Expense type on Resource Assignments becomes non-editable

SUBHAM_SHAW_SN
Tera Guru
Tera Guru

Hello,

The expense type field on Resource assignments is non-editable . Did an analysis ? There is no ACL or UI policy running on this table. Can someone please help ?

Thanks,

SubhamScreenshot 2025-06-16 at 3.37.13 PM.png

1 ACCEPTED SOLUTION

SUBHAM_SHAW_SN
Tera Guru
Tera Guru

I was not able to identify the root cause . However, I could clearly identify that it was a client side logic since it was editable from list view. Having said that, I was unable to find the exact code which was making this happen. Thus, I have put in a workaround by creating UI policy with order being 110 which makes expense_type field editable. Sometimes , small hacks work 🙂 

View solution in original post

2 REPLIES 2

danmjunqueira
Kilo Guru

Thanks for the detailed info and screenshot. Since your ACLs are returning true for both read and write access on the expense_type field of the sn_plng_att_core_resource_assignment table, and there are no UI Policies blocking it, here are some other common causes to investigate when a field appears non-editable:

1. Form View Configuration (Read-only Field on View)
Go to the Form Layout or Form Design for sn_plng_att_core_resource_assignment.

Check if the expense_type field is marked as read-only on that specific view (such as Default, Workspace, or Self Service).

Even if ACLs allow write, the form layout can override it visually.

2. Client Script Making the Field Read-Only
Check for any onLoad client scripts that use:

g_form.setReadOnly('expense_type', true);

These might not be scoped directly to this field name and could be applied conditionally.

3. Dictionary Attribute: Read-Only
Go to System Definition > Dictionary.

Search for the expense_type field on the sn_plng_att_core_resource_assignment table.

Ensure that the “Read-only” checkbox is not selected on the dictionary entry.

4. Form is in a View-Only State
Check if the form is being opened in a view-only mode due to some custom script or UI condition.

Try impersonating an admin and opening the record in a fresh tab.

5. UI Policy Actions from Another Table Extension
Sometimes UI Policies scoped to parent tables affect child table forms.

Check if the field is inherited or shared, and whether there’s a UI Policy from a parent table like task or a base resource assignment table.

6. Workspace View (If Applicable)
If you're seeing this in Configurable Workspace or Agent Workspace, the visibility/editability might be managed by:

Form Controller Settings

Component-level property bindings

Client state restrictions in UI Builder

How to Isolate
Go to the record directly in the platform UI (not Workspace).

Right-click the field > Configure Dictionary → ensure it's editable.

Right-click the field > Inspect ACLs (already done by you, looks clean).

Temporarily preview the record in a new view, or create a new form layout with just this field.

 



SUBHAM_SHAW_SN
Tera Guru
Tera Guru

I was not able to identify the root cause . However, I could clearly identify that it was a client side logic since it was editable from list view. Having said that, I was unable to find the exact code which was making this happen. Thus, I have put in a workaround by creating UI policy with order being 110 which makes expense_type field editable. Sometimes , small hacks work 🙂