Following conversation started here -- http://drupal.org/node/1088538#comment-5227436

Og group currently only holds the group ID and the group label, to allow autocomplete widget. If we will restrict group-audience field per entity-type, then we won't need to care about the group Label, and we can probably deprecate the og group entity.

Issues for Entity reference coming out of this task

#1343854: Separate "Selection" and "behavior" to different plugins
#1319040: Remove "target_type" column from db
#1340748: Add CTools relationship
#1263118: Have equivalent of Node Reference URL Widget
#1352690: The widget should properly handle references to entities the user do not have access to

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amitaibu’s picture

fago’s picture

Also, that way we'd have the real group entity directly in the og membership entity. I see the following advantages:
* Simpler relations = simpler views. People have to configure one relationship less, one join less. (Who got not yet confused about membership:entity vs membership:group:entity? :)
* Simpler relations = simpler rules. Ideally, just get the group node via node:membership-field:0:node. Or maybe even node:membership-field:node in case of single valued fields?
* Simpler relations = tokens solved (see #1088538: OG (Organic Groups) tokens missing.). Tokens for entity properties like [node:membership-field:0:node] would be auto-generated by entity-tokens.

Cons:
* Many, many changes :(
* Update procedure?

amitaibu’s picture

I agree with the Pros, I wish I made Og a bit less flexible in that sense to begin with ;)

* Many, many changes :(
* Update procedure?

Since we have og-migrate module, it might be easier than we think. The whole upgrade from OG6 to 7 was realtively easy when done with og-migrate.

I'll be really happy to migrate the field type to entity-reference...

KarenS’s picture

This would really really simplify things. I just worry about what happens to existing sites or people trying to build sites right now. Once you go through and set up all the code and content and views and relationships and custom tweaks it would be a PITA to have to re-do everything to work with this change. So it would be nice to do this ASAP if it's going to be made. I have some sites considering using OG in the near future. I'm thinking I would recommend that they just wait until this is resolved rather than set it all up and then have to refactor everything.

But a huge huge +1 for this idea from me.

amitaibu’s picture

> I just worry about what happens to existing sites or people trying to build sites right now

Indeed. Maybe it will be Og 7.x-2.x, although I don't really want to maintain two branches..

Anyway, I've opened a new branch. Nothing to see yet, just starting to look what's possible...
git checkout -t origin/1342632

mradcliffe’s picture

I agree with all of the above. Simplifying the views experience would be good, but doing this in the current branch would be a major headache for any current site maintainer or og contrib developer. But then it would be a big headache for the og maintainer.

I took a look through some custom modules that I've written recently for og 7, and besides Views, I do a query on the og table 1 time. Every time I need to query something directly it's via og_membership and in rare cases og_role and og_users_roles.

KarenS’s picture

It definitely has to be a 7.2 branch for such a major change. I think it would be OK to make the new branch the recommended branch once it's working and warn people using 7.1 that it will be deprecated, but leave it open for a while, bugfix only, to give them time to switch. So there would be two branches for a period of time, but not indefinitely.

Crell’s picture

Also remember field/node configuration that has been featurized. That would be more difficult to migrate, wouldn't it?

As someone building a site now with OG and about to pitch it to a client as the backbone of their entire site, I'd much rather see this change made sooner rather than later. :-/ I agree that it would simplify things, but eep!

mradcliffe’s picture

I don't think removing the Og entity would effect fields. That's more related to the task of removing Og Audience. Views, in features, however, make testing before updating crucial. Although with features I find it a bit easier.

Recently, I had to go through and touch related views when the og relationships changed. Then recreate the feature.

If you develop in the current architecture, I think you'll be fine later on.

amitaibu’s picture

> I'd much rather see this change made sooner rather than later

Indeed. I should probably post a blog post about it, and try to get sponsorship for this in order to get it done fast.

Here are the first issues coming out of this issue:

Itangalo’s picture

As far as I know, Entity Reference can only reference one entity type at a time. What happens if I have one group that is a node and another that is a taxonomy term, and I want to reference both?

amitaibu’s picture

> What happens if I have one group that is a node and another that is a taxonomy term, and I want to reference both?

Then you will have two separate fields. Same as you can't reference a node and a term from the same field.

awt’s picture

What about relation module? In conjunction with relation_select it's really flexible and you have an easy way to link different entity-types together (node, tax,...).

amitaibu’s picture

> What about relation module?

While I think Relation can be great, I think it will be changing one complexity with another.

> Really flexible and you have an easy way to link different entity-types together

That flexibility is actually the thing that I want to loose. I believe, following closely the issue queue for the past year, that linking multiple entity-types is something rare, that can also be achieved by having multiple fields. We will still be able to query the OG membership entity, so we don't care if there are multiple fields in that sense.

Itangalo’s picture

> While I think Relation can be great, I think it will be changing one complexity with another.

Having spent some time with the Relation module, I agree on this. (Also, there would still be the extra join created by Relation.)

Jody Lynn’s picture

I'm concerned that this goes well as I have two large projects developing on the current branch and launching soon.

The current branch has been making me nutty with its views integration (although it looks like some of that confusion is getting cleaned up), as well as the fact that everything is a field with a magic formatter (like the subscribe link or add content links). Currently it takes a senior dev to create the og views, and I basically have to look at the db and figure out the query i need first and then attempt to get the relationships and arguments straight to match that. (The descriptions on the relationship options on the plus side do make me laugh with their extreme abstraction and difficulty.)

I'm concerned that the new branch must make things appreciably simpler and not just end up being another transition to something different, another system to learn, and cause us to have to redo dozens or hundreds of views and panels in the process (or, more realistically, strand us on the old branch).

That said, we'd definitely be interested in sponsoring this work if we're convinced it's going in the best direction.

amitaibu’s picture

> I'm concerned that the new branch must make things appreciably simpler and not just end up being another transition to something different

That's the same concern I share :) You can follow the git commits of the 1342632 branch. It's pretty trashed right now, but I'm already able to associate content to groups, using entity reference. Obviously, the big part won't be just converting OG core, but to make sure all the Views/ plugins are updated, adapting the (many...) tests and provide a sane upgrade path.

> That said, we'd definitely be interested in sponsoring this work if we're convinced it's going in the best direction.

That would be great. FunnyMonkey are already going to sponsor 3,000$ and providing developer hours, so I'm definitely looking for others to chip-in to reach the goal

thomas1977’s picture

Just want to chime in and say that I'm just about to launch a major site (making use of OG) next week at our university. Unfortunately, we cannot sponsor the OG development at the moment, but I would very much like to know what direction this takes. I definitely don't want to launch a site of this scale with so many users and having to rebuild big parts of it soon (realizing that 7-1.3 is already giving me some serious headaches). That being said, we really appreciate all your efforts! Thanks a lot!

Taxoman’s picture

nagiek’s picture

Just curious, why is group_audience still being kept around, period? Why isn't it deprecated in favour of the og_membership entity?

BrightBold’s picture

Even though the thought of having to migrate an OG site to a new structure panics me (I have two OG sites in development and both will probably need to launch before this effort could be completed), I think any simplifications in how OG interfaces with Views, Token, etc. can only be an improvement. As Jody Lynn points out, OG 7 can be too complicated for the average site builder to easily implement. While I share Taxoman's concerns that it took a long time for OG 7 to get stable enough to be really usable, and I hate the thought of finally having gotten to that point only to be create new chaos, I think the long-term benefits of changes like this will outweigh the disadvantages. As long as you can maintain two branches for a while!

So another +1, for this change and any other simplifications (e.g. get rid of magic formatters!) that would make this module less inscrutable.

amitaibu’s picture

I'm about to write a blog post and update this issue with the latest in a couple of days, but until then wanted to share that I think we can also partially deprecate OG membership...

The idea is that currently OG membership is added on the relation of a group content to a group giving the state (i.e. active, pending, blocked) and having a membership type (e.g. default, expire, etc;). however in real life this is important only for the User entity. What I'm thinking is maybe we should create an OG membership only for user's relation to a group.

Does anyone has a use case where this will be a problem?

bonobo’s picture

What affect - if any - would deprecating OG membership have on OG Access Control?

And - "I'm going to talk about that in the upcoming blog post" is a totally acceptable answer :)

amitaibu’s picture

> What affect - if any - would deprecating OG membership have on OG Access Control?

None. The access control is always against users not nodes. So we still check for the user's credentials when allowing or denying access. The OG membership is going to stay almost the same, just be created for user entity, instead of any entity.

mradcliffe’s picture

You're probably going to explain how it would work in the blog post, but how would other entities be a part of a group? Is this with entity reference as well? Sometimes entity reference fields have a slight performance hit in the Admin UI (I haven't rooted that down yet though).

The only issue I have right now with og_membership is that in views once you're looking at users, you can't switch out and bring in node entities via og_membership entity id (and vice versa). But otherwise it works fairly well.

There may be a use case for having a node or taxonomy term travel around to different groups or have a different membership type that does different things. I don't think anyone has fully explored what OG 7.x-1.x can do yet.

nagiek’s picture

Remember the original reason that og_membership was added: it was an entity you could add fields to. For example, date added, added by, fields can all be managed. So as for #22, I don't see what the point in taking that functionality out is.

I strongly prefer the ideas of entities to manage relations, not entity references (fields). You can't add fields to fields, but you can add fields to entities. So entities adds a lot more flexibility for the developer. I don't think entity references are the way to go.

amitaibu’s picture

> Remember the original reason that og_membership was added: it was an entity you could add fields to

Yes I remember :) What I am suggesting (and it is open for discussion of course), is that the the OG membership makes sense when it is related to a user. Right now we add an OG membership entity for every group content. So if we relate for example a Message or a taxonomy term to a group, it means we have an OG membership created for each message/term.

I think it makes sense to register a user to a group with "Expire" membership type. Doing that for a node is less likely (although in the occasion one will need it, I can think about other custom solutions). Question is do we want to keep this flexibility, and "pay" the price.

As you can see, I'm now focusing on "real life" cases for OG, rather than making it flexible just for the name of flexibility...

fago’s picture

Oh, interesting discussion!

I think a better separation between the user-membership and other regular membership makes much sense, as the relation is in the end different. Afaik, that could be done just with different membership types and audience field though anyway.

Remember the original reason that og_membership was added: it was an entity you could add fields to. For example, date added, added by, fields can all be managed. So as for #22, I don't see what the point in taking that functionality out is.

I'd agree with that. I like this flexibility and I don't see any downsides in having it, so let's have it. Stuff like expiration might be useful to node-node relations too, as well as metadata like the group-entry date!

Also, having a separate relation entity goes with the foundation idea of relation and makes much sense to me. E.g. deleting all memberships if the group entity is deleted is going to perform much better if you don't have to re-save all group content.

Lastly, the code-path then stays the same with the group-user relation. If we go with a separate, built-in, special membership type for user-subscriptions, we have the advantages of the same code-path, full-flexibility as well as the possibility to easily treat the special user-subscription relationship special. Short - I like that :)

amitaibu’s picture

> E.g. deleting all memberships if the group entity is deleted is going to perform much better if you don't have to re-save all group content.

That's how it is already working. We are deleting all the OG membership, but the field reference is still having stale data, but that's field API limitation, and I longer think OG is that one that should solve it. I thought about solving it, by not using the field's storage system, but now I think we should keep the data, so people can query the fields directly (for non users) to get the group content's associations.

> Stuff like expiration might be useful to node-node relations too

So here's another idea: We can keep OG membership's schema as-is (entity_type + entity_id), but OG will populate it only for users. Or will this be a bigger WTF?

fago’s picture

Indeed, the stale data approach is the right one here. It makes reacting upon leaving a group more complicated though as you'd have to check for group deletions too.

>..but now I think we should keep the data, so people can query the fields directly (for non users) to get the group content's associations

Imho, query-wise there is not much difference. Field values are stored in separate tables too, just as it's the case for memberships.

Which advantages do you see with storing via the field api? Saving work of syncing field values? Well, I guess I'll wait for the upcoming blog post.. :-)

amitaibu’s picture

> It makes reacting upon leaving a group more complicated though as you'd have to check for group deletions too.

Not really, I will make sure to delete the OG membership entities which are important for the user entity (in terms of user access to groups). I don't really "care" if there's still stale data in the field.

> Which advantages do you see with storing via the field api?

The advantage is that for non-users entities, where there's isn't really the notion of pending or blocked membership, we can get the groups an entity belongs to, by looking directly at the field, instead of loading OG memberships (that's the reason I think we might not need OG membership for non-users).
This behavior is actually keeping what's already going in OG now days -- we have the field values in the group-audience field, and the OG membership entity.

fago’s picture

Not really, I will make sure to delete the OG membership entities which are important for the user entity (in terms of user access to groups). I don't really "care" if there's still stale data in the field.

Yep, I was talking about node-node relations, where it's going to be complicated if there are no membership entities.

The advantage is that for non-users entities, where there's isn't really the notion of pending or blocked membership, we can get the groups an entity belongs to, by looking directly at the field, instead of loading OG memberships (that's the reason I think we might not need OG membership for non-users).

Well, I thought that's planned to be achieved via an EFQ query anyway? So you'd load the membership entities only if needed. Else you just query the table to get the entity ids, as for the field table.

amitaibu’s picture

> Yep, I was talking about node-node relations, where it's going to be complicated if there are no membership entities.

Yes, I'm talking about that as-well. og_group() is currently loading the node itself, adds a reference and saves the node. Then on field_insert|udpate|delete we CRUD the group membership. Before I thought maybe we shouldn't rely on the field storage, but now I'm thinking that as it's already doing the hard work for us, OG doesn't need to bother about it.

If we rely only on OG membership, I have to get the OG memberhip entity, load it, and extract the group ID from it. If we keep it in the field, I get it without special effort.

amitaibu’s picture

Ok guys, I accept what you are saying, lets keep OG membership as is -- it will be created for all entities, not just for users. We can always have a follow up patch on this, and anyway is minor in comparison to deprecating OG group.

fago’s picture

edit: cross-posted ;)

ok, discussed with amitaibu in IRC. Making use of an entity-relationship field indeed saves an entity_load of membership entities, so that makes sense.

While discussing, I came upon an idea I try to summarize here. Maybe, it helps amitaibu to pick some good out of it, if not it should at least not harm. ;-)

So what makes OG unique, what makes an OG group a group? It's about permissions. Imho the important features of OG are:
* make an entity to a group
* subscribe users to a group
* provide UI for managing users
* provide og roles and permissions
* provided group based access for group content, i.e. node access and field access

So with respect to those feature, OG does not need to care much about the group <-> group content relation. All it needs, is a way to lookup the groups for some group content and vice-versa in order to implement the group-based access control feature.
So why not leave managing the group <-> group content relation up to *any* field that establishes entity relations? OG could build up the entity reference field by default for the group content relation, but still it could allow marking any entity relation as "group content relation".

So, the user subscription relation is going to stay implemented as og-membership. That means there are membership entities you can attach metadata to, e.g. stuff like expiration dates. So, the membership field implements a user <-> group relation via the membership entity.

Thus, if the membership field would expose the created relation (like user<-> group) too, OG could support using the membership field for the group <-> group content relations just the same way it does for entity-reference relations. So one could decide by use-case what fits best.

That's the whole idea.

nagiek’s picture

Sorry to harp on this, but shouldn't we pick fields OR entities to manage linking? I don't like the idea of duplicate data. I understand that this is for performance reasons (check the field, not entity load), but shouldn't we just write our own function to check og_membership quickly?

DRY: Don't Repeat Yourself.

amitaibu’s picture

> but shouldn't we pick fields OR entities to manage linking?

fago and me had a very long discussion about this. The problem is that each thing has it's own benefits. I don't actually see it as completely code duplication, I think of it more as intersecting data. The field storage, gives us quick access to the groups a node belongs to. We can use EFQ to easily get this info. But we don't have metadata on it.

OG membership gives us metadata on the membership (e.g. the state of the membership). However, If we'll have only OG membership, one will need to query the OG membership, and load it to get its data. You will not be able for example to query all the nodes that are published and authored by user 3 that are associated with group Id 5 -- in one query.

nagiek’s picture

OK. Still not sure about it, but will trust your judgement :)

Grayside’s picture

Having run across duplicate and triplicate data before, and for less meaningful reason, all I can say is be sure to explore what happens when they are out of sync. That needs clean error reporting, and hopefully an automatic or drushy mechanism to fix it.

amitaibu’s picture

> all I can say is be sure to explore what happens when they are out of sync

Indeed, although note that's already the way it works currently in OG7, and so far I don't remember out-of-sync issues.

If anything, we will remove the field storage. This means we need to hook into hook_field_load() and load our OG membership, and populate the fields' value (while disregarding the docs explicit warning You should never use this hook to load fieldable entities). This also sounds tricky...

amitaibu’s picture

> This means we need to hook into hook_field_load() and load our OG membership, and populate the fields' value

Something like this (I just hooked directly into entityreference to test it, but it should be possible with #1343918: Invoke field_[op] in the handler)


/**
 * Implements hook_field_load().
 */
function entityreference_field_load($entity_type, $entities, $field, $instances, $langcode, &$items) {
  $field_name = $field['field_name'];
  if (!og_is_group_audience_field($field_name)) {
    return;
  }

  // Get the OG memberships from the field.
  foreach ($entities as $entity) {
    $wrapper = entity_metadata_wrapper($entity_type, $entity);
    $id = $wrapper->getIdentifier();
    foreach ($wrapper->{$field['field_name'] . '__og_membership'}->value() as $og_membership) {
      $items[$id][] = array(
        'target_id' => $og_membership->gid,
        'target_type' => $entity_type,
        'state' => $og_membership->state,
      );
    }
  }
}
nagiek’s picture

Can there be a discussion about not adding new features until OG is stable? This is one of the largest issue queues out there.

What about #1321232: OG incompatible with latest Entity 7.x release, #283385: Port Organic Groups menus to the Drupal menu system, or the magic formatters problem? Should this really have priority?

amitaibu’s picture

> until OG is stable?

Og is stable. It had 3 official releases, and it has a big users base. No doubt it has bugs, just like every module has.
The issues you state have no patches / or not related to og core. Anyway, I'm still maintaing the 1.x, so why not improve and simplify things in 2.x?

I think its best to stay focused on the issue itself

bonobo’s picture

RE: "improve and simplify things in 2.x"

+1

RE: "best to stay focused on the issue itself"

+1

amitaibu’s picture

For the brave among you:

  1. Patch ER with #1343918: Invoke field_[op] in the handler
  2. Create a clean installation with OG 7.x-1.x, enable og_example and create group + post content and some users, and assign those users OG roles
  3. Checkout to the 1342632 branch
  4. Disable entity (temporary until I (or you) figure out why entity API still calls the old deprecated OG group). (Fixed)
  5. execute update.php
  6. System will ask you to enable og-migrate and execute plugins
  7. Cross fingers, and hopefully you will see what I see -- your site automatically migrated :)
  8. As bonus, you can see that the "people" page where you manage members in the group is replaced by VBO!
bryancasler’s picture

I'm reading this from a phone on a train otherwise I would try it right now. Thanks for all your work Amitaibu,

amitaibu’s picture

Here's a screenshot of the people view. Using VBO, on case add/remove OG roles, and set the state of a user in a group.
Note that we can also view the user's "Request message", as it was saved as field in the OG membership entity.

mradcliffe’s picture

I wish I had some time to help test, but I'm going to be swamped for a while it seems. Sorry.

rlmumford’s picture

Came across a problem that will become much harder to solve without the group entity in the middle.

We were using Search API and Facet API and wanted to have the Group Audience of Nodes as a facet. As it happened we could just about got it to work by joining to the group_membership entity and then to the group entity, followed by a small tweak to the group entity info (I had to set the label entity key).

However, without the group entity we would have to join based on the eid and entity type which would be really tricky/impossible because you don't know what table to join to until query has been run.

amitaibu’s picture

@rlmumford,
> you don't know what table to join to until query has been run

That's not entirely correct, and lets look at it via the entity metadata wrapper. If you do:
$wrapper->og_membership->value() -- You will get an OG membership you can't know much about before.

However, assuming you have a group-audience field called "group_ref", if you do:
$wrapper->og_ref:og_membership->value() -- Then we know in advance to which field the OG membership is attached, thus we can know in advance the entity and the group types of the OG membership.

In order to achieve this, we are till missing #1388700: Allow bundles to re-define existing properties

amitaibu’s picture

FileSize
28.9 KB
38.52 KB
24.19 KB
30.87 KB
21.79 KB

sdboyer was asking me about how to make sure a group-content can belong to only a single group. This is actually the same as making sure a user can subscribe to a single/ limited groups.

In the new branch, OG is very strict about the field cardianlity. Since every OG membership is registered with a field name (i.e. the field the OG membership should appear under), we have that info.

1.jpg

In fact, OG also makes sure that if you try to add a group via a "secondary-field", there is a warning.

2.jpg

3.jpg

4.jpg

Also, the field-formatter for subscribing to group is aware to that, and if you reached the maximum group, you will not be able to subscribe.

5.jpg

amitaibu’s picture

This patch to Entity reference is now also needed -- #1399048: Pass $instance to handler

And with that patch, we have "create permissions" for group members. User will have a selection only to groups they are allowed to create in!

amitaibu’s picture

Just to emphasize, the only required patches in order to test out this branch is #1343918: Invoke field_[op] in the handler and #1399048: Pass $instance to handler
I encourage developers to start looking at this new branch...

paul2’s picture

@Amitaibu, I'm working with your new branch now, thank you. (You should have gotten an e-mail from me too.) Just modifying og_subgroups now to use the new model, seems straightforward.

paul2’s picture

@Amitaibu, I was just wondering where the list of "operations" on the "People" screen for a group have gone (deny, block, assign roles, etc.). Seems that at the moment the only way to remove a user from a group is to go to the user edit form and deselect the group from the groups field.

Edit: Never mind, found out how to add them! Since the "People" screen for groups is now a View, it just needed the appropriate actions added to the Operations drop-down (which comes in the views_bulk_operations module). I edited the view and found out where to add them myself manually - problem solved!

paul2’s picture

One more question: It seems that whenever I want to turn a node type in a "group content" type, two fields get added to it: og_group_ref and og_group_ref_other_groups. I don't understand what the purpose of og_group_ref_other_groups is? If I delete that field (since I don't think I need it?), and then make changes to the content type in the edit form and save it again, that extra field appears again.

jdruery’s picture

I'm relatively new to OG, so wasn't quite able to follow all the details of this discussion. I was wondering if the solution begin discussed will allow me to add fields to the membership entity for group content (i.e. not just for user memberships).

Here's an example use case: Group A, B, C correspond to E-mail Lists. One of the content types will be a Contact, which represents a person, company, or organization. I would like to keep Contacts as group content rather than users for various reasons, but primarily for security. Various organizations will be using the site and I can't have information about Contacts being shared between organizations. If I use users for the Contacts then each e-mail address can only correspond to one user, but in practice the same e-mail address could be in different Contact Lists belonging to different organizations. If all of these point to the same user then when one organization changes profile data for that user then it's changed for all the other organizations as well.

At the same time, I do need fields that are associated with each membership of a Contact in an E-mail List (not just with the Contact overall). For example, some of the Contact Lists are volunteer teams, and the same person can be a weekly volunteer in one team and a biweekly volunteer in another (and both of these teams might be part of the same organization, so the all the information stored in the Contact node is the same, but the weekly / biweekly setting varies from Contact List to Contact List).

I hope that this use case isn't too confusing. And please forgive me if this question is not related to this discussion (I think it is, but I'm a bit of a newbie so I could be overlooking an easy solution).

amitaibu’s picture

@paul2,

It seems that whenever I want to turn a node type in a "group content" type, two fields get added to it: og_group_ref and og_group_ref_other_groups. I don't understand what the purpose of og_group_ref_other_groups is?

This is actually already solved, make sure you git pull to the latest?
Anyway, the og_group_ref_other_groups is the field that allows administrators to associate the content with groups the user doesn't belong to. -- as now the my groups/ other groups can be easily separated.

regrading og_subgroups, great, I'd love to see a patch based on this branch.

jdruery’s picture

I realized an easy solution to my question: I can simply use an additional content type to store content related to membership in a group. So I'll have Contact List as the group, Contact List Member as the group content, and then Contact List Member will have a node reference pointing to a Contact. This will give me the many to one relationship between Contact Lists and Contacts, with fields that are unique for each membership of a Contact in a Contact List will be stored in Contact List Member (e.g., frequency of volunteering in a volunteer team), while the fields that are always true for a particular Contact will be stored in the Contact content type (name, phone, etc).

Hope this example isn't too confusing, and sorry for cluttering up the discussion. Bottom line is that it looks like this isn't a use case that requires a fieldable membership entity for group content.

Taxoman’s picture

@Amitaibu: the list in #42 about "issues for Entity reference coming out of this task" should be moved to the issue summary to ensure continued attention.

amitaibu’s picture

Issue summary: View changes

Updated issue summary.

amitaibu’s picture

Issue summary: View changes

Updated issue summary.

amitaibu’s picture

Note that the next important piece in the puzzle is #1343854: Separate "Selection" and "behavior" to different plugins, in Entity reference module.

I've updated the issue summary.

paul2’s picture

@Amitaibu:
I've just been coming across this error, and I've pulled the latest from git. It seems that when logged in as a user that lacks the permission "Administer Organic groups permissions" and I visit one of the OG node groups that user is a member of, the page doesn't load completely and this PHP error is logged:

PHP Fatal error: Call to undefined method EntityValueWrapper::getIdentifier() in /mnt/SDData/web/www/html/drupal7.selfdesign2.org/sites/all/modules/og/og_ui/og_ui.module on line 422

If that permission is enabled, however, then the page loads fine. I don't know enough about what's going on to be able to debug it further, but let me know if you need any further details from me. For now, I'm just going to turn on that permission for all my users so that the error doesn't show up.

paul2’s picture

@Amitaibu:
I have another error to report using your branch. I just git pulled the latest from your branch as well, but the error persists. Also tried git pulling latest from entityreference but there's nothing new there. I'm simply trying to associate a group with a simple node I created, using the og_group_ref field. It used to work fine, but now when I try to do so I get an SQL error in the validation handler for that entityreference field:

Column 'nid' in where clause is ambiguous

with the query being:

SELECT DISTINCT node.nid AS entity_id, node.vid AS revision_id, node.type AS b
undle, :entity_type AS entity_type
FROM
{node} node
INNER JOIN {node_access} na ON na.nid = node.nid
WHERE (nid IN (:db_condition_placeholder_0)) AND (type IN (:db_condition_placeholder_1)) AND(( (n
a.gid = :db_condition_placeholder_2) AND (na.realm = :db_condition_placeholder_3) )OR( (na.gid = :db_condition_placeholder_4) AND (na.realm = :db_condition_placeholder_5) )OR( (na.gid = :db_condition_placeholder_6) AND (na.realm = :db_condition_placeholder_7) )OR( (na.gid = :db_condition_placeholder_8) AND (na.realm = :db_condition_placeholder_9) ))AND (na.grant_view >= :db_condition_placeholder_10)

(Emphasis mine - I've identified the ambiguous "nid" using bold.) This is happening on line 1136 of in /includes/entity.inc, but being called from EntityReferenceHandler_base->validateReferencableEntities().

If you have any ideas that would be great. If not I'll just delve into the code myself. Is there another patch available that I should apply to entityreference? I believe I've applied both the patches you mentioned in #54.

Update: Funny, I can save the node fine if I try it as user #1. I guess I've never tried to do it as a normal user before. Some permissions issue... I see node_access mentioned in the query...

Update #2: Now I'm getting another error on a View where I'm listing my group nodes, perhaps since "git pull"ing your latest half an hour ago. The error is: EntityMetadataWrapperException: Unknown data property og_membership__1. in EntityStructureWrapper->getPropertyInfo() (line 339 of /mnt/SDData/web/www/html/drupal7.selfdesign2.org/sites/all/modules/entity/includes/entity.wrapper.inc). I'll try reverting git to its last state, see if that helps...

amitaibu’s picture

@paul2,

Make sure you have ER patched with #1343854: Separate "Selection" and "behavior" to different plugins
Clear cache after each git pull.

memoo’s picture

sub

BrightBold’s picture

Hey memoo, did you know you don't need to subscribe anymore? Instead, use the "Follow" button at the top of the issue. See Stop subscribing, start following for more information.

paul2’s picture

Just posting an update on my findings in using this branch:
Those errors I reported in #64 are no longer occurring for me, after git pulling both this branch of OG, the corresponding branch #1343854 of ER (#1343854: Separate "Selection" and "behavior" to different plugins), and finally flushing my cache. However, also since those git pulls I've been experiencing significant problems with OG logging in as any non-admin user. I've reported them both, and here are the links:

amitaibu’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Active » Fixed

Weekend surprise -- http://drupal.org/node/1418146

Waiting for feedback and patches...

morbiD’s picture

I found my way here via other issues. Can I ask, do the changes discussed here allow for different group membership cardinalities on users and group content nodes?

I.e. can I limit content nodes to a single group but allow users to join multiple groups? In 1.x-dev it seemed that users and nodes had to have the same cardinality because they used the same group_audience field.

paul2’s picture

Hi @Amitaibu,

I'm eager to try out your release but I wonder if you'd be able to tell me if you've made any major changes to design, field behaviour, etc., that could possibly break my installation? I'm at a January 19th revision right now, and it's been working fine for me. I'm a bit wary of updating the code lest it breaks my site and sets me back another few days trying to fix it/rebuild it. (Though I was a fool last time for not backing up my database. :P)

I have a pretty simple site: just have a few node-based groups, and some other node types that use the og_group_ref field to attach themselves to groups (I deleted the "other groups" field since I don't need it). The og_group_ref field is also used to associate users (members) to groups. I also created a separate OG entityreference field called og_parent_group which has a singular cardinality, which I needed to be able to associate groups hierarchically. Do you think this will be compatible with your updated code?

Thanks a lot, and for your great work!

jcassano’s picture

Is there an estimated timeline for when 7.x-2.x will be stable for production sites? I'm building a site now and trying to decide whether to use 7.x-1.3 or wait for -2.x, depending on how long it is. Will the -1.x branch still be maintained? I want to avoid having to migrate to -2.x a month after building the site or something.

Thanks for all the great work on OG.

amitaibu’s picture

Let's open follow up issues, but to answer last questions:

I wonder if you'd be able to tell me if you've made any major changes to design, field behaviour, etc., that could possibly break my installation?

Yes, this is almost a complete re-write. If you choose to use it already on production, is up to you, and I don't recommend so.

I.e. can I limit content nodes to a single group but allow users to join multiple groups?

Yes. See comment #52

Is there an estimated timeline for when 7.x-2.x will be stable for production sites?

I hope to get first alpha on March. Can't say about stable release yet.

bonobo’s picture

Amitai - we should be doing some testing with this in the next week.

AlanO’s picture

I just have to say it's AWESOME that you integrated a default VBO for group admins and other cool things....This stuff just gets better and better. AWESOME work Amitaibu. :)

amitaibu’s picture

@bonobo,
Great looking for your feedback!

MrPeanut’s picture

This would seem to be an issue with Rules, but it only appeared after upgrading to 7.x-2.x-dev of OG.

Notice: Undefined index: label in rules_rules_core_data_info_alter() (line 137 of /home/web/sites/all/modules/rules/modules/rules_core.rules.inc).

MrPeanut’s picture

When trying to create a new group, I get this error:

OgException: There are no OG fields in entity <em class="placeholder">user</em> and bundle <em class="placeholder">user</em> referencing <em class="placeholder">node</em> - <em class="placeholder">group</em>. in og_group() (line 1657 of /home/web/sites/all/modules/og/og.module).

amitaibu’s picture

@sirryan,

  1. This issue is closed. No need to report stuff here
  2. As you noted yourself, and might have read in the release notes, the Rules integration isn't ported yet. I encourage you to provide a patch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

WorldFallz’s picture

Issue summary: View changes

Updated issue summary.