What's the main use of groups?

Groups are large collections of users for access-control purposes, spanning multiple spaces. They also typically come from existing user identify systems such as LDAP (Atrium Groups can be tied to LDAP Groups).

Groups can have a hierarchy similar to spaces. For example: "Employees of the NY Office", and "Employees of the San Fran Office" can be rolled into a parent Group "Employees". Typical groups I've seen on real-life OA sites include: "Executives", "Store Managers", "Regional Managers", "Students", "Faculty", "Developers", "Project Managers", etc.

A common use-case where Spaces are specific "Projects" that have a Project Manager assigned as a member is to set "Project Managers" as the notification group. Then, if you remove PM A from the project and now assign PM B to the project it will still notify the "current" project manager. This means you don't have to hard-code the notifications to specific users but can make it more role-based.

Groups are often used in OA in place of traditional Drupal Roles.

This diagram from docs.openatrium.com might help too: http://docs.openatrium.com/system/files/oa2_terminology_and_privacy.pdf

This might help too: http://docs.openatrium.com/content/spaces

Perhaps we could put that useful diagram up on the d.o docs page mpotter? I find the docs.openatrium.com site quite hard to find stuff on.

To add to the examples, we currently use Groups to organise users (as mpotter suggested). So we have a structure where our spaces all inherit users from different Groups, depending on who we want to have access to them.

Then, if we want to assign particular people to be maintainers for a the content in a space, we assign them as members of that space directly.

In our case, inherited users 'see' and direct members 'do'.

Typically our Groups have over a hundred people in, so it's much easier to manage users this way.

Hello John.K, you wrote:

Then, if we want to assign particular people to be maintainers for a the content in a space, we assign them as members of that space directly. In our case, inherited users 'see' and direct members 'do'.

Just a (noob) question: single members that were added directly to a particular Space or members (of a Group) that were inherited through a Group by that particular Space aren't the same thing from the point of view of the Space? isn't it or I missed something in between?

If so, doesn't this mean that direct members assigned (no matter in which way) to a Space should also have a special status (Members promoted Administrators) on that Space to be able "to interact with" and not only "to passively visualize" the Space's content?

I mean: users - directly added as members of a Space or just inherited members through a Group - shouldn't be specifically Administrator of that Space to be able to interact with and not only see the Space's content?

Probably I'm wrong and I missed some important differences here...so I ask.

Kind regards, Davide.

Hi dpoletto.

The space doesn't necessarily see 'inherited' members the same as 'direct' members. When a Group (or Space) inherits users from another Group (or space) you can also set whether you want the inherited users to have the permissions of the parent group, or the permissions from the current Group.

We use this functionality, so members of the group can see content, and members of the space can interact with content, without needing to be 'administrators' in that space.

So it's not just the notifications functionality that treats inherited and direct members differently - the whole permissions structure can as well.

I hope this clarifies things a bit.

I think I have already stated that in the future there will be an option to "Notify inherited members" that would allow this (assuming your Group is assigned to the space for access purposes). You don't want to send notifications to users who can't access the space (they'd click a link from email and get access denied in a private space).

But Groups are more for Access Control and less for notifications. Groups are typically large collections of users and you don't want to spam thousands of users just because some content changed in some space that they are not even members of. Open Atrium makes the distinction between "active participation" (a direct Member of a Space) and "view access" of information (inherited users from a group or parent space).

Teams can only have users who are already members of the space. So again, even with Teams you can't notify outside of your space.

Open Atrium is designed with Spaces acting as microsites of information where control and moderation is at the Space level not at the site level. Sending notifications outside of these boundaries is not the normal use case. You can always use the Rules module to fire off global notifications, or write custom code for that. But it is beyond the normal use case of collaboration spaces. The design here is to focus users on the content most relevant for them and not spam people with notifications about stuff they are not interested in.

In any case, I think this has been discussed enough here. The current system is "by design" and features are in the roadmap to enhance this. That's all that can be done now without writing your own custom code.