Write groups into {og_ancestry} as regular nodes

Thanks,

Yes this is very broken (which I understand as it is a rewrite). I have tested and I can change the parent of a sub group to a different region but the view still states that it is in the old group (set prior to the upgrade). So while the new table updates are working the module has left details behind in the {og_ancestry} table.

Its really the view integration of OG that has been broken. All I am trying to do is display the name of the Group that a sub-group belongs to. Much is the same way the I could display the name of the group(s) that a story or any other node belongs to.

Is the sub group no longer truly part of the OG group?

Is this on a time-line to be looked at? My whole site is based on OG, OG subgroups and Views ...

My situation gets worse. I don't really have a path out of this. Could you explain why you are no longer updating the og_ancestry table? It seems kinda core to the og module. I'm happy to help anyway I can, I'm no PHP expert but have strong software engineering experience in a wide range of other areas. I can certainly poke around in the code and test .

A bit more detail on my current issue.

At the SQL level, this query displays the current hierarchy as I would expect.

SELECT a.parent, ng.title, ng.type, a.gid, nc.title, nc.type 
FROM og_subgroups a, node ng, node nc
WHERE nc.nid = a.gid
AND ng.nid = a.parent
AND nc.type = 'Club'

parent 	title 	type 	gid 	title 	type
66 	Australia 	region 	78 	Albury 	club
66 	Australia 	region 	79 	Erskine Park 	club
66 	Australia 	region 	80 	Pilbara 	club
66 	Australia 	region 	83 	Lock 	club
30 	USA 	region 	98 	Cuba 	club
28 	UK 	region 	19 	Bedford 	club
28 	UK 	region 	87 	Belfast 	club
28 	UK 	region 	88 	Bexhill 	club
28 	UK 	region 	106 	Alloa 	club
28 	UK 	region 	108 	Romford 	club
28 	UK 	region 	121 	Bromley 	club
28 	UK 	region 	130 	Sittingbourne 	club

However, I still have hierarchy data in the og_ancestry table. This has been left over from the the previous version of og_subgroups and this is the only thing keeping some of my views working (which fooled me into thinking everything was okay).

SELECT a.group_nid, ng.title, ng.type, a.nid, nc.title, nc.type 
FROM og_ancestry a, node ng, node nc
WHERE nc.nid = a.nid
AND ng.nid = a.group_nid
AND nc.type = 'Club'

group_nid 	title 	type 	nid 	title 	type
30 	USA 	region 	98 	Cuba 	club
28 	UK 	region 	88 	Bexhill 	club
28 	UK 	region 	87 	Belfast 	club
28 	UK 	region 	19 	Bedford 	club
66 	Australia 	region 	79 	Erskine Park 	club
66 	Australia 	region 	83 	Lock 	club
66 	Australia 	region 	80 	Pilbara 	club
66 	Australia 	region 	78 	Albury 	club

Without updating the og_ancestry table the sub groups are in effect not part of the parent group. I can write a quick SQL script that will fix the og_ancestry table based on the og_subgroups table, but what would the collateral damage be. I need to understand why you are no longer updating the og_ancestry table in the first place.

A small point also. The change in naming conversion og_ancestry.group_nid->og_subgroups.gid is slightly confusing. I'm not sure what the db standards are so I can't comment really on which is correct. And should 'parent' not be parent_nid?

Like I say. Happy to help anyway I can.

I'm not missing anything. The Views integration of Organic Groups is broken by this module. In my view this makes this module non-compatible with the current version of OG. Which is a significant problem.

Quite simply a SubGroup is no longer part of the Group. It was before. This means that you can't create views that display details from the sub groups of a group. As I stated before you can create a view of all the nodes that belongs to a group as it is maintained in the og_ancestry table. A sub group is still just a node that belongs in the parent.

Also, because the upgrade does not clean up the old data in the og_ancestry table at first glance it appears to still be working. It is only when you start to add new subgroups that you realise that it is in fact broken.

Anyone that is using views with OG that upgrades to this version will suffer the same issue. I understand that you have no plans to integrate Views with this module but you should not break the Views integration of OG.

Okay, I'll try and set up a vanilla install of Drupal, Views, OG and OG Sub Groups so that I can demonstrate this issue and give you access.

The scenario I current have is this:

1. I use OG , OG Subgroups, Views and Panels
2. I have a two group types, lets just call them group and subgroup.
3. I create a group (A) and post content to it, stories etc.
4. I have a Panel (with gets passed a GID for the group) which displays information of the the group node and also panels with details of the posts to that group.
5. I then create several subgroups (X,Y,Z) and set their parent to be the group (A)
6. I need to be able to see the list of subgroups for the given parent by using a view with a filter on Type=subgroup. This would work fine in the old world as the subgroups belonged to the group just like any other node. Now the only thing that knows that the subgroup is a subgroup of group is the subgroups module.

On my live site I actually use this with gmap and location. Each subgroup has a location and displays on a map. Only subgroups that belong to the group are displayed on the group page panel.

To fix my immediate issue: you had previously left the data in og_ancestry. So does it do any harm? Can you think of any nasty side effects from me dumping the hierarchy back into this table as a one off (and temporary fix)?

I still think that you should warn potential users of this issue as it is a significant change over the previous implementation. This version of subgroups does not deliver the same functionality as the previous version. The release note

This is the first official release of the rewrite by Amitaibu which is more stable and better coded than the previous version. Users of the 5.x-3.x version can safely upgrade to this version.

Is not really true. The stable and better coded part certainly is ... but some users can't upgrade safely. Views, Panels and OG seem to be referenced as a powerful group and recommended often so I assuem that I am not the only one that will hit this issue.

I hope this does not sound critical, I certainly don't mean to be, the module seems to work in every other way. I'm very willing to help resolve this anyway I can.

I certainly didn't mean to imply the statement was dishonest, simply that people that upgrade to this version need to be aware that it works differently and will break any views of a groups sub-groups.

Sub-group nodes are no longer associated with the group in OG (og_ancestry). This means that the standard Views integration of OG will no longer pull out the subgroup nodes along side the rest of the nodes that are associated with the group. You do update og_ancestry when you call og_subgroups_propogate_content() so all nodes other than subgroup will belong to the parent group. Its just the subgroup that does not.

This is a fundamental change. If it is by design then that is fine but we need to be clear that there is not a clear upgrade path. In fact I can't see anyway to replicate the old functionality without changes to the OG module.

I don't see why one module writing to another modules tables in this instance is an issue. OG subgroup has an absolute dependency on OG, so maintaining the relevant OG data is surely a requirement for the module. Interfacing to the module through its og_save_ancestry() function as you have for the content would seem correct to me.

While having a look I just noticed the the pqsql lines in the og_subgroups.install module (line 15, 76) still refer to {og_ancestry} rather than {og_subgroups}.

We are going is circles here. I still believe that this is a bug and by flagging at as 'by design' it hides it from general view.

1. While you believe this to be a hack it meant that a subgroup was treated the same way as any other node. As a subgroup is just a node, why should it be treated differently.

2. Your question:

Will an og_subgroups integration with views solve you issue? (i.e filter all groups that their parent is XYZ).

Answer:

No. I need to be able to build a view that lists out all the nodes that belong to a group, this includes all the content nodes AND any subgroup nodes ... and any subgroups of those subgroups etc.

Posted here as I don't want to taint the new issue.

I will try and contribute but this is not really the direction I believe that I need to head. As far as I am concerned a subgroup is just content, the same as any other node. I have CCK fields added throughout and I just want it to be a normal node, not a special case. I can't create it as a non-group node as it needs to be able to have members etc (e.g. OG group functionality).

I guess what I really need it an option to 'Treat subgroups as content' which if true would propagate the subgroup-parent mapping into the og_ancestry table just as it does for non-group nodes. If turned off it would delete all the mapping from the og_ancestry table to provide your 'pure group' functionality. I have hacked a SQL fix to do this on my site and this make everything work just fine (views, panels etc).

I understand your option but continue to disagree. Developing separate View integration of subgroups and then requiring views_fusion is unnecessary and over complex, adds unnecessary bulk to this module and duplicates functionality. My views are complex enough as it is without having to combine them together. Reapplying this simple fix makes OG, OG Subgroups and Views & Panels work seamlessly and allows a direct upgrade from the previous version to 5.x-4.0.

I will follow the other thread, to see where you are headed but for now will have move away from these releases, get my PHP manuals back out and start coding again!