Application setup: users and roles

Users and roles

If you want to restrict access to certain parts of a Collections application for certain users, you must register all possible users in the concerning application definition. Since Collections recognizes a user by his or her login name in Windows (the name used by a user to log in to a stand-alone computer or local network on which the Collections application is opened in a browser), you must register those exact same names for all users of that computer or network who's access needs to be limited.
You can register everyone of course, but this is not really necessary, since non-registered users have full access to the Collections application by default.

To register a user in an application, you create a new user in the application setup for a specific application and assign it a so-called role, which is a group name for (usually) multiple users that must have equal access rights. You can choose new role names or select existing ones.
One special role is $REST. This role should never be assigned to users explicitly. Its purpose is to be able to specify access rights to the current object for all users who's role has not been assigned access rights to this object and for all users without a role. So if you've defined users and roles in the application definition (.pbk), but for an object you do not assign access rights to these roles, while you do specify that $REST should get e.g. read access, then all users will have only read access. However, by default $REST has not been set anywhere, and if you do not assign access rights to any roles, then all users will have full access.
A second special role is $ADMIN. This role should be assigned to administrator users, but access rights must never be applied explicitly to this role because users who get the $ADMIN role have full access rights by default and even the right to change the name of the record owner and user access rights per record if record authorisation is active for the database. The $ADMIN role and its inherent rights also have priority over access rights assigned to $REST. The $ADMIN role and its rights even overrule access rights for application roles. The latter means that users with the $ADMIN role may get to see a Collections application in quite a different way, namely with all possible detail screens, methods, access points and all possible data sources: this is because in model application 4.2 and higher, application roles are the filter that determines if an object appears in a certain application or not. Since that filter is ignored for an $ADMIN user, he or she gets to see all application objects.
Designer keeps track of existing roles internally.

Remarks

•	User-role combinations may differ per application.

•	When a user logs in, he or she is automatically assigned the appropriate role.

•	You assign access rights to roles, on the Access rights tabs of object properties in the Application browser. Do not use the $ADMIN role: it has full access rights by default, everywhere in the application.

•	If you assign access rights to roles for databases and datasets, these access rights apply to all applications that use these databases.

•	Access rights for roles for objects in a database definition (.inf file) can never be extended by wider access rights to roles for objects in an application definition (.pbk file), only limited.