You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After exploring LDAP integration and the way CS handles account and users I’m sort of confused as to why the system is using two designations for classifying accounts.
If you look in the account database table there are “account types” of:
system / admin = 1
Domain Admins = 2
Users = 0
Then there are multiple “Roles” that specify api access.
Some existing issues with “types” and “roles” include:
-If you try to change an account from a normal user’s role to the domain admin role in the UI and via API it fails. You can change it in the database but you must also alter the account “type” in the database.
-When you try to create a custom role you are presented with copying the permissions from either a “type” or a “role”. When you copy from a role you end up with a blank list of api permissions in the custom role, it doesn’t copy anything. Copying from a “role” works fine and gives you the api permission list from that role.
-When performing a “link domaintoldap” operation for automated account creation upon login you can only specify “accounttype” (2 or 0). This is limited and ignores any custom “roles” you might want to apply automatically.
With these issues, having multiple account classifications seems unnecessarily complex. It would seem simpler to just have account “roles” and manage permissions in one category. I might advocate for getting rid of account “types”, but I’m not sure how integrated they are in the system. They could possibly have a set of account roles reserved for the default system roles, something like (0,1,2) which can’t be altered but could be copied. The “link domaintoldap” operation could allow you to specify a role ID instead that will apply permissions upon login which would be much more useful.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
After exploring LDAP integration and the way CS handles account and users I’m sort of confused as to why the system is using two designations for classifying accounts.
If you look in the account database table there are “account types” of:
system / admin = 1
Domain Admins = 2
Users = 0
Then there are multiple “Roles” that specify api access.
Some existing issues with “types” and “roles” include:
-If you try to change an account from a normal user’s role to the domain admin role in the UI and via API it fails. You can change it in the database but you must also alter the account “type” in the database.
-When you try to create a custom role you are presented with copying the permissions from either a “type” or a “role”. When you copy from a role you end up with a blank list of api permissions in the custom role, it doesn’t copy anything. Copying from a “role” works fine and gives you the api permission list from that role.
-When performing a “link domaintoldap” operation for automated account creation upon login you can only specify “accounttype” (2 or 0). This is limited and ignores any custom “roles” you might want to apply automatically.
With these issues, having multiple account classifications seems unnecessarily complex. It would seem simpler to just have account “roles” and manage permissions in one category. I might advocate for getting rid of account “types”, but I’m not sure how integrated they are in the system. They could possibly have a set of account roles reserved for the default system roles, something like (0,1,2) which can’t be altered but could be copied. The “link domaintoldap” operation could allow you to specify a role ID instead that will apply permissions upon login which would be much more useful.
Beta Was this translation helpful? Give feedback.
All reactions