Users can be organized in groups.

Concept

It is very important to distinguish the terms group and role in censhare.

User groups

A group in the censhare terminology has nothing to do with permission or privileges at all but simply provides collective receivers as collaboration targets. When an asset’s workflow target is assigned to a group, this asset will show up in the task lists of all members of this group. When a message or email is sent to a group, it will be delivered to all members of this group. Groups are used as workflow targets when the receiver is not a single person but rather a more abstract responsibility. A typical example would be the group of copy editors: for most of the time, the editor does not care which copy editor will proofread his text. Instead, to a dedicated person, he would rather send the text to the group copy-editors. The text will show up in the todo-lists of all present copy-editors and the first one available will start to work on the text.

User roles

On the contrary, a role in censhare means a very different concept, where common permissions are assigned to the users belonging to the role. A role cannot be addressed like a group, but controls which actions and user interface settings become feasibly for the users of that role. Roles and groups in a censhare system can be completely different regarding their members and names, but it is also very common that the same names and members show up in the roles and the groups, as very often departments have common privilege defaults for their employees. Administrators and project managers should carefully use both terms in their respective contexts to avoid confusion.

User groups in the database

censhare groups are stored in the database in the table party. This is the same table in which the standard user accounts are stored. The flag isgroup differentiates users from groups in the party-table. Just like users, user groups can be made invisible and inactive (but there is no practical purpose for that except to temporarily hide a group for some reason). Affiliations between groups and users are stored in the tables partyrel and partyrel_flat (the latter being an optimized copy of partyrel for high-speed search purposes). The user groups are uniquely identified by a system-generated ID that shares the number space with the user IDs. The names of user groups are supported by the system localization and can be changed at any time in the running system.

Create user groups

For more information, see Authorization mapper.