allowing users to create types of relationships

This is a great idea. I don't think anyone on the UR team has time to come up with a plugin for these things soon, but maybe someone in the community would like to take a stab at it? There are built in hooks to core that can probably be used to do this sort of functionality.

bumping into 2.x

we'd have to call this "user_relationships_facebook" : o )

As #532246: Allow users to create there own individual relationship categories was marked duplicate, this issue should be bumped to 6.x so it doesn't fall off the radar. At the moment, unfortunately, I have no plans to develop new features for 5.x unless someone contributes.

It's almost going on 2 years since the initial request for 5.x...Is there a chance that things will move along quicker for 6.x or is this feature still a long long way from becoming a reality?

Right now I have about 7 different relationship categories. With a view including realname and profile picture thumbnail for each category...and those views are in quicktabs and the quicktab is added to the panels user page override.

If and when this feature becomes a reality...will it be views integrated where the user generated categories can be recognised by views and seperated into tabs with the ability to select the username/realname and picture thumbnail as fields.

And how will the admin go about handling the pre-existing admin generated relationship categories when this feature does become a reality in terms of making sure those pre-existing relationships find there way into the new user generated categories

so we can then eliminate the old admin categories and just leave it as one admin generated category of relationships that the user can transfer their relationships from into their own user generated categories?

This process seems like it may become complicated and I'm just curious as to what the thought process will be for how to handle the transition from admin categories to user categories.

Part of me is wondering if I should not create multiple categories right now as an admin because if this feature does become a reality it may be easier to make the transition later on if I only have one category of friends.

Thanks for the details. I would also tend to treat user-defined categories as one relationship type, so that different views and access control can be defined if needed. I'm not sure that views can render tabs the way you describe (generally views and dynamically created menu entries are not straightforward).

I'm not planning this feature right now, it's definitely not a feature for 1.0 version given how much the multiple rtid layout is ingrained in the module. As far as migration, there should be a choice. Some sites would use different rtid's for different purposes, others like you, for different labels. So I'd err on the side of flexibility.

About the two-year deal... the module became unmaintained a few months after the last comment, hence the delay. And I've been focusing on cleaning up the 6.x branch for the most part. So, no excuses, no :) it just sometimes happens this way without contributed patches.

So the one user defined category would have its own rtid and within that rtid there would be say sub urtid's(User rel type ID's)...but will they be able to take other admin rtid's and transfer them from that particular rtid and into a sub urtid under the user defined category rtid?

Sounds interesting...I understand how things get delayed in the open source environment...but it appears this type of feature is well beyond anything a contributed patch can accomplish...It seems like it would be a major rewrite...hence a 2.x version

Keep us posted on any progress with this...even if its just to say that planning or work has begun on it.

Have a look at #950260: UR LISTS created by end-users for a closely related discussion.

This type of rewrite isn't going to happen in 6.x. Moving to 7.x and marking as postponed. This most likely will have to wait until a 2.0 unless someone highly motivated to get this done shows up to do the heavy lifting.

Closing this as a duplicate of the lists issue.