Hi Megala, Yes.we can do it. +1 for the change.
Thanks, Nisala On Sun, Jun 12, 2016 at 11:49 PM, Nisala Nanayakkara <[email protected]> wrote: > Hi Udara, > > Main purpose of separating editing dashboard and changing dashboard > settings, is to give only dashboard editing ability to the dashboard > designers. In current DS, users who have dashboard edit role, can access to > dashboard settings page and dashboard json. So that designers can change > the permissions,oauth configuration and etc. I think that these privileges > should be with dashboard owners. That is why I keep dashboard editing > (designing) > and changing dashboard settings as two different operations. > > Thanks, > Nisala > > On Sun, Jun 12, 2016 at 6:56 AM, Dilan Udara Ariyaratne <[email protected]> > wrote: > >> Hi All, >> >> IMO, what we require here is a "dynamically-defined, >> specific-resource-level-permission" which cannot be achieved by a >> "pre-defined, global-permission". >> >> For ex: dasboards/view golbal-permission would allow any user to view any >> dashboard in the system. >> But if we want to limit specifcally the viewability of, let's say >> dashboard "A" to user "X", but not to "Y", we require a dynamically-defined >> (defined upon the creation of the dashboard), >> specific-resource-level-permission (dasboards/A/view); so that by assigning >> that permission to user "X" and not to "Y", we can achieve the required >> behavior. >> >> @Nisala, >> if I am correct, you are trying to achieve the same here by defining a >> role entry that can act as such a permission (i.e. dynamically-defined, >> specific-resource-level-permission) >> which is exactly the other way of doing this instead of using the >> permission based approach. >> >> In this scenario, either if we choose the role option or the permission >> option, it seems that >> the number of entries to be maintained either at the role level or >> permission level to allow these restrictions, are the same. >> Therefore, in terms of scalability, both options carry the same burden. >> >> But operational wise, the permission based approach has the following key >> advantage over the other. >> Take the same example that you have considered. >> >> i.e. lets think that we have to give access to settings page of >> dashboard X for all the users who have role A. Then how can we achieve that >> use-case here ? >> >> With permission based approach, this can be so easily achieved by adding >> the dashboard "X" settings view permission to role "A". >> However with role based approach, we will have to assign the dashboard >> "X" settings view role to each and every user one by one in order to >> achieve the same. >> But then again, as sinthuja mentioned, if we have the ability to add >> multiple roles to do such operation in addition to the default role, this >> won't even be an issue. >> >> Hence, +1 to go with this approach. >> >> In the mean time, one more clarification to make : >> >> i.e on : Another suggestion from me, Shall we create a single role >> called 'owner' by merging settings role and delete role as manuranga >> mentioned ? >> >> In here, why are we considering dashboard editing and changing dashboard >> settings >> as two different operations? >> Cannot we merge these two and come up with a role and operation mapping >> as follows. >> >> [1] internal/dashboards/{dashboardId}/viewer - can only view the specific >> dashboard >> [2] internal/dashboards/{dashboardId}/editor - can view, edit and change >> any settings of the dashboard >> [3] internal/dashboards/{dashboardId}/owner - can view, edit, change any >> settings and even delete the dashboard, and also is the original creator of >> the dashboard >> >> Regards, >> Dilan. >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Sat, Jun 11, 2016 at 7:20 PM, Megala Uthayakumar <[email protected]> >> wrote: >> >>> Hi Nisala, >>> >>> Shall we create global level permissions for gadget/layout upload and >>> delete as they are very sensitive operations which can directly impact on >>> dashboard creation? >>> >>> Note - Gadget/Layout upload and delete are new features that are going >>> to be introduced with the new release. >>> >>> Thanks. >>> >>> Regards, >>> Megala >>> >>> On Thu, Jun 9, 2016 at 4:32 PM, Nisala Nanayakkara <[email protected]> >>> wrote: >>> >>>> Hi Sinthuja, >>>> >>>> Thanks for the feedback. I will proceed with implementation. >>>> >>>> Thanks, >>>> Nisala >>>> >>>> On Thu, Jun 9, 2016 at 4:26 PM, Sinthuja Ragendran <[email protected]> >>>> wrote: >>>> >>>>> Hi Nisala, >>>>> >>>>> On Thu, Jun 9, 2016 at 8:13 AM, Nisala Nanayakkara <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Sinthuja, >>>>>> >>>>>> This email is to clarify several issues regarding this feature. Up-to >>>>>> now I have created a four internal roles as above. All these four roles >>>>>> are >>>>>> assigned to the user who created the dashboard initially. If we want to >>>>>> give specific permission to another user, we can assign appropriate role >>>>>> to >>>>>> that user. As an example if we want to give access to the settings page >>>>>> to >>>>>> a user, we can assign appropriate role to that user. >>>>>> >>>>>> But lets think that we have to give access to settings page of >>>>>> dashboard X for all the users who have role A. Then how can we achieve >>>>>> that >>>>>> use-case here ? >>>>>> >>>>> >>>>> The operations of the dashboard will be assigned initially with the >>>>> above mentioned roles, but you should be able include other roles also >>>>> for >>>>> that operation as same as we have now currently. And hence it's just >>>>> adding >>>>> roleA also along with internal/dashboardA/viewer role for example. >>>>> >>>>>> Are we going to the add UI configuration in settings page as for >>>>>> editor and viewer ? >>>>>> >>>>> >>>>> Yes, there should be separate options to assign and remove roles per >>>>> operations. >>>>> >>>>>> Otherwise we have to go through all the users who have role A and >>>>>> assign them with the dashboard X settings role using carbon management >>>>>> console. >>>>>> >>>>>> Another suggestion from me, Shall we create a single role called >>>>>> 'owner' by merging settings role and delete role as manuranga mentioned ? >>>>>> >>>>> >>>>> +1. >>>>> >>>>> Thanks, >>>>> Sinthuja. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Nisala >>>>>> >>>>>> On Tue, Jun 7, 2016 at 9:15 PM, Manuranga Perera <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> If we want to model with the permissions then we should be able to >>>>>>>> add the permissions dynamically, but this is not possible with current >>>>>>>> carbon - 4.x. And as I have mentioned above, this cannot be included >>>>>>>> in the >>>>>>>> global level as well, because having a settings or delete privileges >>>>>>>> for >>>>>>>> dashboard - X, doesn't mean you have the same privileges for dashboard >>>>>>>> - Y. >>>>>>>> And hence we thought of going with roles approach for this one as >>>>>>>> well. I >>>>>>>> agree, the role names for settings and delete is bit odd, we need to >>>>>>>> come >>>>>>>> up with proper names for those. :) >>>>>>>> >>>>>>> >>>>>>> I think it is possible to dynamically create any permissions via the >>>>>>> API even in C4 >>>>>>> >>>>>>> 2) Does "settings" make sense, because if you are an editor, anyway >>>>>>>>> you'll have full access to the JSON, don't you? >>>>>>>> >>>>>>>> In settings you have the full privileges, ie, you can even remove >>>>>>>> the user who initially created the dashboard, IMHO it provides the full >>>>>>>> control of the dashboard. Designer doesn't have such privileges, >>>>>>>> he/she can >>>>>>>> only add/remove gadgets, pages etc which is related to designing the >>>>>>>> dashboard. Therefore we need to have a different role to control the >>>>>>>> access >>>>>>>> of the settings page. >>>>>>> >>>>>>> >>>>>>> We may call this "Owners"? >>>>>>> >>>>>>> -- >>>>>>> With regards, >>>>>>> *Manu*ranga Perera. >>>>>>> >>>>>>> phone : 071 7 70 20 50 >>>>>>> mail : [email protected] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Nisala Niroshana Nanayakkara,* >>>>>> Software Engineer >>>>>> Mobile:(+94)717600022 >>>>>> WSO2 Inc., http://wso2.com/ >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Sinthuja Rajendran* >>>>> Technical Lead >>>>> WSO2, Inc.:http://wso2.com >>>>> >>>>> Blog: http://sinthu-rajan.blogspot.com/ >>>>> Mobile: +94774273955 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Nisala Niroshana Nanayakkara,* >>>> Software Engineer >>>> Mobile:(+94)717600022 >>>> WSO2 Inc., http://wso2.com/ >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Megala Uthayakumar >>> >>> Software Engineer >>> Mobile : 0779967122 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > > -- > *Nisala Niroshana Nanayakkara,* > Software Engineer > Mobile:(+94)717600022 > WSO2 Inc., http://wso2.com/ > -- *Nisala Niroshana Nanayakkara,* Software Engineer Mobile:(+94)717600022 WSO2 Inc., http://wso2.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
