I've tried mapping with the preset's default fields and also with just a custom text field mapped to the username, no succeed. When creating a new account the resulting profile is empty, no email, no picture, nothing in the custom field, nothing at all but the username which is something like 'oauthconnector_google__10533...'

The default action now maps email and name to the right fields on first login. Please read carefully... it only maps mail and name and only on first login .
So... it does not do anything with avatar or other fields (yet).

The functionality 'sync local profile with PROVIDERNAME' does also a better job now. Normal text fields are all mapped now, images and other fields not.

What now... or how to solve...

You can take a look at the sub module (of connector) connector_action_default_register_form.module to write your own custom behavior after a connection is made.

Or write a patch for connector so that the default action does its job.

Another patch along the same lines, except this one actually makes Entity a dependency.

I've turned the $allowed_fields into $unique_fields so it will still check if the username or email address is already in use, but otherwise all other fields will be inserted as per the EntityMetaDataWrapper.

Might need some additional checks to make sure every type of field is being attached correctly, but definitely not with such specific checking as per #11.

I'm providing a new patch and updating the issue summary to explain exactly what the issue is. This new patch takes many of the solutions strung across all the previous patches, improves upon them, sometimes fixing them, and putting them in a single patch. Since the work here introduced the entity module as a requirement, I continued to use it even expanded upon its use. Using entity_metadata_wrapper() should work for many fields on users, but there are several properties that it cannot be used for yet #2224645: EntityMetadataWrapper is missing user properties for pictures, passwords, timezones and signatures. So this patch allows values to be stored in an $edit variable as well as the entity wrapper.

This patch also introduces the hook_connector_field_value() hook as a DRY method of validating and setting values. This is used for both user creation and login. There is a default implementation included that provides handling of the avatar field since so many comments and patches were regarding that. This default hook can be expanded to handle other field types like the code suggested by twist3r in #11, or other implementation of it in another module.

Regarding handling the avatar field, I greatly simplified and improved the code given heshan.lk in #20 and #21. Those patches were trying to do too much that was already handled in user.module, assumed the incoming image was JPG, and in the case of #21, gave show-stopping errors because they were trying to create a managed file using the uid when the user hadn't been saved yet.

tr33m4n, I'm not sure why the patch gave you an error. I tried both patch -p1 < 1503258-22-connector-no-user-data-imported.patch and git apply 1503258-22-connector-no-user-data-imported.patch and they both worked fine. Anyways, I'm updating the patch because I wasn't satisfied with how values were being stored to the user account. Since this is using a hook, there is no way for each hook implementation to know if the value had been saved already or not. And I also didn't like how the hook combined both modifying the value and saving the value. So I've split the hook up into two hooks now:

hook_connector_user_info_alter() which let's you alter the incoming info. I then used this to handle the avatar situation.

hook_connector_field_value_handler_FIELDNAME() can save each field.

A few words on hook_connector_field_value_handler_FIELDNAME(). When called, this hook doesn't have to save something to the user. It can do additional validation or anything else. However, if it is implemented and doesn't save something to the user, it must set $field['stored'] = FALSE otherwise the default mapping handler will assume it really did save something.

Also, I did consider removing the new entity module requirement and trying to do everything without it. This would have been possible except the entity module really makes working with fields on user objects a lot easier. So I left it in.