If the creation of or conversion to an extranet space does not work, check if all user directories are available. The Space Privacy app uses a Confluence mechanism which requires a valid connection to all user directories. As a workaround you may disable the broken user directory temporarily.
Required user directory permissions
Space Privacy creates own groups to manage the permissions and visibilities between users. Therefore the user directories configured in your Confluence instance need to fulfill following requirements:
- LDAP (at least "Read Only, with Local Groups") with Confluence Internal Directory
- LDAP (Read/Write)
- Crowd (Read/Write)
Check user directory permissions
After installing Space Privacy you will see a message showing you the status of your user directories. By clicking the link 'Check user directory permissions' or opening '<base-url>/admin/plugins/extranet/config/userdirectories.action' you can see a detailed overview of your user directories and if they are compatible with Space Privacy.
There are only two statuses available:
- WRITEABLE
- READ ONLY
You can see if the app is working without any restrictions from these results, or see where you will have to change your user directory or Space Privacy settings.
Every user directory grants the required permissions
Congratulations, Space Privacy will work as expected!
Not all user directories grant the required permissions
This may not be a problem. As long as you only assign users from "writable" user directories, Space Privacy will work fine. If you allow extranet users to be created, make sure that the newly created users won't be also stored in a "read only" directory.
If you experience problems assigning or creating extranet users which might relate to user directory problems, refer to the section below on changing user directory permissions.
No user directory grants the required permissions at all
When your user directories all grant read-only permissions, Space Privacy will not work by default.
There are two options to fix this:
- Change the permissions of the user directories which are marked as 'read only' (next section)
- Activate the Restricted Mode
Restricted Mode
Space Privacy will inform you if you can only use the app in a restricted mode. This means that:
- The Extranet User Manager administrator role is not available.
- Permissions can only be assigned to users in extranet spaces individually (not to extranet groups). When Managed Groups are not available, as in this case, other functions (like share) are not possible.
If your user directories support Space Privacy without restrictions but the Restricted Mode is still enabled, a note will be displayed that explains this.
Please note that switching between restricted and unrestricted modes is not easy when Space Privacy is already in active use. When you try to do this, all extranet spaces must be reset, but no content will be lost.
Change user directory permissions
Confluence Internal Directory
This is the internal user directory of Confluence and it is not recommended by Atlassian to disable it. This user directory never causes problems with Space Privacy, as it always grants the necessary permissions.
You find more information about user directories here: Configuring User Directories
LDAP
If an LDAP is connected to your Confluence instance, you should edit the directory and set the 'Read only, with Local Groups' option. By default 'Read Only' is set.
Please note, that this option is not necessary if you use the "Internal with LDAP-Authentication" configuration.
Jira Server / Crowd
There is no option “Read Only, with Local Groups” in Jira Server or Atlassian Crowd. You can configure this correctly with the following steps.
In Confluence
Set the option “Read/Write” for the user directory (Jira server or Atlassian Crowd). Set the option “Read Only, with Local Groups” in the tethered user directory.
Crowd
Allow local groups.
Add group permissions (add, modify and remove).
Why are Write permissions required?
Space Privacy maintains the content/space permissions by creating its own set of internal Confluence groups for each individual Extranet space (you're going to notice those in your system, prefixed with "extranet-").
This provides the technical foundation to allow the fine-grained restrictions implemented along with Extranet spaces. While they're only internal groups and not meant to be user-/admin-facing, the group membership still needs to be stored with the user data. So when users are assigned to Extranet spaces, they're added to corresponding groups – depending on what exactly they can see and do in that space. These groups become part of the user profile just like regular Confluence groups, and need to be written into the data source for user profiles in case of external user management.
If you're able to finely control which fields are writable, it should be sufficient to allow write operations on users' group data (add user to group + remove user from group) for Space Privacy to work.