This can be done via workflow (so this will only be triggered in the ALM UI, not by any backend integration or modification).
Let's say your driving field is 'Widget Type'. You have a list of values of "Type A", "Type B", and "Type C", and it is multi-select.
You will need lists pre-created for each Widget Type Value:
WidgTypeA |
WidgTypeB |
WidgTypeC |
AAA |
BBB |
CCC |
AAAA |
BBBB |
CCCC |
AAAAA |
BBBBB |
CCCCC |
Without diving into every line of code, the basic idea is this, in your when your driving field has multiple values, you'll want to do the following:
- Check for multiple values in the driver field (just because it's a multi value list doesn't mean you HAVE TO have multiple values assigned). The easiest way to do this is look at the value and check for a semi-colon. If you find one, you have multiple values.
- If you don't have multiple values, assign the appropriate list as you have done for your single value fields.
- If you do have multiple values:
- Create a GUID value. You should be able to google a vbscript function to do this. This will give you a unique 32-char string.
- Create the temporary listname: TempList_<GUIDvalue> (use the AddList method in the CustomizationLists object)
Why: You can have multiple list changes over the course of your ALM session, each one needs to be different.
- Parse the driving list value string (semi-colon is your delimeter) and determine how many values you have. This is how many lists you need to put together. For this we'll call this number "DV" (driving values)
- You're going to have a For loop that's going to loop DV times (once for each value selected)
- For each value selected, read the list item for the corresponding list you have in your system already.
If your first value selected is "Type B" in your driver field, you're going to read the WidgTypeB list and get "BBB".
- Add this value to your TempList_<GUIDvalue> list. using the AddChild method in the CustomizaitonListNode object.
- Cycle through that list until all the values are in your TempList.
- VERY STRONG SUGGESTION: If it's not on prior to the AddChild method being called, add "On Error Resume Next" so that you can catch errors and check for them!
- Error Code 0: this was successful, don't do anything.
- Error Code -2147220424: The item already exists, this one can be ignored too. Just add Err.Clear after. This will cause this to be bypassed and not report back to the user in case your predefined lists have common values (unlike above).
- If any other Error Code is thrown, get it and its description (Err.Description). You can choose to display this to everyone or just to admins.
- As you go through each DV, each corresponding list of values gets added to your TempList.
- Assign TempList to your second-level field.
A couple of things to note:
- This will create lists when you have multiple values on a driving field. This should be done on FieldChange as well as MoveTo. The reason for FieldChange is obvious, but for MoveTo, the reason is so that you get the correct list of values assigned to the field when you select it (especially if that field has Verify Value checked in Project Entities).
- You do NOT need to save your temporary lists. In fact, don't. This means there are no client-server calls in this code, keeping it fast.
- All of your temporary lists will disappear when the user logs out or is disconnected from ALM.
- In the example above, there are only three values and corresponding lists for the driver field. For 3 values having predefined lists for all combinations and assigning those lists is much simpler. You have increasing combinations of values on your driving list as you have more driving values. For 3 driving values, you have 7 lists. The lists would be the union of:
- Type A
- Type B
- Type C
- Type A;Type B
- Type A;TypeC
- Type B;Type C
- Type A;Type B;Type C
- The other factor to consider on the number of lists is the maintenance of them. If the lists to be assigned to the second-level field change, then the code method is a better option as there are fewer lists to maintain. The composite lists don’t exist except when needed and are composed of the few lists that would be under maintenance.
- ALM Version Note: While the use of virtual lists is a sound methodology, an issue in ALM was found and subsequently fixed. In the 12.x framework, ALM 12.63 is required and in the 15.x framework, ALM 15.01 is required.