- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-16-2025 06:50 AM
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,
Subham
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2025 01:04 PM - edited 07-25-2025 01:04 PM
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 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-16-2025 07:06 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2025 01:04 PM - edited 07-25-2025 01:04 PM
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 🙂