CODEWITHSUNDEEP
permissionsliferay-6
Alain Dresse
Alain Dresse

Reputation: 673

Adding an action key to existing model permissions

I am trying to add a custom permission,i.e. specific to my custom model built with ServiceBuilder (see extract below from resource-actions/default.xml) . My portlet has already been deployed, and is being used.

I have two questions regarding this :

  1. I assume I will have to recreate the appropriate resources in an upgrade method so that my new action key is taken into account. Is that so ?
  2. If I have to add resources again to all my model instances, will the previously assigned permissions be maintained ?

Best regards, Alain

extract of resource-actions default.xml file :

    <permissions>
        <supports>
            <action-key>VIEW</action-key>
            <action-key>DELETE</action-key>
                            ...
            <action-key>NEW_CUSTOM_PERMISSION</action-key>
        </supports>
                     ...
    </permissions>

Upvotes: 0

Views: 1233

Answers (1)

yannicuLar
yannicuLar

Reputation: 3133

The logic in the permission system is Roles -> Action-keys -> Resources

The 'Action-keys -> Resources' is defined in your portlet's business logic, and will be carried with it in other pages or portal instances. This way you can control how the resources (page, model, service builder entities, etc), will be controlled by exposed action keys, for EVERY instance of your portlet.

The 'Roles -> Action-keys' relationship can vary for instances of the same portlet in 2 ways:

  1. By assigning Roles to action keys (from the administrator's control panel), you can use entirely different roles for a specific portal where you deploy your portlet. This way, you are also defining some minimal/default permissions that will be followed in every page of that portal. For expamle, in portal P1, all users in Role R1 can perform the action A1, while in Portal P2, there is no role R1 at all
  2. using the permissions table, you fine tune or override the above permissions, and give different permissions to instances that are placed in different pages of the same portal. e.g Users in role R1, in page p1 can perform an action, while on another page p2, they can't

You can imagine the action keys as an middle layer between the resources and the roles, giving you the abstraction create a great combination of role-to-resource bindings

Upvotes: 1

Related Questions