Eliminate dependence on book.module

and #4 is blank. fantastic. That was supposed to say that using book.module's fieldset requires us to do a form alter to restrict hierarchies by group node type, which seems less efficient to me than not adding a form element to begin with.

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.

Sounds good. I'm online now if you want to talk. I think that part of the code will be similar to the book module's, and that this isn't a problem.

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?

Actually, I think it should be fairly straightforward to preserve that data.

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?

Yes. See #2 in my original post on 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.
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.

Thanks for being thoughtful here, Amitai. It's good to consider the options thoroughly.

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.

Your friendly co-maintainer disagrees with this approach:

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.

Multiple inheritance is a key feature for this module. Just as multiple inheritance is key to the usefulness of Drupal taxonomy, it is important to og_subgroups. It was part of 5.x, and eliminating it dramatically reduces the flexibility of og_subgroups implementations. It also happens to be central to the types of implementations that originally led me to take over as maintainer, and an implementation which should allow me to turn more attention back to og_subgroups in the coming months. I'm not willing to eliminate multiple inheritance or to wait on significantly revising the core book.module and then the next Drupal Core release. How complicated will it be to implement a stopgap patch to book.module to make multiple inheritance possible? I'm not thrilled about the idea of requiring a core patch to use this part of og_subgroups but perhaps it's worth thinking about.

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.

In a non-book dependent og_subgroups module this solution isn't necessary. Still, if we db_rewrite_sql to make sure that menu_name is written with og_subgroups_[x] rather than [book_toc_x] in order to separate the data, can we be sure that book.module loads that data properly in all cases? We have to account for more than blocks. What about other modules that rely on this data? This approach seems like it could be problematic. It seems that having multiple modules (such as og_node_access) rewrite the same sql statement might complicate this further.

Moshe also makes a good point by pointing out that the Contrib space already provides Views and Token integration for Book.module. Looking at the code that Views implements on behalf of book.module, it's pretty minimal (~120) lines and could be provided for og_subgroups fairly easily. Which brings us to the point of avoiding the duplication of code:

I think it's not necessarily true to say that we would be duplicating code by using the menu system directly. The D6 menu system is a natural fit for storing data about node hierarchies, so it makes sense that other modules would seek to harness it in a custom way. The reason we would be writing code that is analogous to book.module's is because just as analogous database queries were written in various modules before Views was available, the ability to use the menu system for storing node hierarchies hasn't been abstracted out and made available as a separate API. As we code towards the "essence" of storing hierarchies perhaps we could develop a hierarchy abstraction module that makes the menu system (which has the distinct functionality we want) available without shoehorning into the book.module (which contains code-flow and limitations that we don't want).

After further thought, with a db_rewrite_sql approach, we still couldn't have a group node be part of a book and a group simultaneously, correct?

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.

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.

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

After hacking on this for a while and trying to use the menu system to store hierarchies, it seems that the menu system is not appropriate for storing hierarchies where a node has multiple parents at the same level (and each of those parents of multiple parents). pwolanin, the maintainer of the menu system agreed that it's not the right system to use.

So, we must find another solution. Ironically, taxonomy (which was used in the 4.7 version of this module before someone decided to change the strategy) seems like the top candidate, potentially with the help of http://drupal.org/project/nat . I conversed with amitai about this and he is ok with the idea, so hopefully we can make progress on this shortly.

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:

The function in question:

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?