How to update Task.State using a client script

[ericgilmore]

ver. Tokyo

Let us begin, stumbled across this today when experimenting with my PDI, while attempting to model a solution.

The ask:

•  A Request State selectbox, on a Request Item with a custom set of options, just for 1 catalog item
•  When the Request State option is selected, update the RITM state (in the background), State (task.state) will not be visible.
•  When the Request State is set to New set State = Open
•  When the Request State is set to {Submitted, Reviewed, Hold, Approved}, State = Work in Progress
•  When the Request State is set to Cancelled, State = Closed Skipped
•  When the Request State is set to Closed, State = Closed Complete

Why? To continue using the OOTB task.state for reporting.

So as a test I created a new column on sc_req_item (Request State | Integer), and added choice list options.

• Added the new field Request State (u_request_state) to the form.
• Added a client script to update State when Request State is updated

Imagine my surprise when I find (in the PDI) that using client scripts in Global seems all but impossible.

Things I've experimented with:

• NOPE - Straight client script to set State when Request State is updated, following SN suggestions {glide.script.block.client.globals = false, Isolate script = (true or false)}
• NOPE - Business rule to do the same actions
• NOPE - UI policy to do the same actions

What I might do next:

Record producer? But I'll be producing a REQ+RITM (Global) so the issue should persist.
Custom app? But it's just a Request. Why create an app, with another table, in another scope, for 1 Catalog item?

??

There has to be a better way.

[ericgilmore · Accepted solution]

How about this?

1. I add the Request State field to Request Item (sc_req_item), so the client feels comfortable using their own states when creating the request, and so this logic doesn't end up in all the other request items.
2. Hide the State field on these types of Request Items,
3. Create a Scheduled Job that does the "sync" of the Request Item.State field, based on the value of Request State,  I don't know, perhaps once a day, thereby preserving the OOTB reporting attributes across the board for ALL requests?

What do we think of this?

[ericgilmore]

This is the direction I decided to go in. Should do the trick and preserve OOTB state options.