[ https://issues.apache.org/jira/browse/SLING-10740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428458#comment-17428458 ]
Eric Norman edited comment on SLING-10740 at 10/13/21, 7:32 PM: ---------------------------------------------------------------- [~angela] Yes, I did notice that the implementation of UserPrincipalManager#getPrincipal was using a search query to lookup the principal by name and the search indexes are only updated after a save. I guess I was just wanting to take a quick look to see if PrincipalBasedAccessControlManager#canHandle could be implemented in a way that doesn't use the code path that requires a search query. For example, UserProvider#getAuthorizableByPrincipal uses a search query for the lookup but it looks like UserProvider#getAuthorizable does not do the same and may be able to find the unsaved transient principal to satisfy the PrincipalBasedAccessControlManager#canHandle checks without throwing an exception? But I could be wrong as I only took a quick glance at it. If you know of some reason why it would be impossible then I won't spend any more time on that. For example, can you explain if the following inconsistent behaviour is expected? {code:java} UserManager uMgr = ((JackrabbitSession) U.adminSession).getUserManager(); // create a unsaved transient user User su = uMgr.createSystemUser(id, relPath); // lookup by string successfully finds the transient user Authorizable authorizable = uMgr.getAuthorizable(id); // lookup by principal returns null and doesn't find the transient user Authorizable authorizable2 = uMgr.getAuthorizable(new PrincipalImpl(id)); {code} was (Author: enorman): [~angela] Yes, I did notice that the implementation of UserPrincipalManager#getPrincipal was using a search query to lookup the principal by name and the search indexes are only updated after a save. I guess I was just wanting to take a quick look to see if PrincipalBasedAccessControlManager#canHandle could be implemented in a way that doesn't use the code path that requires a search query. For example, UserProvider#getAuthorizableByPrincipal uses a search query for the lookup but it looks like UserProvider#getAuthorizable does not do the same and may be able to find the unsaved transient principal to satisfy the PrincipalBasedAccessControlManager#canHandle checks without throwing an exception? But I could be wrong as I only took a quick glance at it. If you know of some reason why it would be impossible then I won't spend any more time on that. > Repoinit create path statement fails for node types with a mandatory property > ----------------------------------------------------------------------------- > > Key: SLING-10740 > URL: https://issues.apache.org/jira/browse/SLING-10740 > Project: Sling > Issue Type: Bug > Components: Repoinit > Reporter: Eric Norman > Assignee: Eric Norman > Priority: Major > Fix For: Repoinit JCR 1.1.38 > > > The processing of the "create path" statement calls save() at the end which > will cause a constraint violation if the nodetype of the created path > contains any properties that are declared as mandatory (and not autocreated). > No processing of "set properties" statements happens before the save() call > in AclVisitor#visitCreatePath so it does not seem to be possible to define > any mandatory properties using the current repoinit grammar. > I could see this solved in a couple ways: > # The AclVisitor#visitCreatePath could possibly pre-process any "set > properties" statements that are applicable to the created path before calling > save and then skip those same items when NodePropertiesVisitor visits the > same. > # Or, the "create path" grammar could be extended to allow defining > properties to be set at the same time as the create (with a syntax that is > similar to the "set properties" statement?) > # Or, perhaps calling save in AclVisitor#visitCreatePath is not necessary? > I'm not sure of the historical reasons why save() is done there. > # Or, maybe something else I haven't thought of > > -- This message was sent by Atlassian Jira (v8.3.4#803005)