Community Advisor

Solved

Custom Granite render condition for hiding component/AEM UI menu option based on User Group

Forum|Forum|2 years ago
July 5, 2023
4 replies
6123 views

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?

@theo_pendle, @arunpatidar

Thanks,

Rohan Garg

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by Rohan_Garg

Hi All,

Thank you for your replies! Please find the summary below of all the options-

Granite Render Condition

/libs/granite/ui/components/foundation/renderconditions/privilege
/libs/dam/gui/content/assetdetails/jcr:content/actions/annotate/granite:rendercondition/haspermission
This will hide the Annotate button from the top header rail bar.
/libs/fd/fm/gui/components/admin/renderconditions/groups - AEM 6.5 (not available on AEMaaCS)
/libs/fmdita/rendercondition/groupmember (Available on AEM Guides)
/libs/dam/gui/content/assets/jcr:content/actions/selection/annotate

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.

aanchal-sikka

Community Advisor

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

https://developer.adobe.com/experience-manager/reference-materials/6-5/granite-ui/api/jcr_root/libs/granite/ui/components/coral/foundation/renderconditions/privilege/index.html

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

Rohan_Garg

Author

Community Advisor

@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]"/>

aanchal-sikka

Community Advisor

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

I

imshailesh

Level 2

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

2. Similarly, we need to overlay one more path for show/hide Annotate on Selection of Asset.
Path : /apps/dam/gui/content/assets/jcr:content/actions/selection/annotate

Here, first we need to add entry for granite:rendercondition under above mentioned path with property as below

jcr:primaryType

Name

nt:unstructured

sling:resourceType

String

granite/ui/components/coral/foundation/renderconditions/and

Then, we can copy the same node isInGroup what we created in first step, keeping same property.

I tested the scenario in AEM 6.5 vanilla instance by creating test-user and asset-manager group. If test-user is part of asset-manager group, I am able to see Annotate option on selecting of image as well as on asset details page and vice-versa.

For ellipsis menu Annotate, we need to change logic by overriding /libs/dam/gui/coral/components/admin/contentrenderer/card/asset/quickActions.jsp at line number 92.

Regards,
Shailesh

Rohan_Garg

Author

Community Advisor

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.

N

nksingh24

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.

Rohan_Garg

Author

Community Advisor

@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.

Rohan_Garg

AuthorAccepted solution

Community Advisor

Hi All,

Thank you for your replies! Please find the summary below of all the options-

Granite Render Condition

/libs/granite/ui/components/foundation/renderconditions/privilege
/libs/dam/gui/content/assetdetails/jcr:content/actions/annotate/granite:rendercondition/haspermission
This will hide the Annotate button from the top header rail bar.
/libs/fd/fm/gui/components/admin/renderconditions/groups - AEM 6.5 (not available on AEMaaCS)
/libs/fmdita/rendercondition/groupmember (Available on AEM Guides)
/libs/dam/gui/content/assets/jcr:content/actions/selection/annotate

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded