Create an asset team who can not write to certain fields
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago - last edited 4 weeks ago
We have an asset team who has the asset role.
I want another team who has similar roles, but can only read:
o Assigned to
o Serial Number
o Asset Tag
o Model
o Configuration Item
o Comments
I thought I could give this new group asset role and set a client script if they are in this group, they can only read these fields. I haven't been able to get this to work. I tried alm_asset.ci and just ci. Doesn't seem to work.
Other ideas?
Thanks
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thank you for the reply.
I am not sure if this change / work is acceptable to the business needs vs effort to make this change.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
You can't use the onload client script as there are probably a fair few things that will change the readonly state of the fields after the onloads run. UI policy works better just make sure that it runs with a high enough order that the field actions don't get reversed after.
As for comments on workspaces I don't think you will find any good way to limit comments without touching the page on UI builder. The activity stream component is separate to the form component, it's not a formatter on the form like in classic UI.
Depending on your acl setup it is actually pretty simple in comparison. For example OOB you could:
- Create a new asset manager role for example "asset_manager"
- Add asset role to asset_manager
- Create new acls for your fields as listed
- deny unless
- write
- alm_asset.[field_name]
- role: asset_manager
- Give existing group new role and new group existing role
- Works ui-agnostic, from apis etc vs just in form view
Even if you configure something client side definitely use roles that you give to the groups instead of group names in the conditions. You will have occassions where a new requirement will arise that a new group of people has to have the same access but they can't just be added to the existing group and you'd have to go around adding groupnames to scripts.

