is_admin in OKAPI code

[kojoty]

Hi @following5

OCPL is going to introduce "role" in place of "admin" column in user table.
Role will be column with type SET in DB and many roles can be assigned to user.
Column admin will be removed.

Currently there is "is_admin" field in OKAPI code which read "user.admin" column from DB.

What is the best way to deal with it in OKAPI code?

[following5]

For OCDE is_admin never made sense (see #410). Generally it is of little use; I will just make it return null.

[kojoty]

thanks!

[following5]

Just noticed that for backward compatibility, we should return false instead of null in certain cases. Anway, the user.admin database field is no longer accessed by Okapi and can be removed.

[following5]

Something like the is_admin flag will be needed for #565, in the meaning of OCPL ocTeamMember role and OCDE ADMIN_USER flag.

@kojoty
Can you tell we what advUser is intended for? Will those advanced users have some of the access rights that now the ocTeamMembers have, or is it for something else?

[kojoty]

@kojoty
Can you tell we what advUser is intended for? Will those advanced users have some of the access rights that now the ocTeamMembers have, or is it for something else?

Hi @following5
For now OCPL has 4 roles:

• ocTeamMember - member of OCPL COG - generally same as is-admin flag before
• advUser - users with access to tested features - for now this is only under /test controller
• sysAdmin - users with rights for technical administration - for example access to APC control menu etc.
• newsPublisher - users with rights to post news on start page of the service

Every user can has no role or even all roles assign at once.

I would like to remove is_admin from code and DB.

[following5]

So OCPL ocTeamMember flag is identical to OCDE ADMIN_USER flag.

The DB field user.is_admin can be removed now. OKAPI would use the new user.role field instead. We may still name that is_admin in the data returned by OKAPI, or chose another name.