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
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
