This post was inspired by a question posted here - Dependent Choice List in Requested Items
The poster wanted to add 2 extra choices to the State field based on what Catalog Item was ordered. If a particular item was ordered, he wanted to add "On Hold" and "Awaiting User Info" as valid choices to the State field. Of course the often used "g_form.addOption" and "g_form.removeOption" methods were suggested (guilty) as a means to solve the issue, but anything running client-side really runs the risk of causing issues. One issue is the choice list would not be updated in list views.
So after some playing around, the solution can actually be handled with Dependent Values. I spent a bit of time experimenting with it and came up with the following that works:
1. Add a new field called "State Set" on the Task table (you might want to use it elsewhere) with a default value of "default"
2. Add a Dictionary Override on the Task.State field for the Requested Item table with "Override dependent" selected and "u_state_set" in the "Dependent" field:
3. Add 2 new sets of choices for the sc_req_item.state field, one where the Dependent value field is "default" for your default set of choices and the other "hold" that includes the default values and the 2 new ones:
Be careful when adding new "Values" for the State field - use a unique and higher number for any custom choices you add, as shown above (I like to start at 100), and do NOT re-use any out-of-box values as they mean something to the OOB code base.
4. Build a Business Rule to populate the "State Set" field based on whatever criteria you need (e.g. set to "hold" when the "Item" field is the particular catalog item, etc...)
5. The proper set of choices will now display in the form and list views:
6. Add an Access Control rule on the State Set field that only allows users with the "admin" role to edit it. There is an issue with this, however - the State field will not be editable either in a list view because it is dependent on the State Set field which is not editable. I consider this to be a bug or at least an oversight. I think it is an acceptable use case to restrict write access to the parent field in the dependency but allow the child to be edited. The reverse is not, however.
So this allows you to create a number of choice list "sets" based on the State Set field without having to worry about adding or removing options through client scripts. It means some extra choices to maintain, but usually you will not have to edit them very often, if ever, once configured.
This was tested in Istanbul.
6 Comments
