Solved

Multiselect task execution error message

M
Rank

Multi-selecting rows is quite new in Universal. We think the functionality itself is really interesting, and that is why we tested around a bit with it. A task is able to execute multiple times, depending on the amount of rows you selected.

 

Recently, we have added a Context procedure which disables a task in certain situations. Whenever a row is selected which does not meet the requirements specified in the Context, then the task is disabled. If you multi-select a row for which the task is enabled via the Context, then the task is enabled again eventhough a row is selected for which you should not be allowed to execute the task. Luckily, the Universal GUI shows the following message when trying to execute the task:

We noticed this behaviour does not happen in the Windows GUI. There the task is executed even if one of the selected rows disabled the task. 

Therefore, the questions we have regarding the multi-select functionality are:

  • Is this behaviour final in the Universal GUI? If not, is it possible to change the above message ourselves?
  • Apparently, it is possible for the Universal to look into if a task can be executed looking into the selected rows. (otherwise, the action_not_allowed message is not shown). Why is the task in that case not disabled instead?
icon

Best answer by Arie V 16 June 2021, 19:10

View original

7 replies

Anne Buit
Rank
Userlevel 7
Badge +5

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.

A
Rank
Userlevel 6
Badge +10

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
A
Rank
Userlevel 6
Badge +10

Hi @Anne Buit Any news on the direction you'll be taking with this situation and related timelines for changes?

Anne Buit
Rank
Userlevel 7
Badge +5

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'.

 

A
Rank
Userlevel 6
Badge +10

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.

Anne Buit
Rank
Userlevel 7
Badge +5

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.

A
Rank
Userlevel 6
Badge +10

Idea raised: 

 

Reply


Terms & ConditionsCookie settings