RE: Programmatically creating a new Role

thumbnail
Pete Helgren, modified 5 Years ago. Regular Member Posts: 225 Join Date: 4/7/11 Recent Posts
I know, I know, plenty of articles on this.  But the kicker is that they are 1) Either very old or 2) Are about adding a Role to a User .  I don't want to add a role to a user.  I want to create a Role from scratch.  Maybe later add it to a User (plenty of code on how to do that).

So, where do I begin with this?  What is the class/method I should investigate to make this happen?  I have searched everywhere and haven't found anything useful.  Running Liferay 7.3.2 
thumbnail
Pete Helgren, modified 5 Years ago. Regular Member Posts: 225 Join Date: 4/7/11 Recent Posts
So here is where I ended up with this.  Not 100% happy with it and I DO have a question for a knowledgeable person who reviews this.  My code:

            RoleTypeContributor roleTypeContributor =
                _roleTypeContributorProvider.getRoleTypeContributor(RoleConstants.TYPE_REGULAR);
            try {
                role = RoleLocalServiceUtil.addRole(99999,
                    roleTypeContributor.getClassName(), 0, roleName, null,
                    null, RoleConstants.TYPE_REGULAR, null, null);
            } catch (PortalException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
 Originally I used RoleServiceUtil which does not require a user ID (the first param) but it throws an error: com.liferay.portal.kernel.security.auth.PrincipalException:
    PermissionChecker not initialized.  I couldn't find good solution for that so I just plugged in the Admin user id (that is not the real one above:99999) and used RoleLocalServiceUtil instead.  It seems to work but seems like it would something less "hacky".  Is there a "proper" way to create a new role without passing in a user id of someone with correct permissions?  Can I just "allow" the service to run under some correct context?
thumbnail
David H Nebinger, modified 5 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
If you use the RoleService (we no longer use the static util classes), the user invoking the method must have the appropriate permissions. That ensures that each one of your portal users can just willy-nilly create roles on the fly whenever they want.

If you use the RoleLocalService (still not using the static util classes), you can use any user id but this is seen as an "audit" entry point so passing in the current user is always best practice.

Your last argument should be a ServiceContext instance, never null, and populated as best you can. The fields from here will also be used for the audit columns in the entity, so pass them often.

I usually pass null for the 2nd argument, using the RoleTypeContributor class is not necessary.

I would suggest passing in the title and description map for your role(s). These control how they'll appear in the UI. So while they may not be necessary to add the role, it will certainly make it easier to use the role.
thumbnail
Pete Helgren, modified 5 Years ago. Regular Member Posts: 225 Join Date: 4/7/11 Recent Posts
Thanks for the update David.  A quick question:  You said I can pass any user ID....I assumed that the user ID needed to have permission to create a Role.  Is that not the case?  I could pass in the user ID of the signed in user, but I was worried that it would fail due to lack of permission.  If any user ID can be used, and is just tracked for audit purposes and not permission, then using the signed in user would be fine.  As an aside, I was initially thrown by the user ID parameter because it appears that the Role would be added to the user in that case.  The documentation could be clearer on what the user ID provides: "userId - the primary key of the user" isn't very helpful.  But, you have been.  Thanks.
thumbnail
David H Nebinger, modified 5 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Permission checks are always against the current logged in user, not the passed in user ids.

When the passed in user id is not the default user (i.e. the guest user), that user is given resource permissions on the role, but do not get the role directly assigned to them.