nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Inherit permission from secondary parents

unknown

Hi,
we need to inherit permissions from secondary parents.
How Alfresco explains in this page https://docs.alfresco.com/5.2/concepts/secur-acl.html it is possible: "By default, ACL inheritance is always from the primary parent. The underlying design and implementation does not mandate this. ACL inheritance does not have to follow the parent child relationship. It is possible to change this through the Java API."

We can develop a logic like this:
1) nodeservice.addchild (node, parent2)
2) Acl aclOtherParent = accessControlListDAO.getAccessControlList(parent2);
3) aclDaoComponent().enableInheritance(acl.getId(), aclOtherParent.getId());

It works, but there are many side effects to manage. For example, when a user add or remove a permission on parent2 or on his ancestors, Alfresco refresh permissions to node, removing our fix. There are other cases like this.

So, we develop a AOP method interceptor on permissionService.setPermissions, but it doesn't cover all cases.

We need a suggestion to develop a strong solution for our purpose.

Best regards,
Federico Tarantino

Find more posts tagged with

Alfresco Content Services

Comments

afaust

What is the reason that you cannot simply make parent2 the new primary parent, and then use the default inheritance from that parent? Since ACLs can only inherit from one parent either way - so either the primary or only one of the secondary parents - it should be easier to just change what folder is the primary parent instead of fiddling with really low-level customisations.
I mean, I personally never shy away from doing low-level customisations if those can elegantly solve a problem, but in such a case I would rather just switch the primary parent around than trying to get this to work with AOP fiddling.

heiko_robert

Hi Federico,

maybe not the advice you expect but we already implemented something like you describe available as a commercial Alfresco Moulde: ecm4u SmartPermissions

If you add the SmartPermission aspect, the permissions defined for the space the secondary assocs is stored in will be added/inherited . An icon and hint will visualize the smartPermissions to show the user that the file inherits permissions from somewhere else.

We combine this often with our ecm4u Filing module (define names, filing locations, secondaries by rules, templates and metadata) and ecm4u SmartLinks which adds UI support and fixes issues for secondaries on fileserver access.

@afaust: Use case is easy to describe: Multifiling, file plans without the hassle of explicit ACLs.

If you e.g. save a suppliers invoice in the accounting structure which is only accessable by the accounting team, you could add a secondary assoc in the projects or departments space and everybody having access to the secondary space now may read the document.

afaust

@heiko_robert : I sure understand such use cases. But I understand that enableInheritance on the AclDAO just changes from which ACL permissions were inherited, so effectively just changing from parent1 to parent2, which could have just as easily been done by changing which of these parents was the primary. So to me this did not look like a multi-filing case requiring ACL merges from multiple parents, just a question of changing the inheritance source.

Anyway - various options to go here, either by using a ready-made module as suggested or doing custom extension development, but none should have to resort to such low-level AclDAO manipulations, which will never be stable / safe / supported across multiple Alfresco versions / features.

heiko_robert

@afaustTotally agree. Maintainability and following costs are unfortunately underestimated too often when adding/modifying/patching things in Alfresco and other OpenSource platforms ...