Loomio
Wed 9 May 2018 11:54PM

Planning user type hierarchy

BW Bob W Public Seen by 283

The preVH is intended to support both the Community and Organisation, so there are a number of distinct roles to be supported. This thread is for talking about how those roles correspond to BuddyPress groups, and how registration as a Community Member, Contributor, etc., fits in with registration on the website.

BW

Bob W Thu 10 May 2018 12:21AM

Here's how we might wish the user type hierarchy would work. The following types of users would be present as nested BuddyPress groups:

  1. Registered Users
  2. Community Members
  3. Contributors
  4. Oriented Contributors
  5. T-Partners (in-training and full)
  6. Full T-Partners

Membership in groups would be governed as follows:

Registered User - No requirements beyond email address (perhaps validated?). (I know Brent had talked about requiring accepting a "Code of Conduct." However, because of the nesting, whatever is required for a Registered User is also required for a Community Member, and I don't think it's right to layer a requirement associated with website usage onto Community Membership. If we're worried about behavior of Registered Users who are not Community Members, perhaps we could figure out how to make affirming a code of conduct a requirement for participating in a the non-Community member forums?)

Community Member - People should not be allowed to complete registration as a Community Member unless they check off all the required affirmations. Once they have done so, they should automatically get become a member of the Community Member group and have access to the forums, without any manual intervention.

Contributor - People should not be allowed to complete registration as a Contributor unless they complete the required affirmations. Once they do so, they should ideally automatically be added to the Contributor group.

It's probably fine if manual intervention by someone in a higher numbered group is required to add someone to the Oriented Contributor, T-Partner or Full T-Partner groups.

Anyway, that's my thought on how I would want things to work with the BuddyPress group hierarchy, more or less.

BW

Bob W Thu 10 May 2018 12:45AM

I have the impression that there are some barriers to implementing things as described above.

As I understand it, the idea would be to implement the forms for registering as a Community Member or a Contributor as additional parts of the user profile. The standard user profile stuff doesn't provide a means to require that all the required affirmations are checked as a prerequisite to completing that section of the profile. I think there may be a plugin that would allow this issue to be addressed?

More limiting, I have the impression that there is no standard mechanism that would allow filling out a profile section to automatically create group membership. I consider that a "fatal flaw" insofar as I really want Community Members to have instant access to their group as soon as they've filled out the appropriate form.

If that is truly a limitation, that seems sufficient reason to shift from the nominal ideal in the following way:

We eliminate Registered User as a distinct category, and instead make registration on the website the same thing as becoming a Community Member. That way, as soon as people complete registration (as a Community Member) they will instantly have enough access to be part of the top level group, and no waiting will be involved.

This doesn't address the issue of creating instant access for Contributors after they fill out the required form... but instant access isn't quite as essential here, so we can probably live with that for now.

@julielawrence you know the constraints better than I do. Does this analysis and the associated solution make sense?

BB

Brent Barker Thu 10 May 2018 1:20AM

Agreed, I'd want Community Members to be able to participate immediately upon registering as such. I think it's okay to require manually adding people to the inside groups.

Would the inside groups still be viewable by public, and just not participatable? That would be nice in service of transparency. Maybe with an option of privatizing on a thread or board level.

Also, are nested groups confusing to navigate in BuddyPress?

As an aside, I now am imagining a user story that justifies a level of User who is not a Member. I can imagine someone who is curious about NVC and wants to learn more by engaging with others on the platform in forums and otherwise. So I think I'm leaning toward agreeing with Bob about this.

BW

Bob W Thu 10 May 2018 12:28PM

For what it's worth, I'm curious to what extent the plugin BuddyPress Member Types Pro could support us in doing what we want to do...

BW

Bob W Fri 11 May 2018 12:05AM

Another plugin that might do the job would be UltimateMember with the bbPress extension? Though, hmm, that's not exactly BuddyPress, so not as useful as extensions go? Nice that it supports custom user roles and different registration forms for different roles. Offers access control, custom profile fields and conditional logic. But... I don't see evidence of it integrating specifically with BuddyPress, and being able to give instant access to a group... Oops, nevermind, UltimateMember does not integrate with BuddyPress.

J

Julie Fri 11 May 2018 8:51AM

Thanks Bob and Brent. Yes, all of that makes sense to me. Whether we need two separate user roles for Registered Users and Community Members depends on whether we want to allow them to do different things ... can you think of any different access/features they'd need?

So if they're not different in what they can access, perhaps "Community Members" could be implemented as something like, once they've checked the required things, a badge shows up on their profile image? There are various plugins to do badges, I believe, although I haven't explored them yet.

Thoughts?

BW

Bob W Sat 12 May 2018 1:29AM

I think we definitely want different access; I imagine that many things will be available to Members but not to Nonmembers. There may be just a few Nonmember-accessible forums? So, no, I don't see simply labeling with a badge as addressing our access-control needs.

J

Julie Fri 11 May 2018 8:56AM

Brent wrote: "Also, are nested groups confusing to navigate in BuddyPress?" ... as far as I know we can't do nested group at this stage. I did find a plugin on github for it, but haven't explored it yet: hierarchical-groups-for-bp

BW

Bob W Sat 12 May 2018 1:26AM

Interesting. It sounds worth checking out. I had imagined using BuddyPress Group Hierarchy since it was the only plugin I was able to find for this, though worryingly it wasn't confirmed to work with recent versions. Ah, I see the plugin you (Julie) found is based on the older plugin I found. So, sounds like the one you found would be the one to work with.

I remember at earlier meetings asking how people envisioned things working, and being told "we'll have nested groups," so I've assumed this is the way it would work. From an access control point of view, I think it makes sense?

BW

Bob W Sat 12 May 2018 2:09AM

What I'd like to figure out is whether group hierarchy affects access to groups. If there is a public group inside a closed group, can anyone still join that group? If so, then the value of having hierarchies seems reduced, for me. Though, maybe it still keeps things a bit more orderly.

BW

Bob W Sat 12 May 2018 2:06AM

One thing I just noticed about BuddyPress is that it appears you can't set things up so that those who aren't in a group can see group contents but not contribute. Either the group is fully open -- to anybody -- or it's private. I think that means we can't have organisational forums that community members could read but not post to. It seems like the access control model is pretty limited, with regard to being able to offer transparency while still offering some control over what happens. That's kind of a bummer, I think. Or, are there plugins that allow more flexible access control for BuddyPress groups? Actually, just found altctrl-public-group which seems like it might do the job of allowing the contents of a group to be visible, while restricting access to actually being in the group.

However, this isn't going to support differentiation between Members and Nonmembers. Guess we'll have to live with that, if we allow Nonmembers on the site.

BW

Bob W Sat 12 May 2018 9:05PM

I've installed the altctrl-public-group and hierarchical-groups-for-bp plugins on http://nvc-we.space. I think these plugins move us closer to the sort of behavior we'd like.

As a result of the hierarchical-groups-for-bp plugin, groups can be organized in a hierarchy. This is mainly valuable for the way it organizes things in a way that shows the relationships between different groups. It also allows activities (posts, etc) to propagate between levels of the hierarchy, if wanted -- but my initial guess is that this usually won't be wanted.

As a result of the altctrl-public-group plugin, it becomes possible to configure a group so you can see contents of the group (or some of the contents), without being able to post yourself. It currently means people can request membership in the group, even though we may usually want to say "no" to this as inappropriate, which is unfortunate. (I may hack the plugin to provide another option of turning off the invitation to request membership.) But, it achieves a level of access control intermediate between public and private, which is good for stuff we want to be transparent about.

On http://nvc-we.space, I've created a private group with a semi-public group inside it. I've also made the Organisation group semi-public. So, you can look at the effect of these.

BW

Bob W Sat 12 May 2018 11:25PM

Based on what I've learned about how things work, I propose an eventual group structure something like the following. Groups in italics are not to be added until later, since I don't think there is yet anyone qualified to be a member. Definitions: a semi-open group allows its posts and members to be seen, but does not have open membership; a mostly-closed group allows membership but not its posts to be seen.

  • Guests - For non-members (or others who are interested). [public group]

  • Community - For everything related to the Community. mostly-closed group (Those joining the Community will be automatically added to this group.)

    • Will eventually have many sub-groups which will be semi-open, mostly-closed, or private. (It's unfortunate that there is no way of making sub-groups "public" for members to join without approval without also making them open to Guests to join without approval.)
  • Organisation - For everything related to the Organisation. [mostly-closed group]

    • Contributors - For all contributors. [mostly-closed group]
    • Unoriented Contributors - For contributors who haven't gone through Contributor Orientation. [mostly-closed group]
    • Oriented Contributors - For contributors who have gone through Contributor Orientation. [mostly-closed group]
    • Partners - For all Transitional Partners and Partners. [mostly-closed group]
    • Transitional Partners-in-Training. [mostly-closed group]
    • Full Transitional Partners - Initially, only ImpC members. [mostly-closed group]
    • Various Implementation Weave groups. [mostly-open groups, though they may have mostly-closed subgroups]
  • Recognised Roles - For those involved in Recognised Roles and Recognised Role weaves.