[ https://issues.apache.org/jira/browse/OAK-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Klimetschek updated OAK-4845: --------------------------------------- Description: OAK-4397 introduced a regression: it does not allow syncing to a locally existing group anymore (that does not belong to another IDP). Updating to 1.4.7 now gives "Existing authorizable 'X' is not a group from this IDP 'foo'.", and the group is not synced and most importantly, memberships for external users are not updated anymore. Looking at the group in JCR, it does not have a {{rep:externalId}} at all, only a {{rep:lastSynced}}. Code wise, this is because the {{rep:externalId}} is only ever set in {{createGroup()}}, i.e. when the external sync creates that group initially. If the group is already present locally (but not owned by another IDP!), then it won't use it due to the new {{isSameIDP()}} check, which will also fail if there is no {{rep:externalId}} property set. The use case is that we are defining the group locally as part of our application already (including ACs etc.) and we want certain external users be added to it, based on some some of their settings on the external IDP side. FWIW, we don't care for the syncing of properties for the group itself, just for the memberships. was: OAK-4397 introduced a regression: it does not allow syncing to a locally existing group anymore (that does not belong to another IDP). Updating to 1.4.7 now gives "Existing authorizable 'X' is not a group from this IDP 'foo'.", and the group is not synced and most importantly, memberships for external users are not updated anymore. Looking at the group in JCR, it does not have a {{rep:externalId}} at all, only a {{rep:lastSynced}}. Code wise, this is because the {{rep:externalId}} is only ever set in {{createGroup()}}, i.e. when the external sync creates that group initially. If the group is already present locally (but not owned by another IDP!), then it won't use it due to the new {{isSameIDP()}} check, which will also fail if there is no {{rep:externalId}} property set. The use case is that we are defining the group locally as part of our application already (including ACs etc.) and we want certain external users be added to it, based on some some of their settings on the external IDP side. We don't care for the syncing of properties for the group itself, just for the memberships. > Regression: DefaultSyncContext does not sync membership to a local group > ------------------------------------------------------------------------ > > Key: OAK-4845 > URL: https://issues.apache.org/jira/browse/OAK-4845 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external > Affects Versions: 1.5.3, 1.4.7 > Reporter: Alexander Klimetschek > Priority: Critical > > OAK-4397 introduced a regression: it does not allow syncing to a locally > existing group anymore (that does not belong to another IDP). > Updating to 1.4.7 now gives "Existing authorizable 'X' is not a group from > this IDP 'foo'.", and the group is not synced and most importantly, > memberships for external users are not updated anymore. Looking at the group > in JCR, it does not have a {{rep:externalId}} at all, only a > {{rep:lastSynced}}. > Code wise, this is because the {{rep:externalId}} is only ever set in > {{createGroup()}}, i.e. when the external sync creates that group initially. > If the group is already present locally (but not owned by another IDP!), then > it won't use it due to the new {{isSameIDP()}} check, which will also fail if > there is no {{rep:externalId}} property set. > The use case is that we are defining the group locally as part of our > application already (including ACs etc.) and we want certain external users > be added to it, based on some some of their settings on the external IDP > side. FWIW, we don't care for the syncing of properties for the group itself, > just for the memberships. -- This message was sent by Atlassian JIRA (v6.3.4#6332)