Granular object-level permissions within shared documents
Mark Hensler
started a topic
about 7 years ago
We have different teams who perform different tasks on overlapping resources. As such, we make heavy use of Royal Server and shared documents. In an effort to secure access to systems from people/teams to do not require access, we have built documents for common resources and documents for resources unique to smaller teams. This works, but I find it quite cumbersome - as each person must open multiple shared documents, rely on the search to locate anything, and make a best-guess effort in deciding to which document a new resource should be added.
I would like to see RoyalTS support a more granular permission structure for individual objects within a document.
I would like to see fewer shared documents (can we get to a single corporate doc?), which contain all shared resources. The document should utilize the folder structure for organization of the resources. All objects should have a new Security/Permissions page in the objects Properties dialog. This page should assigning object-level permissions to specified users/groups:
Can Create Add new objects under folder.
Can Read If FALSE, do not display in listing. Forced to TRUE if Can Update or Can Delete or Can Admin are TRUE.
Can Update
Can Delete
Can Admin If TRUE, can manage permissions on this object.
The user who creates an object is automatically granted Can Admin.
Permissions should be inherited unless overwritten by the current object. (You could add a checkbox to disable inheritance on the current object. But, this may allow the user to break navigation via the tree. To mitigate, you would need to list folders where Can Read is False but recursively contain an object where the user does have Can Read.)
Each document should have a "Global Admin" group who has Admin access to all objects. This access would aid in recovering objects whose only Admin may have been a terminated employee, etc. This should be a group and not a user to mitigate the risk of employee turnover removing the only Global Admin. (It is easier and less risky to add a user to a group than to exhume a user account.)
The UI should prevent removing "Can Admin" from the last Admin (without considering the "Global Admin" specified above).
Please, support AD integration for user/group selection.
Mark Hensler
We have different teams who perform different tasks on overlapping resources. As such, we make heavy use of Royal Server and shared documents. In an effort to secure access to systems from people/teams to do not require access, we have built documents for common resources and documents for resources unique to smaller teams. This works, but I find it quite cumbersome - as each person must open multiple shared documents, rely on the search to locate anything, and make a best-guess effort in deciding to which document a new resource should be added.
I would like to see RoyalTS support a more granular permission structure for individual objects within a document.
I would like to see fewer shared documents (can we get to a single corporate doc?), which contain all shared resources. The document should utilize the folder structure for organization of the resources. All objects should have a new Security/Permissions page in the objects Properties dialog. This page should assigning object-level permissions to specified users/groups:
Add new objects under folder.
If FALSE, do not display in listing. Forced to TRUE if Can Update or Can Delete or Can Admin are TRUE.
If TRUE, can manage permissions on this object.
The user who creates an object is automatically granted Can Admin.
Permissions should be inherited unless overwritten by the current object. (You could add a checkbox to disable inheritance on the current object. But, this may allow the user to break navigation via the tree. To mitigate, you would need to list folders where Can Read is False but recursively contain an object where the user does have Can Read.)
Each document should have a "Global Admin" group who has Admin access to all objects. This access would aid in recovering objects whose only Admin may have been a terminated employee, etc. This should be a group and not a user to mitigate the risk of employee turnover removing the only Global Admin. (It is easier and less risky to add a user to a group than to exhume a user account.)
The UI should prevent removing "Can Admin" from the last Admin (without considering the "Global Admin" specified above).
Please, support AD integration for user/group selection.
2 people like this idea