Updated: Comment #4


It is unclear that og_access must be enabled in order for group privacy settings to work.

Proposed resolution

The docs should be updated to be clear that Commons 3.3 and higher also require og_access to be enabled - not just Commons 3.2. In addition, I feel that the create group page should really provide some kind of indicator that the privacy settings will not work properly without taking additional steps that are outlined in the documentation.

Remaining tasks

  • Update documentation to clearly indicate that og_access is required for group privacy settings to work properly in Commons 3.4.
  • Add explanatory text to create group page to indicate that privacy settings will not properly hide content unless og_access is enabled (or unless instructions in docs are followed).

User interface changes


API changes


Original report by @runeasgar

In group "Privacy Settings" there are 2 options that indicate that content will be hidden from non-members:

  • Joining a group requires an invitation - In the documentation, it is stated that this setting has the following effect: "The group and its content are hidden from non-group members."
  • Joining requires admin approval - In the documentation, it is stated that this setting has the following effect: "The group is visible to non-group members, but its content is hidden, and a group administrator must approve the users' group membership requests."

I created 2 groups on stock Commons 3.4 using these 2 settings, then created test content in both (posts, questions, polls). In both cases, the group content was exposed and viewable (node display, as well) by authenticated non-members (home page - main section & recent activity) and anonymous users (just recent activity, since the main section is different).



Status:Active» Postponed (maintainer needs more info)

Did you enable the OG_Access module?

Status:Postponed (maintainer needs more info)» Needs work

Had not - did now. Also rebuilt permissions per Drupal's notification. However, this only partially resolved the issue.

The recent activity block no longer shows "hidden" content to authenticated non-members or anonymous users, but the home page "What's Going On?" section still experiences the same problem.

Also, as kind of an aside, did I miss some instruction on the site telling me to enable the og_access module? The "Privacy Settings" section of the "Create Group" page doesn't seem to indicate that any modules need to be turned on in order to make the privacy settings work properly.

Status:Needs work» Postponed (maintainer needs more info)

Also, as kind of an aside, did I miss some instruction on the site telling me to enable the og_access module?

Yes :) - https://docs.acquia.com/commons/develop/group-privacy .

It's not clear from your followup comment which content in which groups is visible to which users who shouldn't be able to see it. Can you be more specific?

Note that per the description on the group privacy fieldset, you'll need to re save any content inside the group once the OG access module is enabled/group privacy settings are changed.

I started over from scratch out of concern that the test scenarios I had previously set up weren't a good testbed. This time I succeeded by preemptively enabling og_access, rebuilding permissions and clearing caches before making my first "private" group. I got the expected results from both authenticated non-members and anonymous users. That said, I still see 2 UX concerns:

  • Went to the create group page and looked for any indication that I needed to turn on og_access or go to the docs in order for the "Privacy settings" to actually work. I saw no such indication, so I think any normal user would assume that simply selecting the appropriate privacy setting would have the desired result.
  • Went to the docs anyway (https://docs.acquia.com/commons/develop/group-privacy) and looked for any indication that I should turn on the og_access module on Commons 3.4 in order for privacy settings to work. I saw that it was mentioned under 3.2
  • but not under 3.3 and higher. As a normal user, I would assume that og_access is not required for 3.4 privacy settings to work.

I will update the ticket accordingly.

Status:Postponed (maintainer needs more info)» Fixed

runeasgar, I think you make some very valid points. Its not intuitive to an end user without reading all of the documentation, including previous versions, on how to create private groups.

Most people I think start playing with a site and might get pretty far before running into this issue, and the fact that we don't currently have a bulk way to make content private is, annoying at the least.

This private vs public content has been pretty much solved with forum software. It might be good for us to see what UIs they provide to make this more usable in commons.

Status:Fixed» Needs work

err marking needs work. Because its still very easy for what people think is 'Hidden' group content to be visible after marking a group as hidden.

Title:"Hidden" group content visible to allUnclear that og_access is required for group privacy settings to hide content
Category:bug» task
Priority:Major» Normal

@japerry: This project is an intranet with significant privacy concerns, which they have wrestled with Commons with in the past. I think the stakeholders would be grateful for some thought/improvement in this arena. Thanks!

Issue summary:View changes

Updated issue summary.

Category:Task» Bug report

Well, this clearly is a bug to me. The interface should not state things that simply are not true. So it should not state "The group and content is hidden from non-members" if og_access is not enabled, at least not without context.

Sorry if this sounds frustrated. I inherited a site made by another developer, who overlooked that og_access needs to be enabled. This site is already in production. Am I correct that I now need to manually resave all group content?

Version:7.x-3.4» 7.x-3.x-dev
Priority:Normal» Major
Status:Needs work» Needs review
new1.15 KB

I'm attaching a patch that updates the description for the group "Privacy settings" a bit. It's arguably not the best way to accomplish this, especially since the description is exposed to end users but only an admin user can add the module and rebuild permissions. However, I'm hoping this will help move the discussion forward.

By default, without og_access enabled, the group privacy settings do not say anything about any of the three groups being 'private'. Unfortunately, the word 'privacy' implies a certain amount of privacy, and lack of wording we have in there currently is insufficient.

For example (og_access disabled):

Joining requires an invitation

and og_access enabled:

Joining requires an invitation. The group and content is hidden from non-members.

For us, as developers, we -know- what that means, but if you never have installed og_access before, you don't know that that 'joining requires an invitation' really means 'joining requires an invitation. Content is still visible to all users'

A caveat should be added on the field that without og_access, there is no privacy for any of the options.