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).


ezra-g’s picture

Status: Active » Postponed (maintainer needs more info)

Did you enable the OG_Access module?

runeasgar’s picture

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.

ezra-g’s picture

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.

runeasgar’s picture

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.

japerry’s picture

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.

japerry’s picture

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.

runeasgar’s picture

Title: "Hidden" group content visible to all » Unclear that og_access is required for group privacy settings to hide content
Category: bug » task
Priority: Major » Normal
runeasgar’s picture

@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!

runeasgar’s picture

Issue summary: View changes

Updated issue summary.

gaele’s picture

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?

Matt V.’s picture

Version: 7.x-3.4 » 7.x-3.x-dev
Priority: Normal » Major
Status: Needs work » Needs review
1.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.

japerry’s picture

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.

japerry’s picture

Here is a patch to enable og_access during the install phase.

rosemeria’s picture

screen shot, install

Messaged needs to be altered:

If you only need public groups and want maximum performance, disable this option. Otherwise if you plan on using private groups or trusted contacts, leave this setting enabled.

1) Group Privacy Option is not showing as enabled but message implies it is - '#default_value' => FALSE
2) Message should read something like.... "Disable this feature if all your groups are open and available for any site member to contribute to, this also maximizes performance. Otherwise leave this setting enabled if you plan on using private groups or trusted contacts."
3) The word "public" can be confusing, we should stick to "any site member can contribute"
4) If og_access is enabled during install it shows message error "The content access permissions need to be rebuilt. Rebuild permissions." on entering your new site.

Devin Carlson’s picture

An updated version of #12 which improves upon the wording using suggestions from #13 and adds an installer step which rebuilds node access.

With the addition of og_access and rebuilding node access, some installer steps were bumping up against PHP's max execution time, so additional operations were consolidated into a single batch operation (enabling Acquia network connector modules, enabling OG Access, installing demo content, etc).

Devin Carlson’s picture

Status: Needs review » Fixed

Tested #14 with a number of fresh Commons installations to verify that the installation process and all of the configuration options continued to work properly in addition to the new private groups checkbox.

  • Commit 3668d50 on 7.x-3.x authored by Matt V., committed by Devin Carlson:
    Issue #2117791 by Matt V., japerry, Devin Carlson: Added the ability to...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.