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. Prior to Collections 1.17.2, this $ADMIN role also always overruled any restricting access rights on elements of the application based on the application id: each Collections application (library, archive, xplus etc.) has its own id and this id combined with limiting access rights is commonly used in our model applications to hide certain data sources, access points or fields from view because they have no place in that particular application while they do in some other application. Because those application id-based access rights were always overridden, $ADMIN users would not only get the extra functionality but also some out-of-place data sources and such, causing a confusing impression. This has been remedied in Collections 1.17.2 so that $ADMIN users get to see the application as intended while still having access to the extra administrator functionality.

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.