Spaces & Groups inheritance & permissions

Hi, I can help you with this, but might need more information. You say you're trying to set up a basic site but also that you've taken over a pre-existing site. What exactly are you trying to do and what problems are you running into? In general, out of my own experience (and the Phase 2 pros are likely to have a different perspective), I don't use the "groups" functionality. It's the only Atrium functionality I never use. I just don't find it useful. (I do like the "team" content type and functionality a lot, however.)

-- I've found the "site map" functionality (http://drupalgroup.mit.edu/sitemap/#/) to be a hidden gem in Pantheon when it comes to setting up the basic structure of a site, and also when trying to explain Atrium to other users.

-- Which version of Atrium are you running? If it's not 7.x 2.60, can you update to that easily?

But provide a bit more information and I can help walk you through some of this. I've been meaning for the longest time to set up an Atrium Users Group (http://drupalgroup.mit.edu/), so any questions you ask may push me to do that.

You sound like you're making good choices.

1. Even when I start with an Atrium distribution on Pantheon, I sometimes make a change that breaks the connection for automatic updates from Pantheon. When Atrium doesn't recognize something in profiles/openatrium, it treats the distribution as a Drupal distribution, not Atrium. In other words, the person who came before you may not have done anything wrong. He just made a change that prevents Atrium from recognizing itself. In general, the only change I make to the default Atrium distribution is to move the current theme from profiles/openatrium/themes to sites/all/themes. (I use drush to delete it first, then add it.) Everything else I leave completely alone and the Pantheon/Atrium updates go through perfectly. Those updates are a gift from the development gods and you definitely don't want to get in their way.

2. Migrating to a fresh install that you yourself have built is generally the best strategy, I've found. Tedious, but you will really understand everything perfectly when you're done.

3. "But I need to match the current permissions and access structure that's in place on the old/current site."

That's exactly what I wouldn't do. Over the past hour I set up a sandbox site (http://dev-open-atrium-sandbox.pantheonsite.io/) to explore the whole Groups functionality more carefully, and the site just crashed -- in self-defense, I would say, because it realized that the Groups functionality doesn't bring anything to the table. Worse, there are so many possible combinations that it's more Rubik's Cube than site building.

Basically, the idea behind the Groups and Teams content types has little to do with content types per se, but rather with using those content types with Atrium's notification system. When you create new content, whether it's a blog post, a news item, or an event, you can use Atrium's notification to send an email to a team, to a group, or to a individual users. But this notification structure really should be one of the last things you set up. The same is true for permissions and roles and all that sort of stuff. It's important to get that stuff right, but not right now.

1. "I've been able to grant those users content creation permissions by either adding individual members to the space..."

That's the simplest approach, and best imo. Don't forgot that you also make those members administrators, and then they have access to do everything within the group. You can adjust the permissions that are given to the two default group roles (administrator and member) or add new roles with their own permissions.

1. "...or setting the "Group user permission inheritance" to "Child's permissions".

I find that too tedious to keep straight in my head. I like users to have a specific roles and specific permissions. Nesting roles within this or that group is just not worth it, in my opinion. And whoever takes over the site after you move on will not be singing your praises either.

1. "a little more context on the nature of the site..." So I gather that your site is not using Notifications at all. I don't see any reason for your site to be using Groups. Just configuring the roles so that users with a given role can add the content they need to add, is all you should worry about. But you should check out the Team functionality, as I find that really cool, and it solves a problem that comes up often in my own site building, which is keeping track of team members s they change from year to year.

1. "So it sounds like groups and teams are important for managing notifications? "

Yes. Notifications allow you to send an email to let a user, team, or group know about changes on the site, pretty much exactly as we're both receiving emails when one of us posts a comment to this thread.

1. "I'm under the impression that teams are subsets of OA groups..."

No. Teams is simply a content type called "Team," which allows you to easily add a bunch of users to create a "team." So you create teams like "2016 Leadership Team," "Program Administers," etc. Go to the members page for any space you've created (eg, node/1/members) and then click the tab Teams. Create a new team and add members of the current space to it. You can then use that team with the notifications system.

1. "How are you setting up simple content access...?"

You should be managing this through roles and permissions managed by Organic Groups. Organic Groups has fantastic configurability and makes it very easy to add and modify and configure access for various roles (/admin/config/group/group-membership). You'll find the full set of organic group configurations here (admin/config/group).

1. "it doesn't change with any configuration changes you could make on the site."

You're right. I was thinking of when I created a backup of an Atrium site on Pantheon, and then used the three backup files (code, database, and files) to quickly clone a new site. It works perfectly and is very quick, but Pantheon considers it a Drupal upstream repo, not Atrium.

But in any case, your original comment was that you originally couldn't use the automatic updates with an upstream Atrium repo. And that's the reason: something has been changed from the original distribution that Atrium is expecting to find in profiles/openatrium.

No, I don't use teams for either notifications or for access. As I said, I think Organic Groups roles and permissions should be used to control access, and the teams-notification functionality I hope to use once my sites are more intensively used by their communities. Rather, I use teams to solve a problem that I can't easily solve otherwise: Say your company has an executive committee and every year new people are appointed to it. That's the functionality I need: "2015-2016 Executive Committee", "2016-2017 Executive Committee." There tricks you can play with taxonomy and views to handle this, but it's effortless with Atrium's team functionality.

The link to add a new Organic Groups role is a bit buried. Go to this page (/admin/config/group/roles) and edit the Node-Space group type. Add a new role, then configure the permissions. Next, to assign the new role, or any OG role, to users who are already members of a space, go to the space you're dealing with and select the Bulk Manage setting (/group/node/1/admin/people) and assign them the new role.

I do use teams for both access control and notifications and find them very useful.

In my particular case, on a production site with ca. 5000 members, I use them in different logics: the one Ed described (temporary groups of people); project teams (although here you can of course also opt for different spaces/subspaces - we use it for "small/short-term" projects); different teams within a project.

Thank you all for this inspiring and enlightening discussion, we definitely need more of these to grasp and document the full potential of OA.