Multiple UI Policies on Same Field Not Working as Expected
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2018 11:13 AM
NowI have multiple UI Policies on the same field, and I cannot get them to work the way that I want. It is my understanding that the one I want to "override" (or take precedence over the other should be the larger Order number).
So, here is my original UI Policy that was working fine. Basically, it hides my approver field from sc_req_item when the approver field is empty. This UI Policy has an order number of 100.
Now, I am trying to add a new UI Policy. There is one situation in which the Approver field is empty that I want to show it. Not only do I want to make it visible, but I also want to make it editable (basically, in part of a workflow, if the field is blank, the RITM is being assigned to a group that needs to populate it). The order number I use for this is 200. However, it doesn't work. It does, in fact show the field in this scenario, but it is Read-Only so I cannot edit (and I am in the group it is being assigned to). Here is what that UI Policy looks like:
I did also search for any other UI Policies on this field, and could not find any.
Can anything see what I am doing wrong? How can I accomplish my goal?
Thanks
- Labels:
-
User Interface (UI)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2018 12:53 PM
Right - you won't need the ui policy action because you're controlling the behavior via the scripts.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2018 12:42 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2018 12:52 PM
Ah, it will not override a field set read only at the dictionary level. You should uncheck that and control edit of the field through UI Policies, Client Scripts, and ACLs (the last being used if you need to prevent edit in list view).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2018 01:07 PM
OK. So the fact that it is set like that there implies that we want it to be read-only most of the time, and only not read-only in that scenario I laid out that I am trying to program for. So if I uncheck that box from the Dictionary entry, what is the best way to make sure that it keeps working the way it has been up to this point for all other requests? Is the new UI Policy we created comprehensive enough, or do we need to make another more general one?
For example, we have the condition "Approver is empty" on the "When to Apply" tab, and then have Execute if True and Execute if False section on the "Script" tab. So, if the Approver field is NOT empty, will this UI Policy run, and just hit the FALSE script then?
If so, then I think the following should work, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-21-2018 06:23 AM
Well, I tested it out, and unfortunately, it did NOT work. I removed the "Read-Only" flag from the dictionary entry, and tried to let this UI Policy control everything. But when I bring up a record where the "Approver" field is populated, it is editable (not read-only), so it looks like the "Execute if false" code is not being applied here.
So, I think I am back to square one...
Not sure where to go from here.