Hi Marijn,
Indicium is currently notifying Universal GUI that one or more rows are not eligible for the multirow task execution. Universal currently chooses to call off the execution when this scenario occurs.
You are correct that this is different from the Windows GUI. The Windows GUI ignores this situation and doesn’t notify the user either. The Universal GUI could adopt the same behavior by ignoring this notification or we could change Indicium to inform the caller about this situation.
There are other scenarios that prevent some of the rows from participating in execution that may occur later in the process, such as user input not being processable for one of the rows. This is currently not communicated to the end-user and doesn’t prevent task execution for the other rows.
Certainly not consistent. As mentioned before, there are multiple ways to resolve this. I’ll raise this with the teams for deliberation and keep you posted in this thread.
Hi Anne,
Thanks for your clarification, we did some internal follow up discussion and would like to provide the following pointers for a preferred solution:
- We think it is too rigid that the Universal GUI simply calls off the entire execution
- We can think of scenario's in which we like the Task to execute for all eligible rows, whilst not executing the Task against the in-eligible row.
- Say if a user selects 20 records for some bulk edit action and 1 of these rows would call off the entire Task: then the user would have to go row by row to figure out which one is causing the Task to fail and then de-select that one.
- We can also think of scenario's in which we like the Task to execute for ALL rows
- In that case we would like to add our own process flow decision logic and return a message to end users, telling them about the in-eligible row and asking them whether or not to continue.
- We wish to be able to customize the error message
- Block vs warn
- Show vs hide
- Edit message content
- In any case: we don't like such user-unfriendly errors to be thrown to our end users
Hi @Anne Buit Any news on the direction you'll be taking with this situation and related timelines for changes?
Indicium has already been modified to have Universal match the behavior of the Windows and Web GUI. See the release notes:
We are considering adding the option to notify the user when one or more of the selected rows are:
- Not eligable due to Context logic
- Evicted after user input was not applicable to the row (due to Layout logic limiting fields, look-up filters)
- Not executable due to the Layout logic preventing the commit
Note that this mechanism will not inform the user when actual task execution itself for a single row was not succesful. The normal messaging system can be used for this. In a sense, this is fully controllable by the developer.
Implementing this will require a major platform version update. Given the number features currently on the release planning, I doubt it will make it to the next major release.
If you want to keep track of this new feature, please submit this idea to the ideation section and we’ll keep you posted of any progress.
Furthermore, preventing all tasks from executing when one of the rows row is not eligable, evicted, not executable or fails execution is not something we’d implement at the same time as this would open up quite the can of worms regarding atomic execution. The developer can already support this for the most part using a so-called 'MultiselectParameterID'.
Hi @Anne Buit Thanks for the elaborate update! I wasn't triggered when reading the Indicium Release Notes, but glad you mentioned this change. I think the description there is clearer if you replace the bold part with ‘could not be executed on one’
Minor fixes and tasks
- We have fixed an issue that occurred when using multi-row tasks in the Universal GUI. When the task could be executed on none of the selected records, for instance, due to a context procedure, the entire set would fail. Indicium will now ignore such errors, just like the Windows and Web GUIs do.
We concluded that in an important scenario for which we use the multi-row Task execution the lack of a notification to the end user is a huge risk, we cannot affort the task execution skipping a record unnoticed to the end user. So we're currently going to work around it by not using the context procedure, but instead extend the Process Flow with some decision logic. So we're definitely eager to have the ability to notify the user about the scenario's you mention!
We'll also see if we can get the MultiselectParameterID functionality working at some point, currently we use a temporary table for a similar purpose.
Good point, I’ve updated the release notes accordingly.
The purpose of the MultiselectParameterID is exactly for verifying and processing the selection in a single transaction and is generally more robust than using a temporary table.
