[jira] [Comment Edited] (SLING-10740) Repoinit create path statement fails for node types with a mandatory property

["Eric Norman (Jira)" <ji...@apache.org>]

    [ 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)