I have part of code, which runs as system
AuthenticationUtil.runAsSystem(() -> {...}
and in it i lock document
lockService.lock(nodeRef, LockType.WRITE_LOCK);
I also tried this code
AuthenticationUtil.runAs(() -> {...}, "admin");
but document locks by current user (user, which authorized in now). I wan't do it by "admin" username. How can i do it?
Solved! Go to Solution.
You can use AuthenticationUtil.pushAuthentication() + AuthenticationUtil.setFullyAuthenticatedUser() + custom code + AuthenticationUtil.popAuthentication() to temporarily switch the entire authenticated user, which should deal with your case. Just make sure you do the push/pop of the authentication context in a try-finally block.
You can use AuthenticationUtil.pushAuthentication() + AuthenticationUtil.setFullyAuthenticatedUser() + custom code + AuthenticationUtil.popAuthentication() to temporarily switch the entire authenticated user, which should deal with your case. Just make sure you do the push/pop of the authentication context in a try-finally block.
Thank you! Perfect solution for me.
Hi @Skyor
Great this helped & thanks for accepting the solution - really helpful to other users.
Cheers,
@afaust that solution works but not for the "System" username. After executing those lines below, `AuthenticationService.getCurrentUserName()` still returns "admin" instead of "system".
AuthenticationUtil.pushAuthentication();
AuthenticationUtil.setFullyAuthenticatedUser(AuthenticationUtil.getSystemUserName());
I tried to set manually PROP_LOCK_OWNER and PROP_MODIFIER but I faced many issues.
The functionality via AuthenticationUtil makes no distinction between users - it either works for all or for none Of course other components / code - custom or part of core - could potentially not properly respect the state of AuthenticationUtil, or override it after you set it. Without knowing any of your code / other customisation (e.g. use of an authentication component which may not properly respect AuthenticationUtil), it's hard to know what is the issue in your case.
@afaustthank you for the quick response, it's probably just like you said - authenticationService does not respect AuthenticationUtils state. But how to make it respect?
Here is my code which should lock the given nodeRef as the System user.
try {
AuthenticationUtil.pushAuthentication();
AuthenticationUtil.setFullyAuthenticatedUser(AuthenticationUtil.getSystemUserName());
NodeRef childRef = child.getChildRef();
ownableSerice.setOwner(childRef, AuthenticationUtil.SYSTEM_USER_NAME);
lockService.lock(childRef, LockType.READ_ONLY_LOCK); // inside it uses authenticationService.getCurrentUserName()
}
} finally {
AuthenticationUtil.popAuthentication();
}
After executing this code both cm:lockOwner and cm:modifier are set to "admin" instead of "system"
The cm:modifier is likely set to admin because that property can potentially be set after popAuthentication as part of the transaction commit handling, due to delayed policies / transaction listeners.
"But how to make it respect?" - Well, first by finding out how it actually does not respect it and then potentially having that fixed (if it comes from a third-party addon or is some other custom code), or switching over to a more default implementation. There will generally be no way to "make it respect" in your client code alone.
Thank you for this solution. I also have the same case. The software development with mlsdev.com process refers to a series of activities aimed at the execution and delivery of software application designed by using the software's designing tools. This software development service is carried out by software engineers who have a broad range of skills and experience in software design, software implementation and software testing. They develop software according to clients' specifications and integrate it into a business environment. A software developer who works as a team to deliver an application is also called a Software Development Service Provider.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.