Question on triggers - is there a hook for invoking trigger/script upon item deletion?

[smccoy]

Hi...

We would like to allow our users to delete items while applying the governance that we've coded within the tool. The "delete item" ACL provides access to users for deleting items, but it is not granular enough to apply the contextual rules that we need applied.

Is there a way to hook a trigger/script up to the delete-item processing? We are looking for functionality that is similar to edit-item and scripts where we can setup a trigger and within a script add the custom-logic that we need. In our case, if the governance rules do not allow for a deletion, the script would simply abort with a message describing why the delete is not allowed.

Please let me know how we can accomplish this functionality.

Kind regards,

-Sean

edits: corrections for grammar and typos.

[JoeBartlett]

Hi Sean,

Unfortunately there is currently no Item Delete event exposed for triggers to hook into, but there is an existing RFC requesting this functionality. Check article CS91787 found in our knowledgebase.

[smccoy]

Thank you for the update.

-Sean

[wcatunda-2]

Hi,

Checking the Forward/Backward relationship size, could be a valid solution? For example:

if (delta.getOldFieldValue("Contained By").size() > delta.getNewFieldValue("Contained By").size()) {

    abort("You can't Delete!");

}

[Rocko]

This would work for nodes, i.e. items in document context, but most probably not for items like a defect.

Also there are two different "delete" notions here.

One is the Item>delete, which "physically" deletes an item the other one is deleting in a document, which basically unchains the item from the document tree. But for the integrity of the history it is still there.

[VolkerEckardt]

Hello Sean,

even though there is no delete event to catch, I would anyway implement it in a different way:

a) the items you want to delete should have a "To be deleted" state

This state you can use to catch the user request and, within a scheduled trigger, perform the deletion.

Additionally, you can prevent users from setting this state easily (state transition for specific roles only).

Finally, you can check if the deletion process is allowed. Assuming there are still relationships to other items, you can block the state change easily.

b) if you do not want to go with this approach, I would still not let a user delete any item. The alternative to the state is a project change to a separate "wastebasked" project. Again, very good to control who can see that (perhaps only team leads) and therefore very safe.

Furthermore, you can have again your scheduled trigger that will purge the Wastebasked on a regular base,  lets say you purge all items older than 30 days. Again here, much better control than letting a user delete any item rigth away.

To summarize: I would never give a user any item deletion rights. Instead, I would choose option a) or b).

Hope this helps.

Volker