When attempting to setup a view that shows users and their profiles, the only relationship from User -> Profile that is available is all profiles of all types. You can then add a filter on the view to filter for a specific set of profiles, but you can not easily control the granular configuration of those profiles such as their order, or a mixture of data from various profiles.
For example, consider you have the following 2 profile types with fields:
- Personal Profile
- Name
- Interests & Hobbies
- Professional Profile
- Job Title
- Phone Number
And consider that you would like to create a view of users that show the following fields:
- (Personal Profile) Rendered Entity
- (Professional Profile) Job Title
With the current "All profiles" relationship, there is no way to show the Personal Profile as a rendered entity without it also showing the Professional Profile as a rendered entity. Hopefully this makes sense.
To show specific profiles and possibly show them differently, I'm proposing we add a new relationship for a single profile type. Attached is a patch that adds a new views relationship for a single selected Profile Type. When adding this relationship, the user then selects the Profile bundle that is related.
Unfortunately, I'm not familiar enough with testing to also add an automated test to this patch. Thoughts and feedback are welcome.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | interdiff.txt | 1.27 KB | daggerhart |
| #7 | profile-2905474-7.patch | 3.41 KB | daggerhart |
Comments
Comment #3
daggerhart commentedAttempting new patch that adds the new relationship file correctly.
Comment #4
daggerhart commentedComment #5
maaty388 commentedActually, this patch works great
I tried to implement your patch into default profile relationship because now we have two relationships since with your patch I think we don't need it.
Let me now
Comment #6
daggerhart commentedI agree that the current relationship is not very valuable compared to the one this patch adds. The reasons I created a new relationship is because the module is in beta, and changing how the existing relationship works on current sites would be a breaking change. Happy to make any adjustments we decide.
Any maintainers around to provide thoughts & feedback?
Comment #7
daggerhart commentedThere are some issues with my patch. Mainly that I over complicated it, but also I had left some inappropriate code in place from where I was learning to make custom relationships (taxonomy term stuff).
Here is a complete re-roll that simplifies the relationship class and fixes those issues.
Comment #8
maaty388 commentedStill works great
Is it possible to see git diff between this 2 patches to see a difference?
Comment #9
daggerhart commentedSure thing, here is the interdiff between patch #3 and patch #7.
Comment #10
maaty388 commentedOkay Thank you,
I see there is a lot less code Good job
Comment #11
mglamanCrediting matjaz_zavski for testing manually. I'm not a big fan of Views, but in playing around this seems to make life easier for heavy Views users.
Comment #13
mglaman