Eliminate dependence on book.module

Basically I'm in favor of this. We need to plan carefully how we want to do it and be careful not to duplicate the book.module

While the 'no multiple inheritance' is important I think that the biggest reason for doing this, is to make this module more user friendly.

Ezra, we're in different time zones but lets try to IRC on it.

Hey guys -
I'm just installing this module due to its obvious greatness. Thanks for all your hard work on this important module!

I was a bit confused by the use of the book module to accomplish the hierarchy. I'm wondering: If you do eliminate the dependency, what would happen to the hierarchy in the event of an upgrade from a version that used the book module to a version that did not use the book module? Is it too hard to say whether or not the hierarchy could be preserved?

Sounds like an admirable plan to me. This is a bit like the forum admin page which is another UI for taxonomy admin.

Beware though that we might have to implement own Views integration, token integration, etc. That comes for free by depending on book.

Also, book's limitation that a node only appear once in the tree is not deliberate IMO and should be improved.

Maybe that's a direction we should take - not to eliminate book completely, but to change the UI.

@ezra_g,
Except of the single parent - is there something else that book limits us?

When I first wrote the D6 version I thought about re-writing from scratch, but soon enough I've noticed that book is doing so much work for us. I think that some hooking and altering might bring us to where we want, without replicating code.
I agree with all Ezra's remarks - in this comment I try to think how to solve them without removing the book dependency.

1) No multiple inheritance

as Moshe states it might be a flaw in the book module, we should check it. However, if this is the only restriction, then IMO it doesn't worth removing the dpenedency.

2) There is no distinction between book hierarchies and og ancestry trees.

blocks are built according book_get_books(). We can hook to the db_rewrite_sql and tell it not to bring the books that are groups.

3) Using the book.module fieldset is is confusing

Agreed - let's form_alter() it or as you suggest in #4 write a new element. We'll also have to alter the options in the select list.

Subscribing

+1 for multiple inheritance. For now, I'm trying to do this using a nodereference field from one OG node to another, and modifying views accordingly. This helps with group posts, but doesn't replace all of the great functionality of this module - following this issue in the meantime.

LS,

forgive my boldness to step into this thread, but ... I would like to bring in some other perspectives on this:

As Amitaibu stated on December 12, 2008 - 12:21 in this thread:

When I first wrote the D6 version I thought about re-writing from scratch, but soon enough I've noticed that book is doing so much work for us. I think that some hooking and altering might bring us to where we want, without replicating code.

further more was mentioned:

1) No multiple inheritance
2) There is no distinction between book hierarchies and og ancestry trees.

Considering:

• the fact OG (and OG-subgroups) tends to be used more and more in Social Networking environments. Such environments differ from traditional organizational environments or, to be more on topic, book environments. Organizational environments are rather strict in their structure, book environments even more. IMO it is important to reconsider the 'O' in OG. Organic can imply the forming of structures we never thought of.
• the ongoing trends of user accessibility to information, way's to reduce information overload, etc. It's imaginable that subgroups can be part of different groups, on different levels, with different users who have different interest.
• the aspect of (re)us(er)ability. It's IMO not only the question if a few hundred lines of code is duplicated or not. Other considerations should also be made, for instance:
  • is the module still being used as it was intended, or have groups 'organic-ly' found other fits of use for it and what does this mean for this module?
  • Who are the users (or are going to be) of this module? What do they expect of it? and what capabilities are they expected to have. At the moment of writing, there are (already) a lot (IMO to much) of questions about how to implement the module and where to find what.

Such ideas imply much more than a discussion on changing the implementing of another hierarchy (although it's a good reason to start :-) ). OG subgroups should IMO not rely on the hierarchy of the book module, but develop to a next level.

This post certainly means no disrespect to the maintainers and contributers of this 'damn good' module, but to point out several opportunities for the future. Not alone for OG-subgroup, but also for the whole OG-module. I think there should be a (re)consideration whether or not wanting a dependency on the book module for OG-subgroups, or design a new approach on the matter.

I've some other points of view on this matter I'm willing to share, so if there is going to be a discussion on the topic, I'll #subscribe :-).

Best,
VinceW

also consider the fact that there is no way to limit the depth right now

personally, I'd go for a fully independant way of handling things, making this rely on other modules will most likely break compatability and customizability

but if you must, taxonomy does seem like the best candidate, since it will still allow you to create other vocabularies to work with on the same site, you will be able to set a limit on the depth and the depth can even go infinite...

it would also allow you to make a group a subgroup of more than 1 top level group (and even make it a subgroup of a top level group AND a non-top level group) and it would simplify the input form to a single drop-down list (with an extra one for weight I guess)

don't mind me I am just subscribing.

subscribe

subscribing

Edit: Programmers: if you need help, I can do things. Tell me and I'll look what can I do.

What do you think about using Node2Node or Node Relativity to provide this functionality?

Perhaps they are better than Book. If anything, you can use them for inspiration.

I think it's better to eliminate dependencies to other modules, but taking the ideas from there is not a bad idea.

subscribe

Subscribe.

Just a comment for others looking to implement subgroups and having books functionality. We have just implement Node Relativity Works great. You don't get the inheritance of subgroups, but it does fit our need. Worth a look at in some cases..

@erle That module does look promising for this use, except that I don't see how it could propagate content or users up or down the hierarchy. Am I missing something, or is this the case?

@smithn.nc your right, its not a replacement for subgroups. Just suited our purpose, I'd left a placeholder for anyone else stumbling in after me, since I found @phibar 's comment extremely useful.

We do not need to propagation so never looked that deep. Perhaps a custom workflow to overcome shortcomings? Since we wanted books, we really had no option, but thankfully this option did the trick for us.

@ezra-g

Rather than postpone a 6.x version further in pursuit of a more complex solution, I intend to port one of the 5.x versions to Drupal 6. I hope to have a stable release by the end of March.

Being in need of a D6 version of og_subgroups that does not have a dependency on the book module, I have ported the 5.x version to 6.x. This is a straight port and does not add any new functionality. I'm not sure what to do with this port as far as contributing it back for those who prefer the way that 5.x worked. I'll attach a tarball for now.

subscribing

umm, thanks will test it and report back.

Subscribing

Thanks for this, tested both "Group/User propagation" settings and everything looks good on Drupal-6.13 with -dev modules. Will report if I run into any bugs. This should be RTBC.

"I have ported the 5.x version to 6.x...I'll attach a tarball for now."

How is this supposed to work in a 6.x environment? The .install module doesn't seem to run, resulting in "og_subgroup" table not found errors when you try to edit a Group.

@BayouBill : the error u experienced is probably due to the ugly mac OSX trash left behind in the tarball, although when I tested it with an without the mac-trash, in both occurrences it successfully created the og_subgroups table and no errors were thrown

"the error u experienced is probably due to the ugly mac OSX trash left behind in the tarball"

If you are referring to the files in the tarball that began with ".", I got rid of those, winding up with an og_subgroups folder that contained just the following:

INSTALL.TXT
og_subgroups.info
og_subgroups.install
og_subgroups.module
README.TXT

I did the standard upload of that folder and activation in Modules, but when I went to edit a Group, I got a "table acctname.dbname.og_subgroups doesn't exist" error. I tried playing with the og_sg configuration settings, but no joy. I tried running the Drupal Update function, but that didn't generate any results. It appears that the .install module doesn't function. I've attached it as a .txt file so the author can verify that I have the right one.

Help!

Well, Duh Is Me, because on closer examination all the .install code has been commented out. I've manually built the og_subgroups table and am no longer getting the "table not found" errors. If there are any other db mods I need to do manually, please advise.

Also, where is the documentation on how to use the 5.x version of this module?

"Being in need of a D6 version of og_subgroups that does not have a dependency on the book module, I have ported the 5.x version to 6.x."

Okay, I've installed the above (comment #30, http://drupal.org/comment/reply/337808/1783018#comment-1783018), which is supposed to be a port of the Drupal 5 version of og_sg to Drupal 6 (I've done this because I'm pretty sure the current "book" approach of the D6 version won't work for me.) It seems to be working fine, but I've tried to implement my project and am running into some deadends. So, I am basically asking if this version of og_subgroups will allow me to do the following. I think the issue is "multiple inheritance", which as noted at the top of this thread the "book" approach does not support, but I don't see how the ported Drupal 5 version of og_sg supports it either.

My civic group wants to expand its Drupal site to perform what we are calling "Neighborhood Notices". The concept is as follows:

1. We will set up og groups for any "entity" for which we want to post a notice. For example, each of our council districts.

2. We will set up og groups for each of the "subdivisions" in our community.

3. We want to set up a structure that allows us to define which "entities" are included in each "subdivision". An "entity" can be included in multiple "subdivisions". In other words, part of a subdivision may be located in one council district, and another part of the same subdivision may be located in a different council district.

4. People (Drupal Users) would indicate which "subdivision" they belonged to on their registration page (i.e. "Registration form" would be set on for the "subdivision" groups, but not, to keep the UI as simple as possible, for the "entities").

5. We want to be able to post a notice to an "entity" and have it propagate to all of the "subdivisions" that include it. So, posting to "council district 1" would propagate to all of the subdivisions located in that district. By propagate, I mean (using the context of og_sg), we want the "council district 1" notices to be visible to anyone who is a member of any of the subdivisions in district 1, and, more importantly, we want a notice of the new content post to be sent out to anyone who is a member of those subdivisions.

The problem I've run into with og_sg is that I cannot tell the module that, using the example above, both "subdivision a" and "subdivision b" include "council district 1" (i.e. that "council district 1" has multiple parents).

Can I accomplish this with any version of og_sg or some other combination of og modules?

please don't change the title to something less descriptive

if the issue concerns subgroups in general please make a separate issue

My previous post changed the title of the issue. Posting this to correct. Sorry.

just subscribing... since this is like one giant issue, is anyone working on it breaking the task into smaller parts?

Its good to see that work is continuing on this module. I see a post as recent as 2.5 weeks ago.
I guess I should be patient and wait, but I think I'll just go ahead and register my desperate need for this module....just in case no one else had done so. I'm in the middle of a project, and my developer committed to using this module eventhough it was clearly in dev. status. I trusted him, and now I think he is stuck. Speaking from the perspective of a user, the interrelationship between Book.module and Subgroups is quite confusing.

1) Is this interdependence documented (in operational detail) anywhere?
2) Is there any possibility of getting a simple version released soon (end of Sept 09?), while the greater complexities get worked out?
3) When do you anticipate a stable release of the full version?
4) Are there any workarounds (perhaps using the main Groups modules) to implement subgroups..?

Thanks for your work on these important modules.

Subscribing.

> mal wrote "Are there any workarounds"

The D6 port at #30 worked for me, but note that it does not support multiple inheritance.

Yes--I am asking my developer to take a close look at that. I'm not quite sure of the implications of "not supporting multiple inheritances". But it may be good enough for me. But what about comment #38. Is that still an issue? If so, how does one deal with it?

"what about comment #38. Is that still an issue? If so, how does one deal with it?"

Run the attached php code (*), which just contains the code from the #30 .install module that builds the necessary table. That's how I did it in #38.

Standard Disclaimer: Use at your own risk and backup your database first!

Edit:(*) Create a page, insert code, specify PHP Code as the Input Format, save the page, and view it just once. The other way to do it is to use PHPMyAdmin to go directly to your database and cut and paste the query into a SQL box.

Since recent upgrade of organic groups patch at #30 no longer works. The error I get when going to subgroups tab is:

    * user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT(n.nid) FROM node n WHERE ( 1=1 ) AND ( n.type IN ('group') AND n.sta' at line 1 query: SELECT n.title, DISTINCT(n.nid) FROM node n WHERE ( 1=1 ) AND ( n.type IN ('group') AND n.status = 1 )ORDER BY n.title ASC in /og/og.module on line 1604.
    * user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT(n.nid) FROM node n WHERE ( 1=1 ) AND ( n.type IN ('group') AND n.sta' at line 1 query: SELECT n.title, DISTINCT(n.nid) FROM node n WHERE ( 1=1 ) AND ( n.type IN ('group') AND n.status = 1 )ORDER BY n.title ASC in /og/og.module on line 1604.

The function in question:

// Return an array containing all groups - suitable for a form item.
function og_all_groups_options() {
  list($types, $in) = og_get_sql_args();
  $sql = "SELECT n.title, n.nid FROM {node} n WHERE n.type $in AND n.status = 1 ORDER BY n.title ASC";
  $result = db_query(db_rewrite_sql($sql), $types); <-------------- line 1604
  while ($row = db_fetch_object($result)) {
    $options[$row->nid] = $row->title;
  }
  return isset($options) ? $options : array();
}

Subscribing.

We are going ahead with current dev snapshot of 6.0 og_subgroups hoping that the later release will provide an upgrade path, even if it removes book module dependency.

Thanks

Is CVS current? I see code being posted after the last commit date. If I was going to build on this module, what is the best code base to work from?

Subscribing

Any progress in the issue? I would love to see the first release of this module asap. Can I help anyhow?

Just subscribing.

subscribing

Subscribing. Would like to help with development.

subscribing

subscribing

subscribe

subscribe

subscribe

Subscribing
Really hoping to see progress in this matter. Especially with OpenAtrium this could rock! Me too can help if needed.
Imho, the book dependency is not bad at all. let's keep it :)

Has there been any progress on this? It seems that there is a lot of interest, but I do not see any recent activity. Does the port of the 5.x module to 6.x work? #48 seems to indicate that it does not, however I have not tested myself. I am interested in pursuing this or helping to develop this module.

sub

The D7 version of OG handles subgroups pretty cleanly. I think a D7 version of this module will look very different. Its probably best to focus on D7, IMO.

Hi Jeremy,

I think that the best option is to create a new module for D6 that can start fresh on these issues. May be a good idea is to see how D7 solves this functionality.

emi

The one thing this module does *not* need is any more dead ends. IMHO, multiple inheritance is essential. If the D7 version of Groups (nee OG) will handle subgroups with multiple inheritance, I don't see the point of trying to perpetuate this module. On the other hand, for those not needing multiple inheritance, but needing D6 support for this module, I think a port of the D5 version to D6 would be the most logical place to invest time and effort. In any case, I think the current design of this module, based on books, was a bad idea and should be abandoned.

@ezra-g

The port in #30, is a strait port from D5 code. I think we can branch out D6, and commit it there -- it seems that the book dependency wasn't the best thing after all ;)

there is now a 6.x-1.x-dev version available that does not have a dependency on the book module.

Thank you very much, bschilt.

A related discussion is Subgroups for Organic Groups Rewrite.

This would eliminate a ton of issues I've had to overcome with end-user training :-) subscribing now!