Unlocking a page with system user

[lir]

Hi,

While coding a WorkflowProcess implementation, I need to create a "system user" who can unlock pages.

Pages are locked through a WorkflowSession on a previous workflow step.

How can I give the "system user" the permissions to unlock pages?

Obviously I don't what to use an admin session, and I'm wondering how can I grant unlock permissions in AEM Security Permissions tab!

Thank you,

Lir

[Gaurav-Behl · Accepted solution]

I'd read a thread somewhere which I'll try to find again & post here. It mentioned that 'page.canUnlock()' won't work but 'page.unlock()' will.

[lir]

Interesting!, I'll try that and let you know

[lir]

That was it!

It works now with admin AND with the system user for which I set "jcr:all"

I will reduce the privileges to only what's required of unlocking and that would be it.

It is strange why page.canUnlock() would return false, but no harm now that I know.

Thank you

[AnjaliBiddanda]

HI @lir, we have a custom 'lock payload' and 'unlock payload' steps in our workflow. But the unlock step fails with "LockException: Not an owner of the lock" although i'm using the same serviceUser to lock and unlock the session and this user has jcr:all on the content path and on /home/groups. I've tried both LockManager API and Page API. And i've tried both wfSession (wfSession.adaptTo(Session.class)) and a serviceUser session (serviceResolver.adaptTo(Session.class)).

[AnjaliBiddanda]

Fixed: I was using session.getWorkspace().getLockManager() where session here was serviceUser session instead of wfSession. i.e. final LockManager lockManager = session.getWorkspace().getLockManager(); Here the session should ofcourse be wfSession.

[hsaifudeen]

For me page.unlock() with system user having high privileges didn't work. But something like below worked for me though

page = pageManager.getPage(pagePath);
if (page.isLocked()) {
    Node node = session.getNode(pagePath+"/jcr:content");
    node.removeMixin("mix:lockable");
    session.save();
}

[Gaurav-Behl]

Finally!!

Its probably because the second user who is trying to unlock doesn't have the read permissions on /home/users/..  path to read it's own ACL to find out that can it unlock that specific /content path?

[lir]

That might be the case for my system user, but it shouldn't happen for admin. It does though