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.

Method-level security definition

zhihailiu

Hi,

public-services-security-context.xml has the method-level security definition. For example,

org.alfresco.service.cmr.repository.NodeService.addAspect=ACL_NODE.0.sys:base.WriteProperties,ACL_ITEM.0.cmwnable.TakeOwnership

Question 1 - what does "ACL_ITEM.0.cmwnable.TakeOwnership" mean?

Question 2 - If I want to grant permission to members of a custom group, can I just append it like below?

org.alfresco.service.cmr.repository.NodeService.addAspect=ACL_NODE.0.sys:base.WriteProperties,ACL_ITEM.0.cmwnable.TakeOwnership,ACL_METHOD.GROUP_MY_COMPANY_ACCOUNTING

Thanks.

Find more posts tagged with

Comments

afaust

The public-services-security-context.xml file is NOT where you grant permissions to anyone. This defines the service level checks that will be performed for ANY invocation on ANY node / item passed as a parameter. The way you have outlined in your 2nd question actually RESTRICTS the operation to only members of the GROUP_MY_COMPANY_ACCOUNT. No one else would be allowed to add an aspect to a node, which would effectively break your Alfresco system (virtually everything has something to do with aspects under the hood).

As to your 1st question. ACL_ITEM is a special variant of ACL_NODE. This operation requires that a method has a very specific signature (composed of NodeRef and Map or QName). Additionally it will only pass judgement if the operation is used to change the owner. If no owner change is attempted the check will abstain (yield neither a positive nor negative permission check result).

As a general rule, you should (almost) NEVER change anything permission related in *-context.xml files. You can define NEW permissions via a permissionDefinitions.xml that is referenced from a *-context.xml, but that is not a very common use case. Granting permission is almost ALWAYS done exclusively via the Share UI, Java or JavaScript APIs (PermissionService or ScriptNode.setPermission).