Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Updated: Comment #4
Problem/Motivation
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
TBD
API changes
TBD
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).
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 2117791-og_access-install-13.patch | 10.03 KB | Devin Carlson |
| #13 | ScreenShot-OG-access-intsall.png | 44.95 KB | rosemeria |
| #12 | 2117791-og_access-install-12.patch | 1.62 KB | japerry |
| #10 | privacy_settings_description-2117791-10.patch | 1.15 KB | Matt V. |
Comments
Comment #1
ezra-g CreditAttribution: ezra-g commentedDid you enable the OG_Access module?
Comment #2
runeasgar CreditAttribution: runeasgar commentedHad 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.
Comment #3
ezra-g CreditAttribution: ezra-g commentedYes :) - 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.
Comment #4
runeasgar CreditAttribution: runeasgar commentedI 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:
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.
Comment #5
japerryruneasgar, 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.
Comment #6
japerryerr 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.
Comment #7
runeasgar CreditAttribution: runeasgar commentedComment #8
runeasgar CreditAttribution: runeasgar commented@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!
Comment #8.0
runeasgar CreditAttribution: runeasgar commentedUpdated issue summary.
Comment #9
gaele CreditAttribution: gaele commentedWell, 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?
Comment #10
Matt V. CreditAttribution: Matt V. commentedI'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.
Comment #11
japerryBy 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):
and og_access enabled:
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.
Comment #12
japerryHere is a patch to enable og_access during the install phase.
Comment #13
rosemeria CreditAttribution: rosemeria commentedMessaged needs to be altered:
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.
Comment #14
Devin Carlson CreditAttribution: Devin Carlson commentedAn 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).
Comment #15
Devin Carlson CreditAttribution: Devin Carlson commentedTested #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.