Closed group membership affects access levels on content

[mrclay]

I have a page inside a group, both with access PUBLIC, yet because the group is closed, the use of group_gatekeeper effectively makes the page accessible only to group members.

If this behavior is desirable, we need to add language that "closed" effectively walls off access to all content within (not only membership), and when group content is created in a closed group, the PUBLIC/LOGGED_IN access levels should be removed because they don't work at all.

IMO open/closed should not effectively override the access level of group content. I.e. group_gatekeeper() should not care about $group->isPublicMembership() at all.

[mrclay]

I think the ability to turn a group effectively into a walled garden is useful functionality, but it should be controlled independently of membership policy. E.g. I could imagine it useful to have walled garden groups with open membership (the ability to see what's inside would be incentive to join the group).

[mrclay]

I've determined this is new behavior in 1.8, at least w/ regard to the pages mod. Up to 1.7, group_gatekeeper was called ​before the page owner was set. In 1.8, ​after. While this seems like fix w/r/t using group_gatekeeper correctly, I still contend it creates unintuitive and unwanted behavior.

I propose we introduce a second metadata key "gated" with values "no"/"yes" answering the question "does group_gatekeeper seal off all access to group content from non-members?". If group_gatekeeper found isPublicMembership() to be false, it would pull the "gated" metadata. If missing, it would be set to "no" (return to 1.7 behavior), avoiding the need to touch each group during upgrade.

I'm very motivated to get this in 1.9 because our community running 1.6 (we're working to upgrade ASAP) has a TON of closed groups with public content that would otherwise disappear upon upgrade. Any other 1.7 sites will face the same problems; the hard choice of opening groups or moving content to sister open groups.

[mrclay]

For 1.9: ​https://github.com/Elgg/Elgg/pull/233
This PR would add the gated feature, but unlike my proposal above, would default to the 1.8 behavior (closed groups are gated by default, until changed by owner).

[mrclay]

The PR above now uses the internal terminology "walled" instead of "gated", but ​in the UI calls this "Accessibility of group content" with options "Unrestricted" and "Members Only" with brief explanations. It also handles messages appearing below the group description and displays a dynamic message when a content-level access setting may be overridden.

Perhaps the concept should not be binary and instead support multiple content access models, with methods like get/setContentRestriction only supporting group constants like UNRESTRICTED and MEMBERSONLY for now. This could allow us the option to expand the abilities of group_gatekeeper in the future, while making the API more closely match the UI in the short term.

[mrclay]

​https://github.com/Elgg/Elgg/pull/276 implements a "gatekeeper mode" on the group, and I think is a clearer to understand API, even if we never implement more than 2 gatekeeper strategies. All traces of "walled" have been removed.

[beck24]

This has come up in my list of bugs for the university project - am I right in thinking there's no good way to solve this in 1.8 outside of core?

[mrclay]

Replying to beck24:

am I right in thinking there's no good way to solve this in 1.8 outside of core?

Not really. I think the least bad would be to hack in a custom plugin hook trigger at the top of group_gatekeeper. If you're on a git branch that shouldn't cause merge conflicts going forward.

[mrclay]

​This spreadsheet summarizes the changes I'm proposing in 1.9. If this looks right I'll move forward checking that my branch implements the spec and add unit tests.

[sembrestels]

Replying to mrclay:

I don't understand -> / and -> group notation. Can you be clearer?

[mrclay]

Sorry, redirect to home page or group profile.

[beck24]

just checked out your spreadsheet - proposed 1.9 behavior LTGM

[Coinor]

Replying to mrclay:

​This spreadsheet summarizes the changes I'm proposing in 1.9. If this looks right I'll move forward checking that my branch implements the spec and add unit tests.

Great job. So your PR won't make it into any 1.8.x release, will it? But why is it still not merged into master? Are there any release dates for v1.9?
Cheers!