Manage user groups

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

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 proof-read 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.

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.

There are three ways to create, delete, and populate groups in censhare:

1. Groups can be created as master data and assigned to users in the censhare Admin-Client. This is the traditional approach for system administrators.

2. Groups can also be created and populated in the censhare Client by common users (sufficient privileges provided). This feature was introduced in censhare 3 to allow the ad hoc creation of teams without administrative overhead. Its excellent overview of groups and their members and drag&drop user assignment became so popular, that even system administrators often choose to maintain groups in the censhare Client.

3. Groups can be created from remote directory services based on the Kerberos protocol.

Technical background

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 highspeed 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.