Support views relationship "user -> profile"

Yes, it would definitely be a good thing, since with the current workflow (profile base view and profile->user relationship) it's impossible to get 2 fields from different profiles but linked to the same user appear in the same row. And it's normal because each row corresponds to one profile.
With a user->profile relationship we could use all the profile fields linked to the user.
And it would be awesome.
I'll try to see if i can find something interesting to start.

Would this enhancement allow a node be bound to a profile via a user? For Example to have "Users in the press" and show some fields of the profile2 entity together with the node "press releases". That would be great.

Vote on that.

ok, i got a starting patch.
used hook_views_data_alter to add to $data["user"] the profile relationship. It *works* with profile-table fields, like profile ID.

However :
- Even if all profiles fields are shown (and i honeslty don't know why, i guess entity is taking care of this), when selecting one and updating, it generates errors like white screen with only an output of what seems to be ajax variables, or an AJAX 500 Internal server error popup when trying to preview with one of this fields.
- The view multiplies the number of rows to show by the number of profile types to show. For example, i got 2 user and 2 profile types. With fields username and profile ID set, i get 4 rows:
--> user 1 - profile id 1 (main profile)
--> user 1 - profile id 2 (second profile)
--> user 2 - profile id 3 (main profile)
--> user 2 - profile id 4 (second profile)

Which is really inconvenient, and without getting fields from different profiles within the same row, i don't really see the point.

Anyway, it may be a good start.

*Changed files[] in .info file
*Added hook_views_api at the end of .module
*Added new profile2.views.inc file with hook_data inside.

I attached a git patch, and for those who use cvs, i attached a cvs patch and the new profile2.views.inc in a zip file. Git users won't need to use it, the file creation is included in the patch.

Oups, checked the delete on cvs file inadvertently.

#2, i didn't understand exactly :
- Doesn't the "press releases" is a node reference field in a profile ? In this case, yes when the issue is fixed it, all the profile 2 entity fields should be available, as well as node references.

- Or is it just a node with user references ? In this case, it doesn't have anything to do with profile2 and this patch won't fix that (Although i think you may already do it with actual relationships).

Not sure if I understand this quite but.. is it so that there is work in progress to get different profiles for a user to be displayed in the same row in a view ?

( I made a view that displays fields from the profile called "personal data" wich is first name , last name and telephone number. the view is also displaying fields from the profile "company relation" wich is fields like work telephone number and posiotion , however when using the table display it displays these fields in seperate rows , also I cant add the email field wich is a field from user )

Does the patch "profile2_views_relationship_git.patch" fix theese things ?

@TMH:
That is the intention, yes.

--

"Even if all profiles fields are shown (and i honeslty don't know why, i guess entity is taking care of this)"

Entity module takes care of declaring the profile table as a base table. The views module exposes the fields themselves in field.views.inc.

--

"it generates errors like white screen with only an output of what seems to be ajax variables, or an AJAX 500 Internal server error popup"

I normally get some useful information in those popups but you could try disabling javascript for views under the Views 'Tools' tab. Then preview again and you should get a cleaner error message.

--

I've been trying an alternative to the relationship and just directly joining each of the relevant field tables back to the user table via the profile table. However that still requires either using two INNER JOINs in order to avoid duplicate rows (which means any records that don't have a field filled out will not appear which probably isn't a good thing) or I suppose we could add a GROUP BY uid in there somewhere. (Or perhaps we use GROUP BY with the relationship approach?)

Unfortunately I also ran into an issue with the views_handler_field_field class which assumes the base table is actually the entity table in order to avoid making a join to each field table itself (take a look at the query() method). So it borked when I tried to use it when the base table was 'users' rather than 'profile'.

I think it would be a good thing to take advantage of entity module, so eventual updates won't be a pain to take care of. And it'll probably spare us a lot of codind as entity already handles this kind of workflow.

If entity is aware of fields to expose and actually expose them, why does these fields aren't found by views...

When i try a simple setup with a uid field and a city (from profile) field, with a user view and profile relationship i get this error when viewing from a page view :

Debug : 

'Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column \'profile.uid\' in \'field list\''

dans views_plugin_query_default->execute() (ligne 1314 dans ***/httpdocs/sites/all/modules/views/plugins/views_plugin_query_default.inc).

I switched back to the 3 alpha1 version but the error is the same with the dev version. However when configuring the view i don't get ajax errors anymore. But i got no results, obviously.
I tried to test the sql captured from devel directly in phpmyadmin. This is the request :

SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM users users LEFT JOIN profile profile_users ON users.uid = profile_users.uid)

And this is the message of phpmyadmin

#1248 - Every derived table must have its own alias

Don't know if it's relevant or not...

For the grouping question, using the "group by" functionnality allows to group by uid but it still's generates multiple rows, one for each relationship. And the distinct param in query settings just reduces to one row per uid but showing only one profile.

No more ideas and too tired to do anything else for tonight...

Cheers

Subscribing

subscribing

* subscribing *

Will this be resolved in the next version of profile 2?

thanks

Jon

subscribing

This is what I love about the Drupal community. I come to the d.o to post a new issue about this very subject and there's already a few bright minds working on a solution!

Let's solve this once for all entities via #1066398: Reverse entity relationships for Views integration