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]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
