I am seeing a difference in the ADMIN value inserted into the ARSUSER table for each time the User Type is updated. Here is the scenario.
1- We started with OD v9.5.0.2 with a list of created users in DEV
2- We exported these users to PROD.
3- We added new users to PROD.
Upon adding new users in PROD, we noticed the value in the ADMIN field is different for users of the same User Type.
New Users ADMIN values for specific User Types
8192 User
8200 User Administrator
8208 Application Administrator
8196 System Administrator
DEV Original Users ADMIN values for specific User Types
0 User
8 User Administrator
16 Application Administrator
4 System Administrator
Does that constitute a potential problem?
There's another checkbox / radio button that's selected, changing the value of that field. Look around at different settings to see what's different between them -- did you set the password expiration field to something different, etc?
-JD.
The password expiration field is the same and has not changed.
I'm inclined to say that if there isn't a functional issue, then don't worry about it. You're peeking under the covers, but it seems like everything is working fine.
If you're curious as to how this works, it's called a 'vectored field' or a 'bitfield'. Check out this example from the ARSAGFLD table in the CMOD wiki:
https://cmod.wiki/index.php/Content_Manager_OnDemand_Database_Tables#arsagfld.mask
-JD.
Vladimir,
Here some samples I've understood for my 9.0 CMOD version.
The single problem with this is to forbid a fine analisys in order to report them to your security desk.
USERID Codes - Champs cliqu�s ; tous ceux non mentionn�s sont non-cliqu�s --------------------------------------------------------------
------ ---- ------------------------------------------------------------------------------------------------------------------------------------------
xxxxxxx 8192 "User"
xxxxxxx 8200 "User Administrator"
xxxxxxx 8208 "Application Group/Folder/Cabinet Administrator" simple
xxxxxxx 8196 "System Administrator"
xxxxxxx 8208 "Application Group/Folder/Cabinet Administrator" simple
xxxxxxx 9232 "Application Group/Folder/Cabinet Administrator" + "Hold Administrator"
xxxxxxx 9296 "Application Group/Folder/Cabinet Administrator" + "Hold Administrator" + "Create Users"
xxxxxxx 9360 "Application Group/Folder/Cabinet Administrator" + "Hold Administrator" + "Create Groups"
xxxxxxx 9424 "Application Group/Folder/Cabinet Administrator" + "Hold Administrator" + "Create Gorups" + "Create Groups"
xxxxxxx 1025 "Application Group/Folder/Cabinet Administrator" + "Create Holds"
xxxxxxx 1030 "User" + "
xxxxxxx 8256 "User" + "Create Users"
xxxxxxx 8320 "User" + "Create Groups"
xxxxxxx 8193 "User" + "Create Application Groups"
xxxxxxx 8194 "User" + "Create Folders"
xxxxxxx 8704 "User" + "Create Cabinets"
xxxxxxx 1024 "User" + "Create Holds"
xxxxxxx 8384 "User" + "Create Users" + "Create Groups"
xxxxxxx 8385 "User" + "Create Users" + "Create Groups" + "Create Application Groups"
xxxxxxx 8387 "User" + "Create Users" + "Create Groups" + "Create Application Groups" + "Create Folders"
xxxxxxx 8899 "User" + "Create Users" + "Create Groups" + "Create Application Groups" + "Create Folders" + "Create Cabinets"
xxxxxxx 1094 "User" + "Create Users" + "Create Groups" + "Create Application Groups" + "Create Folders" + "Create Cabinets" + "Create Holds"
xxxxxxx 1089 "User Administrator" + "Create Groups" + "Create Application Groups" + "Create Folders" + "Create Cabinets" + "Create Holds"
xxxxxxx 8448 "User" + "Disable User"
Regards, S.ZANCANARO
Thank you, that's very helpful info.
Again the same things happens all the time...
PLEASE DO NOT DO A QUERY IN THE DATABASE IF YOU DON'T KNOW WHAT YOU ARE DOING.
I don't care if you have done it for 15 years, and it was always OK. because THIS IS NOT OK.
If you do that, then you are dependent on the good will of the CMOD dev that don't change the ARS tables. If they had new fields, or change something, then you are in deep sh%t.
Every BIT on a field in CMOD has a meaning. Like what zancanaro shows... it gives the value, but doesn't give the explanation of each bit, which is also useless. And in the next version if they add new type of admin, or whatever new type of user, then this list will be obsolete... and they could also change the code as they wish...
My STRONG advice, and this will be valid even if the CMOD dev will change the whole database structure (and they can... without any warning, since they didn't document in detail what they are doing in the tables).
Will be to use ARSXML to get all the information you want from the users.
You can also do it in java with the method ODServer.xmlParse(...).
Regards,
Alessandro
Just seconding what Alessandro has to say about querying or manipulating the database directly -- the fields are undocumented, and the values used inside those fields HAVE changed in previous versions, and are subject to change at any time, for any reason, with no notification.
-JD.