Instead of having the individual sub-tabs for each relationship type (which takes up a lot of space if you have many types), I'm wondering if we should just add a "Filter by relationship type" drop-down filter at the top of the /relationships page. This would look exactly like the "Filter by points category" filter that we did for Userpoints module. I think it would look better and be much more efficient. Then, we would only need to have two tabs: "All" and "Pending". In fact, if there were only two tabs, we could probably change "All" to either "Current" or "Confirmed". What do you think?

--Ben

Comments

berdir’s picture

Title: "Filter by relationship type" drop-down filter at /relationships » Make local tasks on /relationships pages configurable

I am not sure.

In UP, the single page + filter widget approach works fine because it's about categorization of more or less the same thing, points. Sure, they can have a different meaning too. But with relationships, two different relationships can be about something completely different things.

Retargeting this issue to collect some ideas, we can create a new issue for a search/filter form on /relationships (since we're also discussing to allow to search for users..) later on:

Some thoughts, feel free to extend and comment on these:

a) If there is only a single relationship type (And I think many sites don't need more than one), we don't need to show a local task for that type because then it will contain exactly the same relationships
b) Renaming to current/confirmed sounds like a good idea, especially in that case..
c) I think showing all relationships of all types is a problematic thing in the first place, why would you want to do that? :) Especially if some would be public and for users and some internal and so on... Question is, what should happen with pending requests, for which there is currently only a single page? Als, what would be the default local task?
d) Maybe you even want for example "Fans" and "Friends" on completely different pages, not just local tasks, but /fans and /friends.

Especially when considering d), what we want might be tight Views integration and completely relying on Views for the listings. Then we would just provide the default views, which would be similar to what there is now but users can place them wherever they want. I'm sure that will come with enough new problems too, but is something we could try for 7.x-2.x (In general, that version will be about doing it the D7-way with Entities, Fields, Views, ...)

BenK’s picture

a) Yes, agree with this.
b) Cool.
c) I'm not as concerned with having them on a single page... some use cases could mean the various types are closely related.

I think Views integration is to ultimate solution, but as we've discussed that's awaiting 7.x-2.x

So as a short-term solution, what about adding two config options on each relationship type:

[ ] Hide this relationship type from the relationships list
[ ] Create a separate tab (and path) for this relationship type

These could both be options in a "Listings" vertical tab.

Just an idea... not sure how feasible.

--Ben

--Ben

berdir’s picture

Yes, I like that, was more or less what I meant to suggest but forgot to write down.

berdir’s picture

Will tackle this once the revamp relationship listings patch is in as these touch the same code parts and would easily conflict.

One last question. With your suggested settings, we don't need to specially handle a), right? If you won't want to show your single relationship type in a separate tab, you just have to manually uncheck that checkbox. Also, should the second option be checked by default or not?

berdir’s picture

Some more things to remember/discuss:

- The blocks module should respect the first (hide) setting...
- We should add a corresponding views filter to allow to hide the relationships there too (not by default, however)
- Is it clear for the first option that it only affects the global listing (it does, right? ;))

BenK’s picture

Yeah, I think, you're right with a).... we won't have to worry about this because you can always manually uncheck the box to control.

As for the second option, I'd probably say unchecked by default... this way you can add complexity if you need the feature but the default is clean. And for those with only one relationship type, things are simpler.

And yes, I agree with your thoughts on the Blocks module and Views filter.

Questions:

Should "Current" and "Pending" be local tasks on each relationship type tab/page? I'm just wondering why the "All" tab can be broken down into sub-tabs, but the "Pending" tab cannot.

Do we need a global option to hide the "All" tab altogether?

--Ben

berdir’s picture

Closing as duplicate of #1102476: Revamp relationship listings, as discussed.

berdir’s picture

Status: Active » Closed (duplicate)