I'd love to get some discusion going on how we could integrate UR with OG.

(and perhaps User Profiles...oops that's another feature request)

I would think that part of OG's core isn't required if UR is the "entity relationships - provider" am I right? or do we make them live happily as neighbors doing some of the same work and updating eachother?

CommentFileSizeAuthor
#22 invite.gif28.03 KBSansui
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sprsquish’s picture

I'll show my ignorance here and say that I haven't played with Organic Groups at all so I don't really know what it does.

Reading through the project page the differences between the two modules seem to be that UR is meant for more interpersonal relationships 1-1 whereas OG is 1-many or many-many. How might the two modules serve each other?

jpstrikesback’s picture

So

UR essentially allows people to define interpersonal relationships and view content (and perhaps each other's profiles?) based on the defined relationship right?

OG allows structured organic creation of user groups and then group content and so implies relationship but only within the scope of groups if I understand it correctly.

If the two were to cooperate I would hope:

- UR would mirror organic group "owners" and "members" as one-way & implied relationships in User Relationships
- UR would provide options depending on a given users role to create a new group type & group OR (with a lesser role) a group under an existing group type when a one-way relationship is established
- UR updates & changes (relevant to OG) would be reflected in the groups and subscriptions perhaps making a single point of management for the OG hierarchy possible within UR's configuration pages?
- OG would also mirror UR's relationship types that would make a group and provide options depending on a given users' role to create a new group type & group OR (with a lesser role) use existing type & create a group for users in those relationships

Perhaps Node Access would need looking at so that content remains visible to the scope of users it was intended to and not say friends???

You Like?

jpstrikesback’s picture

If UR was a repository of group relationships, it would probably store:

- types of groups
- the name & description of each individual group
- membership
- the hierarchy if there is one
- what user roles can use any given type

- maybe - owners and admins
- maybe - notification preferences

and:

- expose relevant permissions to drupal (can start group-relationships, can join group-relationships, can start subgroup, etc)
- provide API hooks to start/join/manage group relationships
- add some UI for management of groups and group relationships

A Trust Module/API based on Node Access could potentially do all kinds of sweet things for these groups by allowing access to (user/group) content in this order:

User selected Audience -> Admin Privacy Defaults -> User Privacy Settings

(I wont go into detail on that just yet)

I need to look into OG some more to understand how we could integrate gracefully, meaning leaving OG intact as is but able to take advantage of and update UR-G's groups, their memberships, any hierarchies, perhaps owners & admins, notification preferences. If the Trust Module/API is available OG could take advantage of and update it's audience & privacy preferences. Meanwhile OG is conducting business as usual (providing group home pages, management UI, group specific content creation, notification, etc) but behind the scenes keeping UR and itself aware of whatever membership changes take place, and node access info.

Like I said I need to look into OG deeper to understand the possibilities and pitfalls, so I'll do that and post again. If anyone has any thoughts, feel free to leave em here.

Thanks,
Jon

jpstrikesback’s picture

OK.

To make UR-groups usable by OG, it should be stripped down from what I previously thought, as I had no real clue how OG was built. Now I have some better ideas...

UR updated to store groups should only store:

- if a relationship type is a group-type (extra field in types table)
- OG group_id(og.nid), child_of(og.nid), flags - in a new table: user_relationships_groups (for group hierarchy)
- the OG group_id in the user_relationships table (defaults to 0, but if a group-type relationship=og.nid) and adapt the multi-field "relationship" index to include this (so it wont choke when the requester/ee are in the same relationship type twice)

I think a OG integration would operate something like this:

When a user creates a group in OG, a helper module called OG-UR would add the first relationship after a second user has joined the group.

So add a record to user_relationships:

Requester (group owner) - Requestee (potential member) - type - 8 (og.nid) - etc - etc - approved -flags (indicates that group # 8's group owner initiated this invite)

- or -

Requester (potential member) - Requestee (group owner) - type - gid (og.nid) - etc - etc - approved -flags (indicates that a user has requested to be in group # 8)

- subsequent -

Requester (group member) - Requestee (potential member) - type - 8 (og.nid) - etc - etc - approved -flags (indicates that one of group # 8's members initiated this invite)

Either OG-UR would allow for creating child groups (with a permission), or OG-subgroups could be adapted to use user_relationships_groups?

In User Relationships the changes could be minor:
- group relationships could be listed or perhaps ignored by the UR-UI
- if they are listed they could be links to the group nid
- requests & approvals should likely be ignored and handled by OG-UR for now
- group relationship management currently should be left to OG membership management page for said group...

For now User Relationships - Node Access would function as is, as long as that wouldn't get weird, perhaps filter out the audience bit for group-type relationships as this is handled by OG already.

Thoughts? Things I've missed?

Thanks,
Jon

sprsquish’s picture

First, I still haven't been able to use OG for anything and so still know little to nothing about it. This fact makes it difficult to follow along.

I can, however, respond to the idea of changing the UserRelationships module. Needing to modify UR-UI to support OG would require checking for the use of OG and OG-UR from within UR-UI. This goes against my core goals for this project. I'll go in to why and how it can be circumvented.

My goal is to never need to use Drupal's "module_exists" function. It's far too hack-ie for my tastes. It creates "magic" within the module that uses it. Site admins and builders should have full control over and knowledge of which modules are installed and what their purpose is. This is why I've built UR as an API with many plugins adding functionality. Each plugin does only what it advertises, nothing more, nothing less. If one wishes to connect UR to another module it should be entirely contained within a plugin built to that purpose.

So, using OG-UR as an example. There might be two new plugins, one to handle the API stuff and one for UI. UR-UI should have points of access that allow modifications from other modules. If this isn't the case for certain situation we can remedy that by creating new entry points that will give OG-UR (as well as other modules) the ability to modify content being displayed.

Jon, are you available via IM or IRC? I'm still having trouble understanding the purpose of this project and I think trying to understand through email or the issue tracker will take far too long.

jpstrikesback’s picture

Jeff,

I totally get your point.

After stripping down what an integration would/could do I began to see little point in doing it as well.

I can see the point of it if UR was made the home of all group relationships and types without any dependencies but for now that's too big a task...

We're gonna stick with OG and a few helper modules (and add/modify a few) to enable what we want, which is essentially a friendlier UI for joining/creating groups & group membership management, hierarchical grouping with a different feature set than OG_Subgroups, and some nice Tree views tailored to our requirements...

Jon

sprsquish’s picture

Status: Active » Closed (fixed)

Sorry I couldn't be of more help.

Thinking about it now, I wonder if we were thinking along different conceptual lines. I consider UR user-to-user specific. Friends may all know each other and be considered part of a group, but UR was only meant to handle the connections between the individual users.

I'm going to consider this issue closed. Feel free to re-open it if you think otherwise.

Sinan Erdem’s picture

This one is an old issue but I didnt want to open same issue with a different title.

I am using both UR and OG. And if I could invite my "friends" to a "group", it would be fantastic. If you know Facebook, you know what I mean: When you are in a group you can choose to invite some of your friends from a list by checking them.

In OG, currently you can invite users to a group by entering each name (or e-mail address) separated with a comma to a text field. So I am thinking of a scenario like this:

1. You click invite friends link on a group page.
2. The list of all your friends come with a checkbox for each of them.
(There would also be the usual textfield to invite non-friend users)
3. You check the desired friends and click on an "invite" button.
4. Invitation is sent as usual.

Is it hard to do it? I am going to post this one also to OG issue page.

Cheers,

Sinan

Sinan Erdem’s picture

Status: Closed (fixed) » Active

Double post.. Sorry...

drupov’s picture

@etcetera9: Sounds very reasonable!

alex.k’s picture

Status: Active » Closed (won't fix)

It's not hard to do, looks like a job for a small module gluing the two. However, I haven't had any plans for such a feature, unfortunately.

Sansui’s picture

Version: 6.x-1.x-dev » 6.x-1.0
Status: Closed (won't fix) » Active

Hope you don't mind me reviving this old thread, but what etcetera mentioned in #8 is exactly what I am trying to accomplish now with UR and OG (a customized invite page that uses user relationships and checkboxes to send invites to friends), and I feel like I am pretty close through using:

Views
Views Bulk Operations
Views Send

I have another thread here under OG, but wanted to bring this idea to those using User Relationships as well for ideas -> http://drupal.org/node/1070734

The test view I have created so far, which exists in a group context does these things right:
Displays only my friends
Displays this view in the group context, so I have all the group controls available on this page
Displays checkboxes for my UR friend list to perform an operation (ie, send an email with an invite message)

It is failing with these things:
Displays only my friends who are currently IN the group. Needs to display friends who are NOT in the group. (problem with group argument?)

Sinan Erdem’s picture

Sansui, did you try the option of "Exclude the argument" located on the bottom of the argument options?

Sansui’s picture

I did eventually try that, and it does stop limiting the view. At this point I'm trying to filter my users to not include friends that are already in the group, but there don't seem to be any OG filters like this, so I'm investigating my options in creating a new handler

Sansui’s picture

So far not much luck on filtering out users who already belong to the group, but I'm thinking Views Send is not the way to go, and it would be better to add an action similar to what's already available in the og_actions to use the og invite function.

Sansui’s picture

SELECT DISTINCT(users.uid) AS uid,
   users.name AS users_name,
   user_relationship_types_user_relationships__user_relationships.rtid AS user_relationship_types_user_relationships__user_relationships_rtid,
   users.mail AS users_mail,
   user_relationship_types_user_relationships.plural_name AS user_relationship_types_user_relationships_plural_name
 FROM users users 
 LEFT JOIN user_relationships user_relationships ON users.uid = user_relationships.requestee_id
 LEFT JOIN users users_user_relationships ON user_relationships.requestee_id = users_user_relationships.uid
 LEFT JOIN users users_user_relationships_1 ON user_relationships.requester_id = users_user_relationships_1.uid
 LEFT JOIN user_relationship_types user_relationship_types_user_relationships ON user_relationships.rtid = user_relationship_types_user_relationships.rtid
 LEFT JOIN og_uid users_user_relationships__og_uid ON users_user_relationships.uid = users_user_relationships__og_uid.uid AND users_user_relationships__og_uid.nid = '115'
 LEFT JOIN og_uid og_uid ON users.uid = og_uid.uid
 LEFT JOIN user_relationships user_relationship_types_user_relationships__user_relationships ON user_relationship_types_user_relationships.rtid = user_relationship_types_user_relationships__user_relationships.rtid
 WHERE (user_relationships.approved = '1') AND (users_user_relationships__og_uid.nid IS NULL) AND (og_uid.nid != 115) AND (user_relationships.requester_id = 1)
 GROUP BY uid
 ORDER BY user_relationship_types_user_relationships_plural_name DESC

Using the group filter, which allows you to specify a member is not a member of a particular group, my query looks like this and achieves the results I want, by filtering for where users_user_relationships__og_uid.nid is null.

I am thinking there should be a way to pass the argument value to the group filter in the argument handling code

Sansui’s picture

I'm using the group filter in OG, then changing it in a helper function in my custom site module.

function mymodulename_views_pre_view(&$view, &$display_id, &$args) {
if($view->name == 'my_view_name'){
$view->display['page_1']->handler->override_options['filters']['nid']['value']['0'] = arg(1);
}
}

I now get a filtered list that displays my friends who are not in the current group. Hurray! Unfortunately, I must have an issue with the logic of my view or something, as my friends must be in at least one other group to be appear in this list.

It would appear my where clause needs to look more like this:
WHERE (user_relationships.approved = '1') AND (users_user_relationships__og_uid.nid IS NULL) AND (og_uid.nid != 115 OR og_uid.nid IS NULL) AND (user_relationships.requester_id = 1)
instead of this:
WHERE (user_relationships.approved = '1') AND (users_user_relationships__og_uid.nid IS NULL) AND (og_uid.nid != 115) AND (user_relationships.requester_id = 1)

Sansui’s picture

I think I've got it working. Going to work on creating an action for OG to expose to Bulk Operations, instead of using views send, and then I think I'll have a working solution for a friends list with checkbox invite in OG groups!

Wasn't as simple and elegant as I hoped, but I will create a new thread later on documenting the steps to create this UR / OG invite list.

YK85’s picture

subscribing

dabeast’s picture

+1

Sansui’s picture

Sorry I haven't been back to document my steps. I did get it working using some customized og actions for views bulk operations (turned promote user into invite - so that it simply sends an invite link instead of signing them up automatically).

I've included a pic of how it looks on my site

The trickiest part was just coming up with the filter override for views to use the group id, and then some work repurposing an existing og action.

It's much easier to use than the big blank textbox

Sansui’s picture

FileSize
28.03 KB

Here's the pic

Sansui’s picture

Classic double post on double click -_-

mrf’s picture

Status: Active » Closed (won't fix)

Seems like there is a reasonable starting point provided here. This is a very specific edge case I don't see many people needing and would best be solved through rules or a small custom module as mentioned above.