How to set different different permissions within a large organisation easily?

Question

I would like to setup a wiki for my team using confluence.

This needs to be internal only and therefore private. I would like members of my team to have editing rights, but all members of the organisation to have read rights.

Is this easily done considering the organisation is large? I have seen in other forum posts that users may need to be added individually, which is not an option here.

Fabienne Gerhard · Answer

You're most welcome @[deleted]! Please feel free to ask for further help if needed.

If my answer helped, you can also click on 'Accept answer' to help other people who browse for help to find it.

Thanks in advance

unknown · Answer

Thanks a lot Fabienne. This answers my question well.

Florian_8erf7n · Answer

We use a plugin called „Custom Space User Management (CSUM)“. It does two things. First it helps us to keep naming conventions for groups. Second it moves user management to the spaces. So space administrators can add or remove (existing) users from their spaces.

Our naming convention is as follows:

For system access we have three groups

__conf-admin, __conf-user and __conf-user-ext. These groups decide whether a uses can login or not (member of __conf-user or __conf-user-ext). The difference is only if a user is an internal employee or an external partner. Users in __conf-admin have administrativ rights on system level. All (except a hand full of test users) user accounts actually are imported via LDAP. So we do not have to create users manually. In this level the group names start with double underscores.

Then we have a second level. The space users. Each space has at least two groups starting with one underscore followed by the space key and closed by the “role” users have in this space. So we have a group _xxx-sa for space administrators and a group _xxx-se for space editors. Optionally there can be more groups like _xxx-manager or _xxx-finance. These additional groups are used for page restrictions only. The permission scheme of each space looks completely identical _xxx-se can read, write, delete stuff. _xxx-sa can the same as _xxx-se plus admin and export. All other (optional) groups can just read. Now that we have our groups we put users to these groups. At least one administrator (better two for redundancy) and many editors. This works quiet well for us. Then we train our space administrators how to add and remove users from their space using CSUM. As a system admin I only need to get involved when a user without a valid license should be added to one of the spaces. Then I just put this user into one of the __conf-xx groups. Done.

CSUM ensures that the naming convention is kept and that space administrators can only modify groups that belong to their spaces.

When you use Jira and Confluence together you can do it even better. Attach Jira to your LDAP to retrieve all user accounts. Then attach Confluence to the Jira embedded CROWD server. Now you have a common user base for both systems. With CSUM you can manage all groups in Confluence but use them in Jira also. So you can use _xxx-se in a Jira project put it in the role of a project user. When you stick to the principle one space one project, user administration works like a charm.