5 Replies Latest reply on May 13, 2013 5:26 AM by Ryan Lunka

    Reverse Replication of user deletion?


      Hi everybody,

      we have successfully implemented the reverse replication of creation/modification of users from publisher to author following http://www.wemblog.com/2011/10/how-to-set-up-usergroupprofile-reverse.html.


      But how is it possible to also reverse replicate the deletion of users from publisher to author? (Background: we must provide a custom application on the publisher which provides a "delete user" function.)


      The problem here is that it is not possible to define a workflow launcher for this case, as launchers reacting to "removed" events can only refer to a very restricted list of node types, rep:User not being on of them.


      Please tell me, there is an easy way to work around that restriction...


      Thanks for your help!



        • 1. Re: Reverse Replication of user deletion?
          Sham HC Level 7

          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.

          • 2. Re: Reverse Replication of user deletion?
            Ryan Lunka Level 3

            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?

            1 person found this helpful
            • 3. Re: Reverse Replication of user deletion?
              Sham HC Level 7

              Hi Ryan,


              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.




              • 4. Re: Reverse Replication of user deletion?
                hrietz Level 1

                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!



                • 5. Re: Reverse Replication of user deletion?
                  Ryan Lunka Level 3

                  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.