You need to implement Listener OR Listener with workflow package. So Write a listener for delete event & in that listener implement the logic to inform author.
1 person found this helpful
I would think opening up the doors to actually deleting CQ users on a public publish instance would be kind of dangerous. That would be my guess as to why Adobe doesn't allow you to do it, based on the node type options you are given for delete listeners.
What about a slightly different approach? What if instead of deleting users, you simply deactivate them? That way you don't lose data without any awareness that it happened, because it was completely controlled by the end user. If you really wanted you could purge deactivated users from time to time as well. I'm not sure if the Jackrabbit User has a deactivate feature built-in, so you may need to develop it. It shouldn't be too hard though...maybe applying a "deny" permission on every node?
I liked the idea with one small suggestion. Instead of playing with acl to deny permissions. Remove the users from group & assign to group which has deny permission to all.
Thank you, deactivation instead of deletion seems reasonable!
What we ended up doing:
- Created a launcher on the publishers for rep:User modified. In our code we are setting a certain property on the user node which acts as a "request for deletion/deactivation" flag. The modified user is reverse replicated to the author.
- On the author we created another launcher which specifically looks for the "request for deletion" property. It then starts a custom workflow which actually deactivates the user on the author, sets another property as a flag for the publishers and replicates the user to the publishers again (we have more than one).
- On the publishers there is yet another launcher and a custom workflow which now deactivates the user on all publishers.
I'm quite satisfied with that solution even though it looks complicated.
Thanks again for your help!
Sounds perfect. I think that'll be a much better solution for you.
By the way, if you are looking for a good way to purge users or do anything specific with those who are deactivated, some of my colleagues at CITYTECH created a Groovy console for AEM/CQ. It's perfect for that sort of thing.