RFC: "Gated" (or "Walled") Groups

I've started a ticket with a pull request that proposes in 1.9 to separate group content content access restrictions from group membership policy, but I'd like some feedback here on 

I propose that the group_gatekeeper() function, instead of considering membership policy ("open" or "closed"), should instead protect content based on whether or not the group has a gated flag. The presence of the "gated" flag on a group would specify that no group content should be visible to non-members. The flag would be independent of membership policy.

The pull request aims to be backwards compatible, so that group owners would have to manipulate the group settings intentionally to make a closed, ungated group or an open, gated group (both cases impossible in 1.8); and so that the 1.9 upgrade would not need to read/alter the metadata of every group in the system.

New use cases

  1. Closed membership groups that need to expose some content to the greater community/public (worked before 1.8, used very much by my users)
  2. Enticing users to join open groups by restricting all content to members, even when existing content has permissive access levels.

Background: In 1.7, due to a bug in pages, group_gatekeeper() did not block access to pages in closed groups. The pages code was fixed in 1.8 so that closed membership groups effectively eliminated the PUBLIC and LOGGED_IN access levels for content within the group (forcing them to be like mini walled gardens).

I see this relatively new behavior as an unintuitive bug; a closed membership policy should not silently remove the ability to make content visible to non-members.

Comments?

Would this change be welcomed?

Maybe "walled" would be a better metaphor than gated. After all, you can see through gates, but generally not walls. Gated makes more sense W/R/T the group_gatekeeper function name, but for users?

  • I failed to mention that in either case, some kind of indication should be given to content creators that some access levels they choose will effectively not work; or those choices should simply be removed if the group is walled.

  • Very much in favour - have had to put all sorts of workaround in because this isn't dealt with in a consistent way at the moment!

  • @Nick, do you mean inconsistent behavior, as in bugs? if so, are they reported?

  • Definitely a welcome change. Especially use case #1 is often requested by users.

    "Walled garden" seems to be generally recognized term so maybe "Walled group" could be better name for the functionality.

    http://en.wikipedia.org/wiki/Walled_garden_(technology)

  • Hi - yep I have reported the main one I've found, which is inconsistency between how open content in closed and hidden groups is accessible (and shows correctly in the river), but open content in closed but visible groups is not accessible.

  • An extra gated flag would be most welcome and is a very good idea for 1.9, and should definitely be a separate issue to openness to membership. However, it seems to me that the 'visibility' attribute should be doing much of that already in 1.8. Permissions within a limited-visibility group should be limited for individual posts to the limit of what visibility allows and no more, otherwise it is quite illogical. If that loophole were closed then it would effectively gate the group and would be consistent with common sense. Proper gating would be much more useful, but that simple consistency tweak could deal with quite a few use-cases.

    Right now, the big inconsistencies in closed groups that I've found are that:

    1. individual blog, files and bookmarks can be seen, in full, inside a closed group if permissions allow (and appear in the activity stream and search results), but it is not possible to see a list of them within the group, despite the option appearing on the group submenu to non group members. I'd say the bug is not that the menu items and posts are shown, but that the listings are not shown.
    2. Discussions and Pages allow neither individual posts nor listings to be visible, though both appear in the group submenu options and both appear in the activity stream, whether you are member of the group or not.
    3. Some third party plugins (e.g. polls, events) allow both listing and viewing of individual posts, presumably by not using group_gatekeeper(). That highlights the inconsistencies because their behaviour is what would logically be expected.
    4. Widgets are invisible. Not at all clear why, given that they will only show what they are allowed to show.

    These inconsistencies are big enough to describe as bugs. I'd suggest, as a bug fix for 1.8, that:

    1) submenu items that are shown should allow browsing of all visible posts. It makes no sense to allow an individual post to be seen but not to be able to browse those that are visible. 

    2) widgets should be visible. 

    3) discussion posts and Pages should be visible. If people have set permissions to allow it, then the permissions should be respected and this would make them consistent with the rest (and with expectations)

    Maybe this is for 1.9, but I'd also suggest making  group posts default to the group's access control so that revealing a post is a deliberate act - that's just a usability tweak, though, not an inconsistency like the rest. Defaults are powerful things!

  • @jondron Do you mean group_gatekeeper is not being used consistently and should be? You should try my branch for 1.9. No time to look up the link right now

  • @jondron Can you flesh out your suggestions in more detail? Are you suggesting we not use group_gatekeeper on the search pages, and always show the widgets area?

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.