The function _rpx_update_user_profile_form() called by rpx_form_alter() adds a lot of fields to the profile form that, at least for me, are unwanted. Would it be possible to implement a checkbox in the admin interface (easy way) or a per-field toggle (harder way) to disable these profile fields?

CommentFileSizeAuthor
#5 rpx-638274-5.patch1.1 KBAnonymous (not verified)

Comments

Anonymous’s picture

Anonymous (not verified) commented

+1 for this.

I've got a situation where I want to add RPX to a site with 500 or so existing users. I'm already handling a couple of additional user profile fields but at this stage just want barebones data of username and email to be provided from RPX. So either allowing individual enabling of the profile fields would be good or an "all or nothing" basic/advanced popup might be another option.

Longer term, I wonder whether RPX module should be adding new profile fields anyway or would it be better to integrate with existing ways of adding profile fields so RPX data can be mapped into them? As more existing sites look to add RPX, I'm sure this will become a bigger challenge. "Can of worms" is the phrase that springs to mind :-)

nrambeck’s picture

nrambeck commented
Version: 6.x-1.0-rc1 » 6.x-1.2
Assigned: Unassigned » nrambeck

I am a bit divided on this issue. I didn't even realize that these profile fields were added until after the 1.2 release. My main problem with the current profile fields, is they are changing the profile data returned by RPX directly. I think this data should always reflect what is saved with the external provider.

I see a few ways of integrating profile fields.

1. Don't allow the use to change their profile information carried over from their chosen provider. Each time they login, refresh the data with any changes they have made with that provider.
2. Allow the Drupal administrator to map profile fields (from the Profile module) to the standard profile fields returned by RPX. When a user registers, the mapped fields would automatically copy their values to the correct profile field. The original RPX profile data would be preserved, but the Profile module fields could be changed on the Drupal site. We could allow the user to somehow automatically update their mapped fields with the latest changes they made with their provider.
3. Everything in option #2, except don't preserve the original data. Use the profile data just one time for registration purposes, but then make the user maintain any profile changes manually. This seems like the best option, if we are going to allow Drupal users to link multiple RPX providers to a single Drupal account.

I'd like to get more feedback on this.

omerida’s picture

omerida commented

I'd prefer if profile synchronization was first a configurable option, and had an api or hook so that it could be intercepted and stored elsewhere - cck fields via content_profile module.

Ideally - options 1, 2, and 3 would be options set by an admin for their own site

For example, on config screen a radio form element with the following options:

Synchronize RPX Profile information?
- No
- One-time, synchronize on registration only.
- Manual, allow users to synchronize profile fields on demand.
- Full, synchronize, synchronize on each login.

Make Profile Fields read-only?
- No (Caution, syncronization options above may wipe out local changes)
- Yes
If yes is selected above, should display fields but set the readonly attribute to 'readonly'

warrunner’s picture

warrunner commented

+1 for disabling these profile fields or allowing that option for admins. I spent hours trying to figure out where these fields came from yesterday so it might be good to mention this feature in the readme.

Also the descriptions for these fields are written for admins but display to users eg. 'The name of this Contact, suitable for display to end-users.' so should be changed or made editable.

In the meantime, if I comment out these profile fields, will that compromise the module in any way?

Great, great, great module btw.

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new rpx-638274-5.patch1.1 KB

This patch adds a "Add additional fields to user accounts" checkbox. I'm no expert coder but it doesn't seem to affect anything else.

Anonymous’s picture

Anonymous (not verified) commented

Oh ignore that patch. Just discovered it breaks the /admin/user/profile page.

Anonymous’s picture

Anonymous (not verified) commented

Any advice on how to properly remove the extra profile fields and preferably not even store them in the DB? Last task on my to do list...

Also Nathan, I wasn't very clear what you meant by

My main problem with the current profile fields, is they are changing the profile data returned by RPX directly. I think this data should always reflect what is saved with the external provider.

janrain’s picture

janrain commented
Assigned: nrambeck » janrain

I have added the ability to toggle the extra profile fields. See latest dev snapshot.

Anonymous’s picture

Anonymous (not verified) commented

Thanks, the extra profile fields option works great.

In answer to your question, I'll start by saying for simplicity's sake I think it should only be possible to link a single RPX account to a Drupal account. (I don't really see the use case for allowing links to multiple RPX accounts since the whole point of RPX is single sign-on rather than remembering which account is linked where!).

So assuming a single account, then I think this profile data should be mappable to existing profile fields but not be editable on the Drupal site. So on the user/edit form, these RPX fields should appear but be uneditable with some visual indication that they can be edited on the login provider's site and changes will be updated on the Drupal site (preferably automatically).

As sharing of profile data becomes more and more commonplace, the user knowing they can update their profile at the login provider and have that data automatically update on their linked sites makes the most sense to me.

kevinquillen’s picture

kevinquillen commented

I think this would be a fairly simple thing to solve.

RPX should be able to talk to CCK/Content Profile and let you map Facebook/Twitter etc basic fields to fields defined in Drupal and saved. Whether or not they are editable there seems to be a non-issue to me, as you would want the data integrity to rely on the external authenticating sites. I have personally never used a site using SSO that let me edit the data remotely, it feels dirty. For example, I wouldn't want my Facebook account to change from anywhere other than Facebook.

nrambeck’s picture

nrambeck commented
Status: Active » Fixed

I've added a new issue #714862: Mapping RPX Profile Fields to Drupal to discuss the feature of mapping RPX profile fields to Drupal profile fields.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.