I recently had to deal with a number of event handling challenges and received some helpful guidance that got me through.
In one of my challenges, I had a nested list where the parent list was a list of expense categories for a case and the child was a list of categorized expenses where the category code defined the valid expense types in the child list. In order for the expense code dropdown to only show items for the specified category, I had to get the local category code added to the expense item so it could be used as a param in the list source data page.
Prior to constellation, I would just call a data transform tied to my grid’s add row configuration and I would be good to go. In constellation we have three hurdles to manage: 1) getting the value to the child, 2) making sure the field I am writing to is visible and editable in the child record and 3) being able to make it so that users can’t actually modify the field and, in some cases, see the field.
Setting Values on Child Records
There are a few options for getting the value to the child record:
- You can use a pyDefault data transform, but pulling the data from the parent using pyDefault means that your class must always be embedded in that parent class. Danger!!!
- You can use the pyRefreshData at the work class and set the values for all your child embedded items each time a change is acknowledged. (This can be chatty and applies to all changes within the scope of the flow action built-on class).
- I could use a flow action to modify rows in my grid and write a pre-data transform or activity to retrieve the row values from the parent. (If this is well named and described, you are less likely to have this routine used where it shouldn’t be.
Having tried all three approaches, I would use pyDefault when I don’t need values from a parent class. I would use the flow action approach in most other circumstances. I would use pyRefreshData in situations where I need to track events on embedded lists and am trying to avoid using a flow action for editing row data. One side benefit of the flow action approach is that I can also track other field level change events and do additional event processing.
These approaches all fail if the fields we are trying to write to are not visible and editable. The events all fire on the server, so you have the full clipboard to work with when setting values, but the updated values only persist when there are fields on the UI to hold those values. This means that if you are doing grid data entry and you are writing to a field that drives grid behavior, that field has to be visible and editable. This basically forced me to use a modal for adding/editing rows because I rarely wanted users to be able modify values from the parent, let alone see those values (as they were effectively noise).
Hiding Editable Fields
How do we set values for fields that should display as read only or shouldn’t be seen at all? Ideally, our event handlers should be able to write to fields that aren’t visible or are read only and those values should be persisted on save, but they aren’t and you won’t realize you have a problem until you start looking for the values you set post-save.
The work around I learned was that you can add a visible editable property to a view and style it away. If you need to see a read only version of that property, you can add the property to the view a second time and configure it however you want (read only, conditionally visible, conditionally enabled, etc). As long as you have one version of that property on the UI that is visible and editable, your event handling will successfully populate the value.
To style away a control, edit the pyC11nCustomFonts text rule and add a code block similar to this:
div[data-testid*=“HideFieldContentAlways”] {
display: none;
}
Ideally, you would modify this rule in your org layer so you can apply this consistently across the enterprise. However, if this gets customized in an application ruleset, you would need to add the snippet there.
Once that is done, on the fields you want to hide (but write to), set the test id to match the one in your code css. Your event handling will work and all will be right with the world.
There are a couple limitations to this approach:
- there is no tag for grids or multi selects
- grids that don’t allow editing will not respond to event handling