Super User Functional permission:
In the previous release, whoever install the MDS originally, is the server admin. The user will have user id 0. There is no easy way to transfer server admin from one user to the other. It will require DB admin go the user table and change SID on user id 0. There is no easy to have multiple server admins or give server admin permission to a group.
New Super User functional permission is introduced in this release. Super user has the same permission as user id 0 in the previous releases. It can be assigned in same way that assign other functional permission. It can be assigned to user or group.
Model Admin Permission:
In the previous release, model admin permission is implicitly assigned based on some calculation result. If user only have update permission on the model level and do not have any other permission in the model sub tree, the user is model admin. If someday later, user got another explicit permission assign in the model sub tree, such as entity level, the user will lose model admin permission.
New explicit Model Admin Permission is introduced in this release. The admin is available on the model level.
Granular Access Permission:
In the previous release, we have Read-Only and Update permission. It is similar to R/RW permission, where RW permission means all the permission including Create Update and Delete.
And we have been seeing more and more user case requires more granular permission than RW, especially spit delete/create from update. So user can only update the master data but cannot create or delete the data.
So we introduce 4 granular access permission Read, Create, Update and Delete. They can be used together. For example, Create+Update means user can create and update but cannot delete.
Since it does not make sense user only have Create, Update or Delete without Read permission, so when assign Create, Update and Delete permission to user, Read is given automatically. For example, assign user Update permission, the UI will show user has Update and Read permission.
Comparison:
|
Previous Release |
Current Release |
|
User Id 0 |
User has Super User functional permission |
|
User has update permission on model and doesn’t any permissions in the subtree |
User has Admin Permission on model |
|
Read-Only |
User has Read Access Permission Only |
|
Update |
User has all 4 Access Permission. Shortcut in UI in All |
|
Deny |
Deny |
The user with old permission will be converted to new permission, during upgrade.
You can find more information at: