BLTHAdapter and stopping tasks

[Stephan vanBeerschoten]

The handleSetSubject() method of the BLTHAdapter class is processed before the task is displayed.

It is used to pre-process and send out error messages that are shown at the top of the task screen.

What is the trick to abort/stop the displaying of the task screen in case handleSetSubject() decides it needs to? I can throw an IMSException or regular Exception, but that only displays the exception message. It doesn't stop the task from being displayed, and data from being entered/submitted, AND the exception message disappears  when you switch from one ProfileTab to another, even when you go back to the first.

[Poonit Marketkar]

If an exception is thrown in handleSetSubject(), then basically validation has failed during set subject phase. Currently, the IDM product will not abort further rendering of the task. 

 

If you desire a change in this behavior, then its possible to enhance this to introduce an abort of further task rendering. Suggest open a new enhancement for this.

[Stephan vanBeerschoten]

Do you have a recommendation for how I can abort the presentation (and possibility for submission) of a task based on a piece of code logic? I don't want to wait until handleValidation() because that would waste a lot of time of an admin filling in this data entry task form only to be rejected after submit was pressed.

[Poonit Marketkar]

Since the actual setSubject is done via RHino JScript engine, we cannot abort it as it is designed to let the task get rendered. My recommendation is open an enhancement for this - the enhancement would allow the user to abort the entire process based on a configuration.

[Gordon Lamothe]

The enhancement request process is putting in an Idea.

You can also vote on others ideas.

The final determination is not based just on votes, but on if Dev believes the change will help the most Users.

[Stephan vanBeerschoten]

Thanks for the confirmation. I submitted a new idea: Allow aborting of tasks in BLTHAdapter 

I'm open for any suggestions as to the wording. I hope I have properly characterized what I'm looking for.

[Poonit Marketkar]

"Please enhance the exception handler to allow for an abort option to stop the task screen from being displayed, and to make the exception message persistent across tabs in a tabbed task screen."

 

Although you seem to require this only for a tabbed task screen, you should mention this should be done regardless the type of tab controller the task uses. Since there are three types of tab controllers, just mention this instead of tabbed task screen (where you mean Standard tab Controller). Thanks!

[Stephan vanBeerschoten]

Thank you for the feedback. I'd like the abort option for all controllers, but my environment only consists of the tabbed controllers, hence the specific mention. I have updated the Idea, and hopefully made it more clear. 

[Stephan vanBeerschoten]

I have found a workaround that I'd like to share. If you throw an exception in a LAH, the task in which the logical attribute is used is stopped. So what I have done is created LogicalAttributeAdapter class, and use the toLogical() method to perform my checks. You have access to the entire User object, so you can do whatever you need.

 

If any checks fail, I throw an exception. The result is an empty page with the exception message, an button to go back to the search list, and an OK button to return to your home screen. This is exactly what I expected to see from an exception in the BLTH handleSetSubject() method.

 

To implement this, create a new LAH handler in the IM management console, and associate it with a mock |CheckAttribute|. Then add the |CheckAttribute| to the tasks where you want to perform the logical check. If you add it as a Hidden, ReadOnly attribute, the LAH toLogical() code will execute (and abort, if needed) without any visible trace of the mock attribute in the task.