Hi AEM Community,
I have a use case where we want to hide "Annotate" option on AEM Assets for certain user groups.
The best way to do so should be via render conditions.
I was checking out the below blog for it -
https://www.bounteous.com/insights/2020/06/10/control-aem-action-menus-render-conditions
This blog has mentioned a component that validates against a group property is located at /libs/fd/fm/gui/components/admin/renderconditions/groups. However, in AEMaaCS there is no such path anymore.
Query 1 - Is there still a OTB render condition that decides based on group membership?
There was an alternative blog on the same -
https://jpsoares.medium.com/aem-granite-render-conditions-438c804b1e5a
Here they have created a sling model, and created a render condition on the dialog that points to the html file which invokes the sling model.
However, when trying the same I was not able to do so.
My use case is I am trying to hide the Annotate button on AEM Assets for selective user groups.
This button needs to be hidden from both primary and secondary location as well - primary being the top rail and the secondary being the ellipsis menu on each asset icon.
Query 2 - Is hiding the asset optimal way to restrict users of certain groups or should we write corresponding ACLs to do so?
In terms of ACLs how do you restrict an asset's privilege with respect to annotation?
Thanks,
Rohan Garg
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi All,
Thank you for your replies! Please find the summary below of all the options-
Granite Render Condition
Using custom sling model instead of OOTB JSP is also valid approach. The only drawback is this will have to be done for all the paths where annotate button is present. (primary and secondary menu)
Restricting annotate functionality by ACLs and then hiding the buttons provides the best of both approaches.
Views
Replies
Total Likes
hello @Rohan_Garg
Query-1:
If you use AEM guides package, there is one for Group membership under /libs/fmdita/rendercondition/groupmember
There is one for privilege, which can be used by providing access on dummy nodes or by checking on specific ACLs on a resource.
/libs/granite/ui/components/foundation/renderconditions/privilege
Query-2:
Also please check /libs/dam/gui/content/assetdetails/jcr:content/actions/annotate/granite:rendercondition/haspermission
If we take away Modify_properties from the user groups, they won't be able to annotate
@aanchal-sikka - Thank you for your response!
For Query 1, I had checked out privilege render condition but that does not work for my use case. Hence, either we have to install AEM Guides for the render condition or create a custom render condition. I will try to do the latter as including Guides package for one render condition might not be optimal.
Query 2- I explored that haspermission render condition has modify_property but that might block out the entire modify access. I want to restrict user only to annotate property.
<haspermission
jcr:primaryType="nt:unstructured"
sling:resourceType="dam/gui/coral/components/commons/renderconditions/haspermissions"
path="${requestPathInfo.suffix}"
privileges="[modify_property]"/>
Hello @Rohan_Garg
You can control the Annotation by just the ACLs, without taking away the MODIFY access on entire Asset. We just need to define access on comments node
Step-1: Assign Deny on comments node. All annotations are stored in this location
Step-2: Add privilege rendercondition for comments node
I have tried it on Asset Details Screen /apps/dam/gui/content/assetdetails/jcr:content/actions/annotate/granite:rendercondition/hasannotationpermission. The existing Annotations are visible, but user is not getting an option to annotate in toolbar.
The user won't be able to add comments via "Comment" Box. The backend server will throw error.
@aanchal-sikka - Thanks for the suggestion! This will work yes!
However, this solution will hide the Annotation button only in the top header.
The dot-dot-dot icon on individual asset will still display the secondary menu with Annotation.
We ideally want to hide the annotate button and not only restrict it.
The haspermission renditon condition will not allow user to comment but we still want to hide the annotate button and hence need another condition.
Hi @Rohan_Garg ! Good evening !
Query 1 - Is there still a OTB render condition that decides based on group membership?
As I understood, we need to hide "Annotate" option on AEM Assets for certain user groups. The logic present under /libs/fd/fm/gui/components/admin/renderconditions/groups checks for only one group, we can create our own version of renderconditions/groups to check for multiple user group.
/apps/weretail/components/renderconditions/groups/groups.jsp
<%@include file="/libs/granite/ui/global.jsp" %><%
%><%@page session="false"
import="com.adobe.granite.ui.components.Config,
com.adobe.granite.ui.components.rendercondition.RenderCondition,
com.adobe.granite.ui.components.rendercondition.SimpleRenderCondition,
org.apache.jackrabbit.api.security.user.UserManager,
com.adobe.aem.formsndocuments.util.FMUtils" %><%
Config cfg = cmp.getConfig();
UserManager um = resourceResolver.adaptTo(UserManager.class);
boolean isAllowed = false;
String[] groups = cfg.get("groups", String[].class);
for (String group : groups) {
if( FMUtils.isUserPartOfGroup(request.getUserPrincipal(), um, group) ) {
isAllowed = true;
break;
}
}
request.setAttribute(RenderCondition.class.getName(), new SimpleRenderCondition(isAllowed));
%>
We need to overlay certain paths /libs/dam/gui/content/assets/jcr:content/actions/selection/annotate and /libs/dam/gui/content/assetdetails/jcr:content/actions/annotate.
1. We need to add one new entry called isInGroup under for /apps/dam/gui/content/assetdetails/jcr:content/actions/annotate/granite:rendercondition and give property values as
below :
groups | String[] | asset-admin, asset-manager |
jcr:primaryType | Name | nt:unstructured |
sling:resourceType | String | /apps/weretail/components/renderconditions/groups |
jcr:primaryType | Name | nt:unstructured |
sling:resourceType | String | granite/ui/components/coral/foundation/renderconditions/and |
Hi @imshailesh, Thank you for your reply!
I have already tried this approach and it works partially!
Point 1 - The path /libs/fd/fm/gui/components/admin/renderconditions/groups does not exist in the AEMaaCS SDK instance. It does exist on AEM 6.5.0.
Hence the jsp is obsolete. If however, I go ahead and update this jsp on AEMaaCS at /apps. The annotate button does get hidden as shown below -
However, if I click on the dot-dot-dot icon I get an empty screen. I will try to investigate why this happens.
Ideally the best fix would be to find out how the groups.jsp script has been reincorporated in AEMaaCS.
Hey Rohan,
Overlay the following node from /libs to /apps and use grantine:rendercondition like below:
/libs/dam/gui/content/assets/jcr:content/actions/selection/annotate
Any user who is part of Test_group cant see "Annotate" option.
@nksingh24 - Thank you for your response!
This grouprendercondition render condition is just the approach I tried with @imshailesh
We are both getting issue in overlaying /apps - it is working with /libs however.
We will double check if we missed a step.
Anyways, this will overlay the annotate button in primary menu. For secondary menu too we will have to add a render condition.
Views
Replies
Total Likes
Hi All,
Thank you for your replies! Please find the summary below of all the options-
Granite Render Condition
Using custom sling model instead of OOTB JSP is also valid approach. The only drawback is this will have to be done for all the paths where annotate button is present. (primary and secondary menu)
Restricting annotate functionality by ACLs and then hiding the buttons provides the best of both approaches.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Like
Replies