Multiselect task execution error message

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?

2 replies

Userlevel 6
Badge +4

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.

Badge +1

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