Please note: This is entirely a technical discussion. The actual behavior of groups, per requirements, will not be affected by this

Good news (I think!)! Excluding migrations and tests, the only references to joinableBy in the codebase are:

• The model itself
• The group service in its create* methods
• h.db’s __init__ where the world group is created (once) with a joinableBy of None
• h.views.activity in one or two spots that I think Sheetal is removing as I type this

Other group-related services and views don’t give a hoot about joinableBy and I’d argue, neither should we. Removing it would simplify the “group type” matrix and relieve confusion about what “joining” actually means. There’s nothing in our data model that actually prevents a membership relationship from being created, and the fact that the creator is immediately added as a member to a new restricted group “violates” the notion of joinableBy = None anyway, in some ways.

My recommendation:

• Evaluate removing the joinableBy flag from the group model for now.
• Understand that we will need to take up the issue of how joining works at another time soonish.
• Views can switch on Group.type for now to determine what kind of membership-related interface to expose

Because each of the remaining two access flags only have two possible values each, after the removal of the joinableBy flags, we’d only face four possible group types at present, of which three are already defined:

1. Private: readableBy=members, writeableBy=members
2. Open: readableBy=world, writeableBy=authority
3. Restricted: readableBy=world, writeableBy=members

Without creating more access flags, the only unused combination we’re left with is readableBy members and writeableBy authority which doesn’t make sense anyway.

And, as we discussed, joinableBy doesn’t quite make sense as an “access flag” in the way we’re currently using it.