This is a bit of a complex one, but I've had a lot of problems around editing profiles when RaaS authentication is used, and I've put together a patch to try and mitigate that.

One of the problems faced was with Gigya profile fields that were mapped to Drupal fields. If one of these mapped fields (non-compulsory profile fields, that is) was saved with no data in it (both at create and update time), the module would pull through all the available profile data encoded as JSON into the matching Drupal field. I tracked this down to the way that gigya_get_nested_value behaves, specifically the bit where it returns array values via drupal_json_encode.
I really don't know why this was in there. Right now, I assume it exists to allow other modules to use the corresponding Gigya user create/update hooks to fiddle with the data as they would like, and it needs a JSON representation of the profile object to know what to do.
Therefore, I added a variable called gigya_field_update_resolve_arrays that controls the callback that the array values are passed through, that defaults to drupal_json_encode. If it's not set, or is uncallable, gigya_get_nested_value returns FALSE, allowing for fields to remain empty as intended. You don't have to set it to have things work the way they currently are, but until someone can explain why return values are JSON-encoded, it should probably remain.

Furthermore, it feels like gigya_raas_profile_edit_ajax wasn't quite working properly; it wasn't really updating profile values after we updated a profile using the Gigya form. After having checked what was being passed into the $_POST values it became apparent that the profile values were not being passed in correctly, nor were they being passed through the Gigya user update hooks as they would on login. I've done some work around fixing that up, especially on the Javascript side.
I also added something to keep track of AJAX handlers, to prevent gigya_raas_profile_edit_ajax being triggered multiple times after the form is updated multiple times. (For most people this probably isn't an issue, but it is for us since we display the Profile form on its own page, and on completion, we display the updated form.)

I've done some cleaning up around the profile create/update code, since a lot of it is repeated again and again, especially the bits around isolating User and Profile2 entity fields, and aggregating field values that match them.
I've also tried to document some of the code around RaaS - please let me know if this is helpful.

It's a pretty big patch, so if the maintainers feel that there's something in here that should be separated out/cleaned up more/removed, could you please let me know?

PS. If anyone's interested, I might be able to contribute some code around integrating the addConnections form.

CommentFileSizeAuthor
gigya-profile-updates-1.patch14.99 KBgeoffreyr
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

geoffreyr created an issue.

luciodiri’s picture

Thanks for the profound research and patch @geoffreyr.
We will have to asses and QA to implement in the next release.
As for the second issue, does it apply to all profile fields or specific mapped fields?

geoffreyr’s picture

The gigya_raas_profile_edit_ajax issue? All fields. The endpoint is expecting keys in post like profile.firstName, profile.lastName etc, but the frontend code was submitting firstName, lastName etc.

geoffreyr’s picture

Just checking whether this was resolved at all yet. I noticed that one of the important bits of my patch was knocked out by this commit:
https://cgit.drupalcode.org/gigya/commit/gigya.inc?h=7.x-6.x&id=d8a71f35...
but am wondering if the corresponding issue in your issue tracker mirrors what's going on in this issue.

I'm interested in rerolling my changes for 7.x-6.x, but am wondering how much I should keep.

geoffreyr’s picture

Checking against 7.x-7.2.2, it looks like some of my changes have been rolled into this version; the relevant bits involving handling of user and profile2 fields seems to have been done in _gigya_process_field_mappings.