Feature #629


Create Required Profile Field to Define User Status

Added by Matt Gold about 13 years ago. Updated almost 13 years ago.

Priority name:
Category name:
BuddyPress (misc)
Target version:
Start date:
Due date:
% Done:


Estimated time:
Deployment actions:


In our last subcommittee meeting, we discussed the possibility of adding a new required profile field to the Commons that will help us track membership a bit. Options can include:

Faculty member
Graduate student
Non-CUNY Collaborator

The idea here is that this will eventually help us create different permissions around roles (really for non-CUNY Collaborators and undergrads), but also that it will allow us to figure out which constituencies the site actually serves.

Let's have a discussion here about the feasibility of this, the technical challenges, and the particular options we would want to include if we do go this route.

Related issues

Related to CUNY Academic Commons - Feature #642: Create new BuddyPress Profile Field to Designate RoleResolvedMatt Gold2011-03-17

Related to CUNY Academic Commons - Feature #643: Create Mechanism to Require People to Fill Out New Identity Profile FieldResolvedBoone Gorges2011-03-17

Related to CUNY Academic Commons - Feature #370: Guest AccountsAssignedMatt Gold2010-10-08

Related to CUNY Academic Commons - Feature #1199: Add Option for Open Text Field to BP Profile Checkbox FieldsResolvedBoone Gorges2011-09-25

Actions #1

Updated by Boone Gorges about 13 years ago

It's easy to require such a field for new users.

It's more complicated to require it for existing users. It's possible to check each user to see if they've filled in the field, and if they haven't, to redirect them to their profile edit page and ask them to fill it in. I find that kind of thing somewhat obtrusive, but if it's important then it's not a huge deal to do it once. If we need to do this, it might be beyond the scope of Commons 1.2, but that's something we can decide as that release gets closer.

The next question is what kind of field it should be. A dropdown menu where users can only choose a single option does not reflect the reality of CUNY existence very well. On the other hand, multiple checkboxes might not give you the sort of rich data you're looking for.

Also, I would suggest that this data should not be used as part of any future permissions/roles features. If roles are going to be meaningful, they must be controlled and set by an administrator, not self-selected by users. Thus, if we're going to require such a field, it should be because we want to gather data, as I don't think it'll be useful for roles.

Actions #2

Updated by Matt Gold about 13 years ago

Thanks, Boone. I think that checkboxes would work well and would still be useful in data reporting as long as we could tell when people had multiple choices selected.

I agree that we wouldn't want to assign people to roles based purely on their self-selected choices, but I do think that that such information would give us a head-start on finding, say, non-CUNY collaborators in the user base if we need to find them post-registration. Obviously, it would not be a foolproof means of finding them, but it would be a step and would probably be better than nothing.

I like your ideas for getting existing users to designate their roles; that kind of functionality might also be useful when we update our Terms of Service.

Actions #3

Updated by Maura Smale almost 13 years ago

I agree re: checkboxes. This is definitely something we will want for City Tech's Title V platform -- maybe we can combine resources to develop something?

Perhaps one way to get around the issue of roles v. permissions is to require non-CUNY collaborators and undergrads to be flagged as such by someone in a known role on the Commons (i.e. faculty, administrators, grad students). Could permissions levels be tied to that rather than the self-identified roles chosen upon registration?

Actions #4

Updated by Boone Gorges almost 13 years ago

No development is needed to have a checkbox (or multiselect, or radio button, or dropdown) profile field. This is all built into BuddyPress. So from a technical point of view, this is quite easy.

I would imagine that the issue of non-CUNY collaborators should be handled separately, since there will presumably never come a day when we have completely open registration. Thus, when someone registers for an account, we already know that they are CUNY, or that we have given them some sort of special access, in which case we already know that they are non-CUNY. Whatever our system ends up being for non-CUNY accounts (an invitation code, a whitelist of email addresses, accounts created by admins only), it should be handled completely independently of this self-reported profile field. (In essence, this is what Maura suggests. But I think it's worthy of a separate conversation.)

Actions #5

Updated by Matt Gold almost 13 years ago

Okay. So, it seems like we have a few different topics here:

1. Creating a new BP field for CUNY members to designate identity (doesn't require development; does require discussion)

2. Creating a mechanism for existing users to be prompted to fill out that new field (requires development and discussion)

3. Figuring out a mechanism for handling non-CUNY members (requires development and discussion).

If you agree with everything above, I will take care of #1 and create separate tickets for #2 and #3.

Actions #6

Updated by Boone Gorges almost 13 years ago

The 1-2-3 distinction sounds right to me.

Issue #3 is covered in

Actions #7

Updated by Chris Stein almost 13 years ago

Sounds good to me too.

Actions #8

Updated by Boone Gorges almost 13 years ago

  • Assignee changed from Boone Gorges to Matt Gold

Matt, I'm reassigning this to you - assuming that this ticket now refers to your (1).

Actions #9

Updated by Matt Gold almost 13 years ago


Actions #10

Updated by Matt Gold almost 13 years ago

  • Status changed from Assigned to Resolved

Also available in: Atom PDF