Define Required and Optional Data for User Profiles

They are asked for their First and Last names during account creation, nothing else at this time.

tagging

Updated the summary, added email as mandatory (cannot communicate with delegate otherwise!) and added an optional field that I as a delegate usually expect (website) and ones that as conference organiser I would require (phone, accessibility, dietary).

(Cell/Mobile) phone is mostly important for presenters. It's valuable to be able to call them if they haven't turned up half an hour before they're scheduled to talk.

I also propose to rename 'first name' and 'last name' to 'given name' and 'family name' for easier cross-culture acceptance.

Updated issue summary.

Attached is a patch that adds a few basic fields and sorts them into fieldgroups:

Admin: Administrative comments
Public: First name, surname, organisation, job title, website, picture
Private: Opt-In, dietary requirements, accessibility needs

I expect some might need to go into cod_base (eg: the admin one) and some into cod_community (the blog one) before we're done, but it's a start. This patch introduces a dependency on the link module.

This patch should apply happily *after*:

• #1670284: cod_base feature has override on field permissions when enabled #1
• #1672922: Recommended Changes to Attendee List (/community) #21
• #1679940: Remove admin.module dependency #4

when i try to register or create a new account via the admin, i do not see the following fields:
6. Organization
7. Job Title
8. Interests
9. Photo
13. Contact phone number

When I edit, I do not see the following (even as an admin):
9. Photo
13. Contact phone number

Ah yes, they'll all be set as 'site admin' I reckon. Will reroll the patch after I get rid of that :-)

Rerolled patch with included permissions an a contact phone field.

This should be applied after:

#1477754-17: Rename "site administrator" role to "administrator"
#1672922-21: Recommended Changes to Attendee List (/community)
#1679940-8: Remove admin.module dependency

reviewing but found a problem with the dev im using. please see my comment and if anyone can answer http://drupal.org/node/1672922#comment-6262996 my mistake!

Using the sandbox and applying the requested patched, I'm getting this error:
error: cod_community/cod_community.field_group.inc: No such file or directory

combining patch 7 and 10 and enabled photos

It's not clear in the discussion if we want to ask in the initial registration the following fields:
6. Organization
7. Job Title
8. Interests
9. Photo

This patch applies clean, the fields are on the profile.

The one field I don't think should be there is 'dietary needs'. IMO this should be collected as part of the registration process, on the profile it implies that all events will have food ;)

Think your patch missed something, that field was still showing for me. Try this one on.

19 applied cleanly and the feature came up as defaults. The dietary requirements field is gone. The fields show up when they need to, screenshots attached.

12 suggests the fieldgroups I created never made it into my patch. So do we want to have fieldgroups for admin fields, potentially public fields and private fields? Or not bother?

I have moved the admin field to the top of the field list (not shown in the screenshots) as a conference administrator is more likely to want to see that first than the other fields. (Patch 21) This patch also removes the dependency on fieldgroup.

In theory the empty text on the attendee view could be changed, as there may be lots of signups, but they may all want to be anonymous. I don't think that's a major bug though :-)

@cafuego, sorry, didn't mean to overwrite your work.
Regarding the public/private grouping, I think it will help if users know which info are publicly available and only for organizers. I personally would not want to post my phone number but I would be willing to give it to the organizers if they need to contact me.

's not your fault if I managed to make a patch that lacked a file :-)

I'll reroll it shortly.

Updated patch attached.

Patch applies clean, love the new organization, makes things more clear. Thanks!

clean and it works as described

ok, applied to sandbox

can we get:

• location
• twitter
• linkedin
• facebook
• Google+

?

Yes we can, but I think it would be really nice to use specific modules for those that provide API integration as well, so you're not just collecting a string in a text field.

I reckon that rather than adding extra dependencies on all the modules that provide that functionality on cod_community, it may be a good idea to add a cod_community_bonus (or something like that) feature that provides this integration with external social media services.

Family Name and Given Name are just alternates for last and first (more global friendly)

Check the order of fields over ;) you've got first name, picture, last name...

lost the field groupings, and the attendees list field

big ole' PDO exception when I try and enable cod_base after applying your patch ;)

but you know this

Will reroll this as fresh patch that should happily apply *after* "CODZILLA".

Reroll.

Location field uses the addressfield module (new depend).
I've slightly reworded the opt-in checkbox label.
Fields are back in their groups.

Applies to CODZILLA; patch created after applying #1279928: Features Extra support for date_formats to features (though no date formats are included, so that ought not matter).

[deleted double-submitted description without attached patch]

Works on my end. Not sure if I'm missing anything but I think there's a bit of inconsistency.

Yeah I was wondering about doing a twitter URL instead, but then I thought that if you want to put that field on a badge (generally more likely than the facebook, linkedin or G+ username) having a URL field for it is poo. I reckon as-is it can be themed to a link and still be helpful for badge data.

I'll check the grouping - I thought I'd put them near eachother :-/

Odd. Attached is the layout on the site used to create the feature.

Also attached is an updated patch; I've visually inspected the field weights *and* added groups to the hidden fields. What I see now is in fields-admin-display.png.

Maybe its somehow "random" because two elements have the same #weight. dpm'ing field_profile_facebook and summary, I see the same value for #weight in both elements.

Edit: Oh, #44 patch applies cleanly as well.

I've changed the weight for "Facebook URL" up to "Twitter Username".

#46 applies cleanly but, when I enabled cod_base and cod_community I get a Notice and a PDOException:

Notice: Undefined index: create field_profile_admin_comments in user_role_grant_permissions() (line 3032 of /modules/user/user.module).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => create field_profile_admin_comments [:db_insert_placeholder_2] => ) in user_role_grant_permissions() (line 3034 of /modules/user/user.module).

Is there a patch I need to apply before using #46?

Sorry, missed to add files.

#49 patch applies cleanly and the urls are now below the member for:

attached is the image of the page that has the right display now

#49 applies cleanly. cod_community is default when enabled. I've tested this and it works showing the fields in a consistent order.

Don't want to derail this if it's really RTBC, but it'd be great to have a formatter that automatically linked the Twitter username to http[s]://twitter.com/...

I agree with making the Twitter username on its own rather than a link for badge and other purposes, but it would be nice to be able to click on it from the profile page anyway.

But if this is 99% done otherwise I don't want to stand in the way.

Lets leave it RTBC, get it committed and revisit it if needed/wanted.

Hi rootwork, lets take the extended fields (twitter) out of this feature. I'd actually like to put fields as something users would customize (and remove from cod_community eventually)

but for now I think this is a good upgrade path, and it needs to be committed. It tests properly from #49 to the latest git branch for cod and cod_support (Nov 5 2012) so pending Ezra's review, I think we're good to go.

I'm fine with that. Hooray for progress!

Okay after talking to Ezra, we would like to refactor this into the commons profile module, which has many of the same fields. Marking as needs work until we get that integrated. It should just extend the fields that already exist for commons into this module instead of duplicating the common ones.

The specific modules here are http://drupal.org/project/commons_profile_base and http://drupal.org/project/commons_profile_social.

A benefit of using those modules is that by aligning the profile fields between distributions, COD can get profile-related functionality built for Commons for free. For example, Facebook sign-in.

It also reduces code duplication between the projects.

Just curious if there had been progress on this at the recent sprints. Is integrating these two modules part of the near future, or just a "nice to have" goal for sometime ahead?

Updated issue summary.