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.

Implementing Custom Roles to Restrict Access to Actions

pjaromin

I've been struggling with a design for custom permissions to our app and could use some advice.

I've got a few custom actions that I want to expose through Share forms. These actions manage a specific custom model types, nodes of which may exist in any space in the repo. The application I'm porting to Alfresco follows the RBAC pattern and it does seem logical to me to assign the permissions for these actions to custom ROLEs in Alfresco.

I'm struggling however to work out how this can/should be implemented.

First, is it possible/advisable to protect action method through the security configs?

Second, if I create a custom role, say it's "ROLE_CUSTOMTYPE_DESIGNER" what would be the best way to allow admins to assign this role to arbitrary groups?

Thanks!

-Patrick

Find more posts tagged with

Comments

jpotts

Roles don't get assigned to groups. A group has a given role for a given node. So if you define a custom role, your admins can go into a node and say which group(s) are in that role for that node (and its children, at least the ones that have inheritance turned on).

Jeff

pjaromin

Jeff-

Thanks for the response. I've managed to work out how to map these now and have created a set of groups/permissionSets/etc. on bootstrap and applied these to my bootstraped spaces. Your book proved invaluable for this, so thanks!

Now, however, I need to use these permissions to restrict actions under share. I got a bit turned around because the action defs under explorer's web-client-config.xml are nearly identical to share's share-config-custom.xml, and I was expecting the permissions to behave similarly. Now I read in the docs that the permissions for exposed to share need to be defined in the applicationScriptUtils bean.

Does this mean that I need to add any of my custom permissions I need to use with Share actions to the list under the jsonConversionComponent bean? I've added three custom permissions to the list and the action's still not working for me. I've found it very difficult to debug this as it appears to span server and client-side JS.

Any direction/hints would be welcomed!

Thanks!

-Patrick

jpotts

Actually, this is new ground for me. I recently gave this a shot in the actions tutorial and ended up using the out-of-the-box "write" role rather than a custom role in my action config:

<action id="someco-web-enable" type="javascript" label="actions.someco.web-enable" icon="someco-create-website">
    <param name="function">onActionSimpleRepoAction</param>
        <permissions>
            <permission allow="true">Write</permission>
        </permissions>
        <param name="action">enable-web-flag</param>
        <param name="successMessage">message.web-flag.enabled</param>
        <param name="failureMessage">message.web-flag.failure</param>
        <evaluator negate="true">someco.evaluator.doclib.action.isActive</evaluator>
</action>‍‍‍‍‍‍‍‍‍‍

So there definitely appears to be some extra work you have to do before you can use a custom role in the permissions for a Share UI action.

You definitely seem to be on the right track. You may have to turn on your Eclipse debugger for the Share-tier tomcat, the Rhino debugger for Share-tier server-side JavaScript, and Firebug (or the equivalent for your browser) for the client-side stuff.

One thing I would check is to see where Alfresco Share makes the request to the repo tier for the current user's permissions and make sure your custom roles are coming back in that list. If not, you'll have to debug the repo tier to figure out why.

I would love to help you figure this out, because I've been wondering about it, but I don't have time to look at it today.

Jeff

pjaromin

Thanks again, Jeff!

Yeah, I have some other things to work on today as well, but I was debugging both the client-side and repo side yesterday and did see the roles coming in properly from the node details. However I was having trouble working out how this all goes together on the client side…at some point my custom action got filtered out and I was unable to catch where.

Then my head exploded and I had to call it a day!

I'll be back on this either this afternoon, or more likely tomorrow. If you or anyone can provide any additional insight that would be great. If I beat you to it I'll be sure to post what I've worked out here.

Thanks!

-Patrick

pjaromin

Got it!

So my problem apparently was that I was overriding the wrong repo bean def for the user permissions. The version of community I'm using is 4.0.d. In that version, applicationScriptUtils is defined thus:

    <bean id="applicationScriptUtils" parent="baseJavaScriptExtension" class="org.alfresco.repo.jscript.ApplicationScriptUtils">
        <property name="extensionName">
            <value>appUtils</value>
        </property>
        <property name="serviceRegistry">
            <ref bean="ServiceRegistry"/>
        </property>
        <property name="decoratedProperties">
            <map>
                <entry key="cm:creator">
                    <ref bean="usernamePropertyDecorator"/>
                </entry>
                <entry key="cm:modifier">
                    <ref bean="usernamePropertyDecorator"/>
                </entry>
                <entry key="cm:workingCopyOwner">
                    <ref bean="usernamePropertyDecorator"/>
                </entry>
                <entry key="cm:lockOwner">
                    <ref bean="usernamePropertyDecorator"/>
                </entry>
                <entry key="cm:owner">
                    <ref bean="usernamePropertyDecorator"/>
                </entry>
                <entry key="cm:taggable">
                   <ref bean="tagPropertyDecorator"/>
                </entry>
                <entry key="cm:categories">
                   <ref bean="categoryPropertyDecorator"/>
                </entry>
           </map>
        </property>
        <property name="userPermissions">
            <list>
                <value>CancelCheckOut</value>
                <value>ChangePermissions</value>
                <value>CreateChildren</value>
                <value>Delete</value>
                <value>Write</value>

                <!– PUT custom permissions HERE –>
                <value>MyCustomPermission1</value>
                <value>MyCustomPermission2</value>
            </list>
        </property>
    </bean>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Unfortunately I had grabbed the definition from a later (I believe community HEAD) version of script-services-context.xml that breaks up into multiple helper beans. For this version, you need to override the 'baseJsonConversionComponent' bean instead:

   <bean id="baseJsonConversionComponent" abstract="true">
      <property name="nodeService" ref="NodeService"/>
      <property name="publicServiceAccessService" ref="PublicServiceAccessService" />
      <property name="namespaceService" ref="NamespaceService" />
      <property name="fileFolderService" ref="FileFolderService" />
      <property name="lockService" ref="LockService" />
      <property name="permissionService" ref="PermissionService" />   
      <property name="contentService" ref="ContentService" />
        <property name="userPermissions">
            <list>
                <value>CancelCheckOut</value>
                <value>ChangePermissions</value>
                <value>CreateChildren</value>
                <value>Delete</value>
                <value>Write</value>
                <!– Our custom permissions HERE –>
                <value>MyCustomPermission1</value>
                <value>MyCustomPermission2</value>
            </list>
        </property>   
   </bean>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Once this is here, the node details service looks up the user's permission status for your custom permissions and includes them in the JSON result for share.

So the docs that say to override the applicationScriptUtils bean are correct for my version. Looks like I should have checked the svn log before copying the bean def into my code.

Thanks!

-Patrick

jpotts

Hey, glad you got it working!

Thanks for posting what worked.

Jeff