Feature #370
openGuest Accounts
Added by Matt Gold over 13 years ago. Updated about 9 years ago.
0%
Description
We have just had an inquiry about bringing 15-20 non CUNY people on to the site for a conference. These kinds of decisions would be much easier to make if we had some sort of guest accounts, perhaps with limited permissions (the ability to participate in a specific blog, for instance, but not to create a new one or to edit wiki pages.)
What do you think? Helpful? Unnecessary? Let me know
Related issues
Updated by Chris Stein over 13 years ago
The only problem I can think of with guest accounts that can be assigned to different people on a rotating basis is that it means that if there is an issue it may be hard to determine who was using the account (and the name will show up as guest). For security we may also need to change the password each time and then manage that list somehow.
Another possibility is to give people accounts and then deactivate them after a given period of time, like in this case after the conference is over. We could add a college named guest as a way to identify the people as guests. Hmmm. does this also mean that we don't want to allow them to edit their profile? We probably wouldn't want to allow them to do that if we use the guest account option either.
This whole business has some complications and management issues regardless of the solution. We should make sure it's something that's worth the effort.
Updated by Matt Gold over 13 years ago
I agree, Chris -- it may not be worth the effort. FWIW, I was thinking not of generic guest accounts that would be logged into by multiple people, but rather individual accounts with limited permissions. In the end, what I'm trying to do is lower some of the barriers to inviting non-CUNY people into the site. There may well be other, and better, ways of doing that.
Updated by Matt Gold over 13 years ago
. . . and maybe this ghetto-izes those guest accounts in an unwelcome way. After all, what's the logic behind not wanting guests to edit the wiki? I'm not sure. I just wish there was some way of letting people into one specific part of the system without allowing them into all parts of it. That would make it easier to let people into specific projects.
Updated by Boone Gorges over 13 years ago
From a technical point of view, this is not extremely easy at the moment, because BuddyPress uses a more or less homegrown permissions system. But it's been on the roadmap for some time to replace this homegrown mess with better WP Roles integration, and this might be a nice excuse to make it happen. That said, it could be done within the way that BP currently works, but it would be a bit tougher and more ramshackle.
A truly flexible solution would allow the admin to specify an arbitrary number of user types, and for each user type select from an extensive list of things that the user is and is not allowed to do.
Depending on the nature of what the committee wants, this could be a medium-to-large sort of development task, the sort of thing that would take 10-20 hours of dev time from start to finish (where "finish" is loosely defined :-D )
Updated by Boone Gorges over 13 years ago
- Priority name changed from Normal to High
- Target version set to Future release
Updated by Matt Gold about 13 years ago
- Target version changed from Future release to 1.3
Updated by Boone Gorges almost 13 years ago
- Target version changed from 1.3 to 1.4
It's all but certain that the changes necessary to make this easy, from the BP point of view, will not be added in BuddyPress 1.3. That means that it will take a large amount of ultimately wasted effort to implement this at the moment. I suggest we push it to the next milestone.
Please pipe up if this is a huge problem.
Updated by Matt Gold almost 13 years ago
Not a huge problem, and it makes sense to wait, but I do think it's a very important feature. Do you have a sense of when BP 1.3 will be released?
Updated by Boone Gorges almost 13 years ago
I do think it's a very important feature
Agreed, but everything is an important feature, and it can't all be done at once!
Do you have a sense of when BP 1.3 will be released?
A beta should be out within the next few weeks.
Updated by Matt Gold almost 13 years ago
Agreed, but everything is an important feature, and it can't all be done at once!
Point taken . . . .
A beta should be out within the next few weeks.
Okay, cool -- I thought we were talking months/years instead of weeks/months
Updated by Boone Gorges almost 13 years ago
To be clear, BP 1.3 will not contain the necessary infrastructure. But at least when it's out, it can start being worked on for the next version of BP.
Updated by Boone Gorges about 12 years ago
- Target version changed from 1.4 to 1.5
BuddyPress 1.6 will contain the first sketches of the necessary infrastructure, though there is a lot of labor-intensive work to be done to make rich guest-account configuration a possibility.
In the short to medium term, it may be possible for me to create certain kinds of limited-access accounts. This is something we discussed at a recent team meeting. Keep in mind that the default setting for BP/WP is for users to be able to do everything, so the fewer things we have to forbid in a custom account type, the easier it will be to accomplish. For instance, it would be fairly easy to create a guest account type which can do everything except create blogs. Blocking the ability to create groups is a bit trickier, but can also be done. Blocking read-access to certain kinds of content starts to become much more difficult.
I will continue to upgrade this ticket as progress is made in BuddyPress toward a more flexible system. Likewise, if team members have concrete ideas for the kinds of guest accounts desirable, leave them here and I can give you my best sense of the feasibility of implementation.
Updated by Boone Gorges over 11 years ago
- Target version changed from 1.5 to 1.6
- Estimated time set to 10.00 h
- Severity set to High impact
As promised, there is now some minimal ability to do the necessary kind of permissions filtering in BuddyPress, though it's not totally robust, and it'll still take a lot of work to do what's being requested here.
That said, there's enough infrastructure in place to start, though I suggest starting small. If we had to come up with one new user type which would be high impact, what would it be? What would be the use case for such a type? For that use case, what kinds of permissions would those users have to have? Which permissions should they definitely be denied? Let's work toward a spec.
Updated by Matt Gold over 11 years ago
I'd say that we should concentrate on the non-cuny user status. ideas for implementation:
-- non-cuny users get assigned non-cuny status that they can't change (have to think about how this would play with our non-cuny sign-up codes
-- users would be restricted to the following:
- ability to edit own profile
- full abilities within groups (add files, edit docs, post to forums) but maybe would be barred from admin/moderator status
- full abilities on the blog associated with the group
no permission to:
- join other groups (except maybe we can have a workaround where a CAC can manually add a non-cuny user to another group if needed)
- post to other blogs
- post directly to sitewide activity feed
not sure about:
- ability to edit the sitewide wiki?
Updated by Matt Gold over 11 years ago
The idea behind all of that is that non-cuny users would have been invited to be part of a specific group and would be restricted to that group.
Updated by Boone Gorges over 11 years ago
- Assignee changed from Boone Gorges to Matt Gold
ability to edit the sitewide wiki?
It's going to require a herculean effort to tie account types to wiki permissions, so I'll suggest that we leave this bit out for now.
Reassigning to Matt until there's a full spec ready.
Updated by Chris Stein over 11 years ago
A couple of additional thoughts without answers at the moment
Are guests allowed to be invited to additional groups at a later time? Like you invite Jim Groom to your group and then I decide I want him in mine too.
Will the accounts be permanent or will there be time limits?
To go along with time limits, would a use case be, I have a conference with 600 non-cuny people and I want them all to have guest accounts.
If we do envision the conference type use case is there a tool to manage inviting a list of emails or something like that?
How does this work with the idea of federated profiles?
How will they fit into the members page and search? Should we
- not include them
- include them
- include them but filter out by default (option to expand search to non-cuny)
Updated by Matt Gold over 11 years ago
Great questions, Chris. Here are my answers:
Are guests allowed to be invited to additional groups at a later time? Like you invite Jim Groom to your group and then I decide I want him in mine too.
(answering without regard for the technical difficulty involved in implementation): if the invitation comes from a CUNY person (and it should, since non-CUNY people shouldn't have the ability to invite), I'd say yes.
Will the accounts be permanent or will there be time limits?
permanent with the ability to set a timelimit, perhaps? But at the end of that timelimit, I'd not delete their accounts, which could also delete the content they created, but instead either create a deactivated state and/or just lock them out of the account and disable password recovery.
To go along with time limits, would a use case be, I have a conference with 600 non-cuny people and I want them all to have guest accounts
If we do envision the conference type use case is there a tool to manage inviting a list of emails or something like that?
Great thought. I wasn't thinking of this use case, but it's absolutely valid. We do have a few tools for invites of non-cuny accounts and we also have the special non-cuny signup codes which could be used for this purpose.
How does this work with the idea of federated profiles?
Don't know but I don't think we actually have federation working at this point (Boone, please correct if I'm wrong about that)
How will they fit into the members page and search? Should we
- not include them
- include them
- include them but filter out by default (option to expand search to non-cuny)
I think that they should show up in search without being filtered out.
Updated by Boone Gorges about 10 years ago
- Category name changed from BuddyPress (misc) to Registration
Updated by Boone Gorges about 9 years ago
- Target version changed from 1.8 to Future release
I think we've been tackling this problem the wrong way. Instead of trying to cover every possible use case with the first pass at this feature, we should find one single, concrete use case, and build that. Then we'll be in a better position to think about the UX and technical implications of making the feature more general.
I'm moving this into Future Release until such time as we have a specific use case.