Permission/privilege transition #133
Replies: 2 comments 1 reply
-
Since v5.43, a user's role has required a permission record to create new DMS messages. This should be documented better. As a starting point: INSERT INTO iris.permission (role, resource_n, access_n)
SELECT name, 'dms', 4
FROM iris.role
WHERE enabled = true
ON CONFLICT DO NOTHING; This gives all roles full permission, but would need to be run again after new roles are created. |
Beta Was this translation helpful? Give feedback.
-
Yeah I did something like that to get us working, it was easy enough to figure out given what I knew. I agree some additional documentation would be better, and a note in the release notes about that change (I see there is one about checking the DMS permission, but clarifying that it requires an additional step to configure would be good). It would probably be ideal to figure out a way to approximately translate the existing privileges into the new permission system (at least in a "close enough" way) that can be added to a migrate script. It would require a little thought, but probably on par with the sign group -> hashtag transition. Maybe not a big priority until more things move over to the new system, but something to keep in mind. If you want some help with that, let us know. |
Beta Was this translation helpful? Give feedback.
-
There is some overlap between the old "privilege" system used by the Java client, and the new "permission" system for the web UI. The current migration scripts create permissions for the administrator role, but all other roles are excluded. Since permissions are checked by the server for some operations, this prevents users in the Java client from performing certain actions that they have the appropriate privileges for. Since permissions are (presumably) only configurable via the web UI (and database), this creates some administrative challenges.
Can you add a note to the release notes that administrators need to consider this when upgrading? I presume you have some way that you're dealing with it at MnDOT that may not work for others, but maybe you can recommend an approach. In our case, since we don't currently have the web client running, I added permissions to bypass those checks to leave things working with the old privilege system for now (which we can revisit when we get around to deploying the web stuff).
Let me know your thoughts on this when you have time. Ideally we could come up with some approach to deal with this in the migrate scripts, at least partially (or perhaps there could be another method for enabling/disabling it). I know eventually you plan to move everything over to the new system, but some way to deal with things in the interim (or at least a prominent warning) would be good. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions