trac user mrclay wrote on 42370733-07-01

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

trac user mrclay wrote on 42378081-04-28

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.

Title changed from Group membership policy should not override access levels on content to Closed group membership affects access levels on content by trac user mrclay on 42378081-04-28

trac user mrclay wrote on 42378849-11-14

For 1.9: #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).

trac user mrclay wrote on 42465977-01-16

The PR above now uses the internal terminology "walled" instead of "gated", but [https://github.com/mrclay/Elgg-leaf/blob/1cf4d085ad50083bd8db7af59068d1a1bd22265d/mod/groups/languages/en.php#L35 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.

trac user mrclay wrote on 42466165-12-21

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

Milestone changed to Elgg 1.9.0 by cash on 42471168-10-08

beck24 wrote on 42552581-12-03

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?

trac user mrclay wrote on 42553213-02-16

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.

trac user mrclay wrote on 42586413-11-12

[https://docs.google.com/a/elgg.org/spreadsheet/ccc?key=0AlAO5SiXoBNGdExuTjgySk1xeDdubm04dmZHU01WQVE#gid=1 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.

trac user sembrestels wrote on 42589384-05-14

Replying to mrclay:

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

trac user mrclay wrote on 42589512-03-14

Sorry, redirect to home page or group profile.

beck24 wrote on 42630864-12-15

just checked out your spreadsheet - proposed 1.9 behavior LTGM

trac user Coinor wrote on 42756083-02-18

Replying to mrclay:

[https://docs.google.com/a/elgg.org/spreadsheet/ccc?key=0AlAO5SiXoBNGdExuTjgySk1xeDdubm04dmZHU01WQVE#gid=1 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!

Note: awaiting approval of PR #528