Is there an "After Related List Edit" Event ?

[GeoffreyOptumOp]

Oh Wow, it's been a very long day...  Need help...

How do I run some code AFTER the user has edited a related list, and maybe added 10 items and removed 500 items, all at once?  I need to perform an action ONE TIME after all the records have been added to and removed from the task_ci table that is represented by this related list.

Currently I have a business rule with some very intensive logic behind it, that is running EVERY TIME a record is deleted from the task_ci table for a task.  It's major overkill.  So again, I need to figure out a clean way to run some code ONLY WHEN all of the "Editing" (adding / deleting) is Done.  Ideally it would happen before the Incident form reloads itself.

Follow?

Thanks!!

[Maik Skoddow]

Hi

unfortunately there is no way for catching the requested state. For each row the update is done individually.

Kind regards
Maik

[GeoffreyOptumOp · Accepted solution]

So I ended up replacing code which was running one time for each deletion from the slush bucket TIMES the number of items IN the slush bucket, which ended up being an untenable Order N*N (or N Squared) algorithm, with something that runs JUST ONCE in an On Display business rule.

When the slush bucket is dismissed, there is a round-trip to the server, and On Display is triggered for the parent Incident record.

So what used to sometimes take 5 minutes to run, and sometimes timed out completely, now takes 2 or 3 seconds max.  I'm pretty happy with the result, if I don't say so myself...

The only drawback I can think of is that the "old code", before I changed it, was tied to the related list TABLE itself, whereas my code is now more tied to a USER INTERFACE concept.  So I guess, in theory, if the table was modified NOT by the user, but by back end code (somehow, for some reason), then my super-duper On Display code would never be triggered.

I don't envision that happening, but if someone can think of an even better solution than On Display, I'm all ears.  Thanks!

[Valor1]

I would do this by firing an event, then looking for that event before firing additional ones.

Depending on how busy your instance is, you may want to add an index to sysevent on "instance" as my sysevent table does not have one. If a table has an index on the queried fields (notice that I've commented out the "table" element query), it's essentially free.

Yes, this will issue a lot of queries against sysevent, but when you run your script action for the triggered event you can be relatively assured that there are no competing events. If you need to make absolutely certain only one runs, you could do gs.eventQueueScheduled() for one minute out then check again in your script action code.

Also note that I'm firing the event for the task instead of the affected ci. This makes the whole approach possible.

Example:

var taskTable = current.task.sys_class_name;
var taskSid   = current.task;
var syseventGR = new GlideRecord('sysevent');
//syseventGR.addQuery("table", taskTable);
syseventGR.addQuery("instance", taskSid);
syseventGR.addEncodedQuery("sys_created_onRELATIVEGT@minute@ago@1") // within 60 seconds

syseventGR.query();
if (!syseventGR.next()){
   gs.eventQueue("task.affected_ci.change",current.task.getRefRecord(), gs.getUserID(), gs.getUserName());
}

Now, I know you said "ideally before the incident form reloads" but I don't know of a way to do that without running for every action as you're doing right now or hacking the M2M UI Page to bits.

[Valor1]

I'm leaving my other reply in case you're using an older version of the platform, but there's actually a really simple way to do this in modern versions.

If you're using the "Add" modal as shown, modify the Add UI action and you should be able to specify your (client side) code before the list refreshes.

Add modal:

Add UI Action -- line 36 should do it. GlideAjax is in scope FWIW:

[EDIT] It doesn't appear that the modal handles deletions 😞