Awesome. Thanks. :) On Fri, Oct 9, 2015 at 1:49 PM, Dilini Gunatilake <[email protected]> wrote:
> Hi Damith, > > Noted. Please close the issue. > > Regards, > Dilini > > On Fri, Oct 9, 2015 at 1:05 PM, Damith Senanayake <[email protected]> > wrote: > >> Hi Dilini, >> >> "Considering these facts, can we conclude only the primary super admin >> (admin/admin) can create roles with Admin permissions?" >> - Yes. That is the case. However, as you have correctly understood, this >> only means that the permission "permissions/admin" can only be assigned to >> a role by the super admin and no other admin user. >> >> "Secondly, although the aggregate of children does not constitute the >> parent according to the implementation, isn't the behaviour in the >> functionality the same?" >> - No, they are not. Consider you have assigned a role(role1, say) the >> permission '/permissions/admin/' and another role (role2) has all the >> children of "/permissions/admin/" but not "permissions/admin" itself. Now >> assume you add a new permission that is not already there. role1 will now >> have the new permission and role2 will only have the ones you assigned >> earlier. I hope this is clear. >> >> " 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." >> - Following the above explanation, this is by design and hence is >> logically accurate for* our permission/entitlement model.* >> >> Hope this explains the situation. >> >> On Fri, Oct 9, 2015 at 12:28 PM, Dilini Gunatilake <[email protected]> >> wrote: >> >>> 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] >>> >> >> >> >> -- >> >> >> *-Damith Senanayake-*+94712205272 >> > > > > -- > > *Dilini GunatilakeSoftware Engineer - QA Team* > Mobile : +94 (0) 771 162518 > [email protected] > -- *-Damith Senanayake-*+94712205272
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
