Unlocking a page with system user

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

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?

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

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

In any case the question remains:

Shouldn't the code below always work on an admin session?

According to AEM docs it should, but it does not!

Resource pageResource = adminResourceResolver.getResource(pagePath);

Page page = pageResource.adaptTo(Page.class);

if (page.canUnlock()) { // should always return true on admin session

    page.unlock();

}

I can easily use the same "system user" to lock and then later unlock the page without even the need of impersonation, but that would not satisfy this requirement:

- The workflow initiator should be able to manually unlock the page at any time, no matter the state of the workflow. (he can't, unless my workflow code locks the page under his session)

I expected that AEM had a clear straightforward implementation of the page locking mechanism, so that developers did not need to dig into the inner workings of jcr locking.

It will take some time for me, as I'm new to AEM and JCR.

Thank you for the prompt responses, very appreciated.

I don't have a 6.2 setup for now.

If you've setup the system user properly and given all ACLs then probably the next thing to try would be impersonation or other take the jcr properties/node route.

I would recommend you to go through JCR specs that explain more about lock tokens and other aspects, that would definitely throw other options to try out - JCR 2.0: 17 Locking (Content Repository for Java Technology API v2.0)

Additionally, the content repository may give permission to some sessions to remove locks for which they are not the owner. ...

In order to use the lock token as a key, it must be added to the session, thus permitting that session to alter the nodes to which the lock applies or to remove the lock. When a lock token is attached to a Session, the session becomes an owner of the lock.

I found a couple of links, check if these help -

• java - Workflow LockProcess AEM - Not locking the asset/page - Stack Overflow
• User Administration and Security  - Locking a page can be performed when impersonating a user. However a page locked in this way can only then be unlocked as the user who was impersonated or a user with administrator privileges. Pages can not be unlocked by impersonating the user who locked the page.   (this means that you can lock the page impersonating that system user who would unlock it in the last step of your custom workflow)
• AEM 6.2 Lock Payload workflow step behaving as NoOp

Hi,

I checked: my system user already has "jcr:lockManagement" privileges.

I even gave him "jcr:all" but still he could not unlock the page.

Then for the sake of "proof of concept" I tried unlocking by making use of "admin" user via the deprecated :

getAdministrativeResourceResolver(adminAuthenticationInfo)

as Gaurav hinted.

Even the admin user could not unlock!

Can someone please try unlocking via a "system user" or admin (through code) in 6.2.

On the other hand, me and my colleagues have noticed that even unlocking through the UI (as admin) is sometimes a hit and miss. You have to log out, login again or wait for a while etc.

Is there a problem with unlocking in 6.2, do we have to wait till we upgrade to 6.4?

Thank you!

You do it via /crx/de. add the user/group and then assign appropriate permissions.

check - User, Group and Access Rights Administration