Show user profile "required" fields

* bump * subscribing.
There is a sister post for 5.x version out there.

subscribe

I needed something quickly for a client so here's a patch against version 6.x-2.1 to add required fields. Currently it works with text fields only, great for First and Last name fields. It does not check permissions or validate input.

I'm not sure how much time I'll get to work on this so I'll put it up here to give you somewhere to start.

If (when!) you do find any bugs or problems with it, please let me know.

@imclean - Thanks for the patch. I cleaned up the patch and got it to apply without errors. It looks like there may have been some stray files in your directory when you created it because the patch data was repeated over and over.

The required fields are indeed showing up on the add multiple users form -- great! Looking at the code, though, the call to profile_save_profile() requires that the required profile fields also be set to appear during registration as well. I haven't yet tested to see if the profile values get saved because I haven't configured the fields properly.

Looking at profile_save_profile(), this seemingly straightforward feature is going to be tricky to implement. For any fields that appear on the form we're going to need to figure out their profile categories in order to get the values saved.

We may want to change the way this works and have the user specify which profile categories they want to appear on the add multiple users form. That'll, at least, make the saving of the values more straightforward.

Thoughts? Anyone else get the patch to apply and get a chance to test it?

- Marc

Holy moly, I have stuffed up there! I can't seem to delete the previous attachment so here it is again.

All the patch does is grab any profile fields which are set to required - "The user must enter a value" check box in the Profile field details section.

From what I can tell, the categories are not required (or indeed used) with profile_save_profile() when the last field "$register" is set to TRUE. It simply inserts the values into profile_values.

The patch (when properly generated!) works for me as intended, it does save the Profile fields. To test, create a couple of Profile text fields and check the box "The user must enter a value" for each one.

I just committed a fix for this to 6.x-2.x-dev so it should be available the next time the snapshot gets updated. It differs greatly from imclean's patch, but the patch really got this thing springboarded, so I'm mighty thankful for it.

Required profile fields will now show up on the add multiple users page, and there's no way to turn them off right now. That'll be a separate feature request -- hopefully someone'll get around to adding it in the system for me so I don't forget.

I've only tested this with textfields and urls and they seem to be working just fine. No idea what's gonna happen when we stray outside the lines.

Feedback is much desired.

It'd be easy enough to have a checkbox on the Userplus config page.

userplus_admin_settings()

   $form['add-multiple-users']['userplus_show_required_fields'] = array(
    '#type' => 'checkbox',
    '#title' => t('Show required Profile fields'),
    '#return_value' => 1,
    '#default_value' => variable_get('userplus_show_required_fields', 0),
    '#description' => t(''),
   );

Add a check in the required places:

if ((module_exists('profile')) && (variable_get('userplus_show_required_fields', 0))) {
    $result = db_query('SELECT fid, name, title, type FROM {profile_fields} WHERE required = %d ORDER BY category, weight', 1);
	  while ($record = db_fetch_object($result)) {
        $profile_field[$record->name] = array(
     	  '#type' => $record->type,
     	  '#size' => 16,
     	  '#maxlength' => 64,
     	  '#default_value' => '',
     	);

 	  }
    }

if ((module_exists('profile')) && (variable_get('userplus_show_required_fields', 0))) {
    $result = db_query('SELECT title FROM {profile_fields} WHERE required = %d ORDER BY category, weight', 1);
    while ($record = db_fetch_object($result)) {
    	$header[] = $record->title;
	}
   }

Another method would be to be able to select which Profile fields to include. The options could be per field, per category, all fields or just the required fields.

Just committed a solution for #7 -- thanks, imclean.

Waiting on folks to test out the required fields on the add multiple users page before cutting a new release.

This is a really great improvement to be sure - IMHO it probably shouldn't go into a release without support for all of the profile field types - it looks a bit odd with the fields that are select boxes being empty columns.

FWIW, it would be useful for my purposes at least to be able to configure *which* profile fields to use rather than just adding all required fields. There are times where it might be advantageous to leave fields untouched for example:

* Your user registration form has a checkbox that allows users to opt out of a site-wide user listing, and you want to make sure they have a chance to see that checkbox and make a decision whether or not they registered or an admin created their account.
* You create a rule (Rule module) specifying that if $user->profile_opt_in == "" they should be directed to their profile page.
* In the event that a user registered, but didn't check the box, the field would be set to '0'. If they did, then '1'. If an admin creates their account using the usual user/add they will submit the form including the checkbox and thus set the field to '0'. If the user could be created another way (say, userplus) without submitting any value for that checkbox - the rule could be triggered when the user first logged in.

Cheers,
Justin

Configuring *which* profile fields to use should be a separate feature request if it isn't already.

I agree that the poor support for fields other than text makes this feature less appealing in a lot of cases, but I cut a release because you can turn it off and get the same behavior you had before.

I was also hoping that patches will appear here to provide support for the other profile field types.

Right on, I see your point about turning it off if you don't want to use it.

Closing this. Please open up a new issue if other types of profile fields need to be supported.