Hi

I'm very interested in help you with coding relation types to buddylist2, but at least I could see that this module implements at least the two types of named relations:

The first is the easy one, like "friends"... it's a one way relation: friend <=> friend

The second one is a bit more complicated, is a two way named relation, like "father" and "son". But in this type there could have multiple possibilities: father <=> son ; mother <=> son ; father <=> daughter ; mother <=> daughter ...

Another option (from User Relationships) are implications. For example, "father" implies "family"

Hope I could help

Comments

bobdalob’s picture

bobdalob commented
Component: Code » Buddylist UI

I'd like to see some differentiation between a one-way and mutual buddy, moreso where no approval is required. Firstly, I think one should be able to simply identify one's relationship with another user by relation name (e.g. one-way = fan, two-way = friend). One relation name for all means that, in my profile, I cannot tell if a buddy is one-way or mutual without then going to their profile to see if I'm in their buddy list. This already leads into the second point - about finding users according to my relation with them or their interest in me (I'm a fan of, fans of mine, mutual friends) - there is no way but chancing upon a profile to find people who've added me as a buddy (users I don't even know are fans of mine)

nodestroy’s picture

nodestroy commented

Hi,

the idea behind this is:
one-way and two-way are just configurations in which a relation type can run. now we only have one relation type...the "buddy", and this buddy can be one-way OR two-way. The plan is to implement named relation where you can decide one-way/two-way for each one.

Then you can define for example:
fan - one-way
buddy - two-way
...
...

buddy_api is already prepared to support such named relations. do you think that this solution would be good?

regards
dominik

bobdalob’s picture

bobdalob commented

yes, it sounds good if I read you correctly.

I think it's the user relationships module that went part way with implied relationships but, in my opinion, there is no need to continue to show a user as a fan once the relation has progressed to buddy (in user's buddylist - showing userX under both your fan AND buddy). I don't like it, thinking from a user's point of view.

Something like:

Buddylist action                  userX sees userY in buddylist as                  userY sees userX in buddylist as
userX adds userY                  "you are a fan of"                                "a fan of yours"
userY then adds userY             "buddy"                                           "buddy"
userX removes userY               "a fan of yours" *                                "you are a fan of"

* or if we get real, ex-buddy!

I understand the buddylist api was borne out of desire to allow a developer to go where they want. I hope this is one direction that makes sense to develop.

introfini’s picture

introfini commented
Version: » 5.x-1.x-dev

Hi,

Allowing different relation types is a must have for Buddylist.

Thanks.

introfini

4drian’s picture

4drian commented

I'd just like to add my 2 cents to this request:

I am very keen to get buddy types onto a site that I'm working on at the moment. One of the things that I can't do (at time of writing) with the user relationships module is to only show certain relationship types depending on the user role. In my situation, the users are buyers, sellers, and manufacturers and I do not want buyers to see or use the relationship type 'lead' or 'customer'.

Similarly in a school environment, you don't want students making up relations that suggest that they are a teacher of another student but this would still be a valid relation type for users with the teacher role.

If, and it sounds like when, relation types are implemented, would it be easy enough to specify availability of types based on roles?