Hello all. I am new to Jive and have the following question.
We are using Jive 22.214.171.124.
We would like to allow a well-defined population to collaborate using Jive. All of the features we want are provided by Jive’s social groups. Users can create their own (open/membership/private/hidden) social groups and invite others. However, we have a hard requirement that an additional access control be applied when accessing these social groups: at the time of creation, a social group owner would indicate the permission group(s) to which all users must belong in order to access the social group, regardless of membership status to the social group. So, it’s not enough that a user has been invited to the social group in order to access it, the user must also be in the permission group(s) allowed to access the social group.
Option 1: Use Customized Social Groups
We could not find out-of-the-box Jive functionality to allow for this. Jive does allow permission group access control for *all* social group. However, we don’t want such a universal approach. We want to be able to selectively apply permission groups to social groups on a case by case basis. So, we thought about customizing Jive’s social groups as follows:
- Allow a social group owner to indicate the permission groups required to access a social group
- Add checks within Jive to enforce this access control
How easily can the “create social group” web interface be customized?
For access control enforcement, we were thinking we would implement a plugin, via a servlet filter, that checked every social group related resource request URL on the server to ensure the user belonged to permission group(s) (if any) that protected the social group. One issue here is recognizing all the various URLs that are related to a social group (e.g., using the context path in some cases, “container id” in other cases, etc.). How feasible is this?
Option 2: Used Customized Spaces
As a second option, we thought about using Jive spaces, since they provide for fine-grained access control on a case by case basis while also providing most of the same features as social groups. The idea would be to designate a space to which this user population has admin permissions, and underneath which users can create their collaboration area as subspaces. The problems with this approach are:
- It is undesirable for users to have admin permissions to spaces (even if in a limited fashion in the form of this one designated space)
- We would still require customizing the web interface for setting permission groups for this space (for example, we would want to remove the individual user override capability – long story)
- We lose the membership and invitation features of a social group, something that is undesirable.
The ability for self-service in order to create these sub-spaces on demand is also an important requirement, so we cannot simply place administration responsibilities for the subspaces on community manager(s).
Option 3: Use Separate App to Create Spaces
As a third option, we would create a small app (not sure if it can be a Jive app or an altogether external web app) that would allow users to create their subspace, under some designated space for this purpose, on demand and handle invitations to users also. None of the users in this case would be space admins, only participants. The app would have to proxy through a backend service we create in order to send requests to our Jive instance with designated (“hard coded”) space administrator credentials and utilize the v3 REST APIs to provision subspaces and set their permission groups. One issue with this approach is that it does not allow the user creating a subspace to customize and manage the home page for that subspace (Overview/Activity), which is an essential feature.
Is there a way to provide a space/subspace participant with the ability to manage the subspace home page without giving them space admin permissions?
Thanks in advance for any input!