CUNY Academic Commons

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.

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.

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?

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

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.

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

Issue #3 is covered in http://redmine.gc.cuny.edu/issues/show/370

Sounds good to me too.

Thanks?