Hi Damith, First of all, I want to clarify what Omindu mentioned regarding his statement "Only the super admin can create a role with Admin permission".
In this case I created the new role from a user with default admin role. Default 'admin' role in the sense, the role that is assigned to the primary super admin user (admin/admin). Refer [1]. I believe a user with this 'admin' role can do anything the primary super admin can do. I also tried out the same use case from a user with super admin permission. Permission assigned as in [2]. In both cases, I couldn't create a role with just admin permission. Considering these facts, can we conclude only the primary super admin (admin/admin) can create roles with Admin permissions? Secondly, although the aggregate of children does not constitute the parent according to the implementation, isn't the behaviour in the functionality the same? If we select all the child permissions we allow to create the role and if we select only parent Admin permission which assigns exactly the same set of permissions, we don't allow to create the role. This behaviour is contradicting to each other from user's perspective. Isn't it? Regards, Dilini [1] [2] On Thu, Oct 8, 2015 at 11:42 AM, Damith Senanayake <[email protected]> wrote: > Since this is the expected behavior and not a bug, I guess we can resolve > the JIRA [1]. > > [1] - https://wso2.org/jira/browse/IDENTITY-3758 > > On Thu, Oct 8, 2015 at 11:40 AM, Damith Senanayake <[email protected]> > wrote: > >> Hi Dilini, >> >> Suppose you have selected all children of a parent permission is selected >> (in this case "permissions/admin/configure, permissions/admin/monitor, >> permissions/admin/login, permissions/admin/manage"). However if you add a >> fifth child (say "permissions/admin/backup"), that is not assigned to that >> particular role, whereas if you have selected "permissions/admin", the new >> permissions will be implicitly added. >> >> Since the aggregate of children does not constitute the parent in our >> permission model, selecting the parent and selecting all its children nodes >> are two different scenarios, hence this is the expected behavior. >> >> HTH, >> >> On Tue, Oct 6, 2015 at 9:59 AM, Dilini Gunatilake <[email protected]> >> wrote: >> >>> Hi Omindu, >>> >>> What is the difference of giving all the child permissions and parent >>> admin permission? Is there any difference in the functionality? >>> >>> Regards, >>> Dilini >>> >>> On Tue, Oct 6, 2015 at 12:19 AM, Omindu Rathnaweera <[email protected]> >>> wrote: >>> >>>> Hi Dilini, >>>> >>>> Only the super admin can create a role with Admin permission, hence the >>>> exception in your first scenario. In your second scenario, you are giving >>>> all the child permissions which is different from giving the parent Admin >>>> permission. >>>> >>>> Have a look at the first few lines at *UserRealmProxy::addRole *[1] >>>> method. In the first scenario, the list of permissions passed to the >>>> addRole method includes "/permission/admin" (Since 'Admin Permissions' is >>>> selected) while the second scenario doesn't. In the addRole method, if the >>>> "/permission/admin" is included in the list of permissions, an exception is >>>> thrown. So this should be the expected behavior. >>>> >>>> >>>> [1] - >>>> https://github.com/wso2/carbon-identity/blob/master/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/UserRealmProxy.java#L869 >>>> >>>> Regards, >>>> Omindu. >>>> >>>> >>>> On Mon, Oct 5, 2015 at 6:05 PM, Dilini Gunatilake <[email protected]> >>>> wrote: >>>> >>>>> Hi IS team, >>>>> >>>>> I tried to create a new role logged in from a user with default admin >>>>> role in MB 3.0.0-ALPHA. When I give permissions as in [1] I get an error >>>>> as >>>>> in [2] and couldn't create the role. Please find the full stack trace >>>>> attached. >>>>> >>>>> But, if I assign permissions as in [3], I can successfully create the >>>>> role. Is this due to a permission issue in the UI? >>>>> >>>>> [1] >>>>> >>>>> [2] >>>>> >>>>> >>>>> >>>>> [3] >>>>> >>>>> Thank you. >>>>> Regards, >>>>> >>>>> -- >>>>> >>>>> *Dilini GunatilakeSoftware Engineer - QA Team* >>>>> Mobile : +94 (0) 771 162518 >>>>> [email protected] >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "WSO2 Engineering Group" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Omindu Rathnaweera >>>> Software Engineer, WSO2 Inc. >>>> Mobile: +94 771 197 211 >>>> >>> >>> >>> >>> -- >>> >>> *Dilini GunatilakeSoftware Engineer - QA Team* >>> Mobile : +94 (0) 771 162518 >>> [email protected] >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> >> >> *-Damith Senanayake-*+94712205272 >> > > > > -- > > > *-Damith Senanayake-*+94712205272 > -- *Dilini GunatilakeSoftware Engineer - QA Team* Mobile : +94 (0) 771 162518 [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
