-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NEW] Granular permissions for settings #8942
[NEW] Granular permissions for settings #8942
Conversation
…ns' to see and change the affected settings. However, this is not reactive: Once the permissions for a particular setting are changed, the user needs to log off and on again before it becomes effective in the UI. This is most probably a consequence of the CachedCollection. This collection needed to be changed on permission-change. In the backend however, the permissions become effective immediately.
This is great, thanks for the PR. We'll check if we have people available to help on the needed changes, else I'm sure the community can help improving it |
- Do not try to create permissions for hidden settings in higher-level-callbacks - Remove `setting-permissions` collection - fully integrated into `permissions`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a couple of fixes - and reverted some development which was done earlier.
Now, it works fine from my side: reactively without any frontend or backend exceptions ;)
Some explanations why I changed what and where I was looking for better solutions I did not find below.
packages/rocketchat-authorization/client/stylesheets/permissions.css
Outdated
Show resolved
Hide resolved
@@ -1,36 +1,76 @@ | |||
<template name="permissionsTable"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created a template for the table as both permission tables follow the same scheme.
@@ -1,66 +1,121 @@ | |||
/* globals ChatPermissions */ | |||
import {permissionLevel} from '../../lib/rocketchat'; | |||
|
|||
const whereNotSetting = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ne
is not supported by Minimongo. Thus, had to fallback to $where
. Still, this does not seem to work, see the .filter
-comment some lines below
sort: { | ||
_id: 1 | ||
permissions() { | ||
return ChatPermissions.find(whereNotSetting, //the $where seems to have no effect - filtered as workaround after fetch() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any idea why the $where
has no effect?
@@ -1 +1,5 @@ | |||
RocketChat.authz = {}; | |||
|
|||
export const permissionLevel = { | |||
SETTING: 'setting' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can imagine that there are other levels as well, such as the permission to change dedicated roles, thus making it a map
@@ -20,4 +27,12 @@ Meteor.methods({ | |||
|
|||
RocketChat.models.Permissions.on('changed', (type, permission) => { | |||
RocketChat.Notifications.notifyLoggedInThisInstance('permissions-changed', type, permission); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be notifyLogged()
it was like that earlier, so I didn't change it...
}); | ||
} | ||
|
||
setupListener(eventType, eventName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The redefinition is necessary as the change of permissions has to trigger the Settings-collection to be refreshed. We'll have to listen to an event "authorization changed".
// private settings also need to listen to a change of authorizationsfor the setting-based authorizations | ||
RocketChat.Notifications[eventType || this.eventType](eventName || this.eventName, (t, record) => { | ||
this.log('record received', t, record); | ||
if (t === 'auth') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there was an enumeration-constant, I'd be happy to use it ;)
RocketChat.Notifications[eventType || this.eventType](eventName || this.eventName, (t, record) => { | ||
this.log('record received', t, record); | ||
if (t === 'auth') { | ||
if (! (RocketChat.authz.hasAllPermission([`change-setting-${ record._id }`, 'manage-selected-settings']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The concatenation change-setting-${ record._id }
should be reusable function of the auth-package. However, as rocketchat:lib
is lower than rocketchat:auth
, this is not possible.
For simplicity (and worse maintainability) I just green-coded that...
removed WIP as this is actually done, except beautification |
…ng` but not `view-privileged-setting`
Is there possibility to merge this feature in nearest future? About beautification: maybe it could be transposed from table into tokenized rows? Each row would be a role with autocompleted and tokenized select field. So roles with less privileges would take less space and those with more privileges would take more space. Now every role takes exact space (column) and there are every privileges displayed regardless if they're checked or not. In my concept only chosen privileges would be displayed for each row and each privilege could be removed/added. |
…' of https://github.com/assistify/Rocket.Chat into core/RocketChat#8771-fine-granular-settings-permissions
@RocketChat/core I merged the current |
…8771-fine-granular-settings-permissions
@@ -41,6 +40,14 @@ Meteor.methods({ | |||
} | |||
settings.updateById(_id, value, editor); | |||
}); | |||
// Throw messages for settings that are not allowed to save! | |||
if (settingsNotAllowed.length) { | |||
throw new Meteor.Error('error-action-not-allowed', 'Editing settings is not allowed', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error is not propagated to the user, just like it was not done earlier
if (Meteor.userId() === null) { | ||
throw new Meteor.Error('error-action-not-allowed', 'Editing settings is not allowed', { | ||
method: 'saveSetting', | ||
}); | ||
} | ||
|
||
if (!hasPermission(Meteor.userId(), 'edit-privileged-setting')) { | ||
throw new Meteor.Error('error-action-not-allowed', 'Editing settings is not allowed', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually failed the saving of multiple settings on the first permission violation. Since now multiple settings can be saved at once and some may fail while others wont, I moved this error handling into a loop down below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ggazzo I now successfully merged the feature to 1.4-develop
.
To me, it feels as if it was good to merge.
Switching between chat permissions and setting permissions is not beautiful, but given the fact this is not a core interaction, I'd consider it "ok".
It was great if we could get this merged, since it's a must for corporate, as per our compliance guys
@@ -0,0 +1,38 @@ | |||
import _ from 'underscore'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The setting collection was used twice, so I refactored this into an own file.
Since the setting permissions are based upon permissions, the change of permissions needs to be synced first
…8771-fine-granular-settings-permissions
…' of github.com:assistify/Rocket.Chat into core/RocketChat#8771-fine-granular-settings-permissions
…' of github.com:assistify/Rocket.Chat into pr/8942-mrsimpson-core/RocketChat#8771-fine-granular-settings-permissions
@sampaiodiego could you review this code plz? I'm not worthy anymore (because I change the code a lot) =/ =) ... ps: last thing I know, we have to move the streamer to |
…' of github.com:assistify/Rocket.Chat into pr/8942-mrsimpson-core/RocketChat#8771-fine-granular-settings-permissions
Closes #8771
@RocketChat/core This PR adds the ability to allow a role to change only dedicated settings.
This is necessary in order to e. g. allow a user to change the colors of his Rocket.Chat without compromising critical settings such as LDAP-connectivity.
Though the actual purpose is already fulfilled, this PR has to be considered WIP due to the limitations mentioned below.
@Developers (particularly frontend-developers): I need assistance to fix the "final" (mostly UI) bugs
What works
What could be improved
Impressions
Configuring the permissions
There is one explicit permission which makes the whole set applicable.
Whether this is a good idea, I am not convinced myself. The permission could be determined.
Effect