Improve mapping UI, support provider and client

I'll take care about this.

Aron, thanks

We could get rid of that yes, provided we made sure content profile was enabled on the provider and relying party

The reason it is there currently is so the correct request goes out with the correct namespaces. We might want to determine if that is a good idea to put it into the cp module and thus force people to utilize it.

#3: I'm aware of sreg support here. I suggest to extend

#4: 'openid_cp_field_map' - where is this hook implemented? Maybe i overlook something but i could not try out my patch without this.

The patch below is only for the first draft, it's not tested.

Aron will test and see how it performs.

Hm, the patch is not in testable status unfortunately.
To achieve testable status, I need to understand the current workflow of the module.
Can you point me where openid_cp_field_get_value comes into the play?

The openid_cp_field_get_value is utilized too ask for two hooks that link too the content profile fields permissions. If a user has decided they want their fields to be private then openid will respect those privacy rules in this function, it verifies whether it is allowed too and if so it retrieves the value if not then it just returns NULL.

The two hooks access and value in that can be implemented by any module and we have them implemented i believe in one of the content profile sub modules i believe, one of our other guys Alex K does that, i will find out which module utilizes that.

Here is where i'm now.
Sreg mapping UI is added.
What's missing:
Add the populating of content fields (maybe instead of the hook calls)

Hm, it seems that i cannot delete the last file, it was posted accidentally :)
Here is the correct file.

Current status:
Good UI for SReg mapping also
Draft code for returning the value (instead of calling external modules)

Missing:
Export for SReg
Test that the _openid_cp_field_get_value() actually works or not
Test is with both openid_provider_ax and openid_client_ax

At #12, I forgot to attach the patch file, but here is a newer version.

I coded on hook_openid_provider_ax() because it was not adequate originally (the parameters were not the same as in openid_provider_ax)
I assume openid_client_ax should only call openid_cp_field_get_mapping() simply, the other logic can remain in openid_client_ax.
Export works for sreg as well.
To actually try it out, first openid_client_ax needs to be compatible with openid_cp_field.

Minor modifications on the previous one according to http://drupal.org/node/434378#comment-1484264 (for openid_client_ax)
The two patches really needs to go together.
Be aware that these patches still need testing. It contains all the concept and logic that i'd like to implement.

This patch is ready to try out now. To make it work, check out the openid roadmap (http://groups.drupal.org/node/21221) and apply #434378: Move mapping functionality to openid_cp_field to openid_client_ax.

This is in "needs work" status because of the following:
- SReg support is not here, because I haven't started #430332: Make SREG independent of Persona yet.
- at this point we cannot declare if an attribute is required or optional. It needs to be discussed. Do you see such a use-case when you would like to refuse the openid registration because of a missing attribute?

I tested and it works well, i did map CCK and body fields to openid attributes and the whole process seemed to be convient.

Aron, the patch 5 the last one has been applied to the openid_cp_fields branch DRUPAL-6--1 in CVS http://drupal.org/cvs?commit=198642 is the cvs commit

If this piece can be closed you can close it not sure if you are going to be adding more to this or not.

darren.ferguson: Thank you, it's great to see this patch in the CVS logs :)
I would like to discuss one thing with you before closing this ticket:
At this point we cannot declare if an attribute is required or optional. Do you see such a use-case when you would like to refuse the openid registration because of a missing attribute? You know, openid_client_ax supported this feature, I assume if we want this feature, the mapping UI should support it also. What do you think?

Here is a fix (extremely important) for the mistake I did in the patch what was committed.
The issue is: the exchange of the attributes did not happen according to the specs.

Aron,

The patch is now in CVS regarding above.

"At this point we cannot declare if an attribute is required or optional. Do you see such a use-case when you would like to refuse the openid registration because of a missing attribute? You know, openid_client_ax supported this feature, I assume if we want this feature, the mapping UI should support it also. What do you think?"

I think we might want this purely for the following if the name or email which Drupal needs is non existant and it is not available through simple registration then we should definitely catch that rather than allow Drupal's user module to catch that. I think we should support the feature but the default for each of the mappings should be optional.

Darren: thank you for your feedback, this means we don't have to make the UI more complicated to get this feature back, (altough I need to make sure that name and email is always here)