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 <dil...@wso2.com>
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 <meg...@wso2.com>
> 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 <nis...@wso2.com>
>> 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 <sinth...@wso2.com>
>>> wrote:
>>>
>>>> Hi Nisala,
>>>>
>>>> On Thu, Jun 9, 2016 at 8:13 AM, Nisala Nanayakkara <nis...@wso2.com>
>>>> 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 <m...@wso2.com>
>>>>> 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 : m...@wso2.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> 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
>>>>> Architecture@wso2.org
>>>>> 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
>>>> Architecture@wso2.org
>>>> 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
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Megala Uthayakumar
>>
>> Software Engineer
>> Mobile : 0779967122
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
