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
Comments
Comment #1
amitaibu#1246662: Use Entity Reference in OG as group audience field
Comment #2
fagoAlso, 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?
Comment #3
amitaibuI agree with the Pros, I wish I made Og a bit less flexible in that sense to begin with ;)
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...
Comment #4
KarenS CreditAttribution: KarenS commentedThis 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.
Comment #5
amitaibu> 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
Comment #6
mradcliffeI 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.
Comment #7
KarenS CreditAttribution: KarenS commentedIt 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.
Comment #8
Crell CreditAttribution: Crell commentedAlso 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!
Comment #9
mradcliffeI 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.
Comment #10
amitaibu> 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:
Comment #11
Itangalo CreditAttribution: Itangalo commentedAs 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?
Comment #12
amitaibu> 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.
Comment #13
awt CreditAttribution: awt commentedWhat 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,...).
Comment #14
amitaibu> 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.
Comment #15
Itangalo CreditAttribution: Itangalo commented> 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.)
Comment #16
Jody LynnI'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.
Comment #17
amitaibu> 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
Comment #18
thomas1977 CreditAttribution: thomas1977 commentedJust 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!
Comment #19
Taxoman CreditAttribution: Taxoman commentedPlease have a look at this post I just made:
#1352176: Stable, medium-to-long-term perspective for OG developments
Comment #20
nagiek CreditAttribution: nagiek commentedJust curious, why is group_audience still being kept around, period? Why isn't it deprecated in favour of the og_membership entity?
Comment #21
BrightBoldEven 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.
Comment #22
amitaibuI'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?
Comment #23
bonobo CreditAttribution: bonobo commentedWhat 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 :)
Comment #24
amitaibu> 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.
Comment #25
mradcliffeYou'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.
Comment #26
nagiek CreditAttribution: nagiek commentedRemember 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.
Comment #27
amitaibu> 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...
Comment #28
fagoOh, 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.
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 :)
Comment #29
amitaibu> 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?
Comment #30
fagoIndeed, 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.. :-)
Comment #31
amitaibu> 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.
Comment #32
fagoYep, I was talking about node-node relations, where it's going to be complicated if there are no membership entities.
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.
Comment #33
amitaibu> 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.
Comment #34
amitaibuOk 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.
Comment #35
fagoedit: 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.
Comment #36
nagiek CreditAttribution: nagiek commentedSorry 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.
Comment #37
amitaibu> 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.
Comment #38
nagiek CreditAttribution: nagiek commentedOK. Still not sure about it, but will trust your judgement :)
Comment #39
Grayside CreditAttribution: Grayside commentedHaving 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.
Comment #40
amitaibu> 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...Comment #41
amitaibu> 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)
Comment #42
amitaibuHere are issues for Entity reference coming out of this task:
Comment #43
nagiek CreditAttribution: nagiek commentedCan 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?
Comment #44
amitaibu> 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
Comment #45
bonobo CreditAttribution: bonobo commentedRE: "improve and simplify things in 2.x"
+1
RE: "best to stay focused on the issue itself"
+1
Comment #46
amitaibuFor the brave among you:
Disable entity (temporary until I (or you) figure out why entity API still calls the old deprecated OG group).(Fixed)Comment #47
bryancasler CreditAttribution: bryancasler commentedI'm reading this from a phone on a train otherwise I would try it right now. Thanks for all your work Amitaibu,
Comment #48
amitaibuHere'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.
Comment #49
mradcliffeI wish I had some time to help test, but I'm going to be swamped for a while it seems. Sorry.
Comment #50
rlmumfordCame 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.
Comment #51
amitaibu@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
Comment #52
amitaibusdboyer 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.
In fact, OG also makes sure that if you try to add a group via a "secondary-field", there is a warning.
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.
Comment #53
amitaibuThis 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!
Comment #54
amitaibuJust 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...
Comment #55
paul2 CreditAttribution: paul2 commented@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.
Comment #56
paul2 CreditAttribution: paul2 commented@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!
Comment #57
paul2 CreditAttribution: paul2 commentedOne 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
andog_group_ref_other_groups
. I don't understand what the purpose ofog_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.Comment #58
jdruery CreditAttribution: jdruery commentedI'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).
Comment #59
amitaibu@paul2,
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.
Comment #60
jdruery CreditAttribution: jdruery commentedI 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.
Comment #61
Taxoman CreditAttribution: Taxoman commented@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.
Comment #61.0
amitaibuUpdated issue summary.
Comment #61.1
amitaibuUpdated issue summary.
Comment #62
amitaibuNote 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.
Comment #63
paul2 CreditAttribution: paul2 commented@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:
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.
Comment #64
paul2 CreditAttribution: paul2 commented@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:
with the query being:
(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...
Comment #65
amitaibu@paul2,
Make sure you have ER patched with #1343854: Separate "Selection" and "behavior" to different plugins
Clear cache after each git pull.
Comment #66
memoo CreditAttribution: memoo commentedsub
Comment #67
BrightBoldHey 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.
Comment #68
paul2 CreditAttribution: paul2 commentedJust posting an update on my findings in using this branch:
Those errors I reported in #64 are no longer occurring for me, after
git pull
ing 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:Comment #69
amitaibuWeekend surprise -- http://drupal.org/node/1418146
Waiting for feedback and patches...
Comment #70
morbiD CreditAttribution: morbiD commentedI 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.
Comment #71
paul2 CreditAttribution: paul2 commentedHi @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!
Comment #72
jcassano CreditAttribution: jcassano commentedIs 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.
Comment #73
amitaibuLet's open follow up issues, but to answer last questions:
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.
Yes. See comment #52
I hope to get first alpha on March. Can't say about stable release yet.
Comment #74
bonobo CreditAttribution: bonobo commentedAmitai - we should be doing some testing with this in the next week.
Comment #75
AlanO CreditAttribution: AlanO commentedI 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. :)
Comment #76
amitaibu@bonobo,
Great looking for your feedback!
Comment #77
MrPeanut CreditAttribution: MrPeanut commentedThis 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).
Comment #78
MrPeanut CreditAttribution: MrPeanut commentedWhen 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).
Comment #79
amitaibu@sirryan,
Comment #80.0
WorldFallz CreditAttribution: WorldFallz commentedUpdated issue summary.