Group content vocabulary/menu

good idea. hopefuly someone will contribute a patch. the idea is to create a 'system' vocabulary for each group. examples of system vocabs are image.module gallery and forum.module hierarchy

This would be very useful. But how would one assign certain vocabularies to certain groups - all groups are the same node type?!

Could every new group be a new node type? This would not work for sites with hundres of groups, but might be a solution if you have between 5 and 20 groups.

Regards,
Lennart

I will work on this. Suggestions are welcome.

Currently I think I'd like to create a vocabulary per group on group creation.

Questions include:
- Delete vocab on group deletion?
- how to deal with nodes that are removed from the group?
- the node creation process calls would let you chose the terms of a vocab at the same time when you chose the group. This is difficult. We could bypass this problem if we'd only allow free tagging vocabs.

Suggestions very welcome.

Hi Killes -- I am not a programmer, but I have thought about this. Starting with your premise...

Currently I think I'd like to create a vocabulary per group on group creation.

...As a standard this would suffice, but I think it would be great if every group would show up under admin/taxonomy so that more vocabularies could be assigned to each group - thus ensuring full use of Drupal's great multidimensional taxonomy system.

- Delete vocab on group deletion?

...Yes, why not delete assigned vocab(s)? Supposedly they are specific to the group in question anyway.

- how to deal with nodes that are removed from the group?
The would have to be stripped of group specific terms.

- the node creation process calls would let you chose the terms of a vocab at the same time when you chose the group. This is difficult. We could bypass this problem if we'd only allow free tagging vocabs.

...How is this difficult? Is it technically difficult to program, or do you refer to a usability issue?

I think *only* allowing free tagging would be a mistake.

Kind Regards,
Lennart Kiil

Lennart, not being a programmer is not a problem. ;)

I think I am ok with what you write about vocab deletion, and stripping tags from nodes when removed from a group.

Adding more than one vocab per group would certainly be possible. But due to the last issue I am not certain that it is desirable.

Now the real problem:

If you create a node with og.module you get a choice to assign it to to any of the rgoups where you are a member. That's fine. But now the problem is: On the same page you need to decide which terms to assign from which vocabulary. So we either have the choice to display allo vocabularies from all groups the user could choose and get a UI nightmare or we postpone chosing of terms to a second page after we created the node. The taxonomy_similar module does use this technique. A problem is that many users would probably skip the second step and not assign any terms. You couldn't enforce mandatory vocabs this way, which I think woudl be a bad thing.
We could also do an intermediate stp and only show the right taxonomy forms after previewing the new node. But I still think that would be confusing and not good UI.

With tagging vocabs we could just insert the tags into all of them and don't need to offer a selection on the node creation form.

Thanks for the clarification!

We want audience selection and categorization on one and the same page for workflow and usability reasons.

Audience selection is primary, so when an audience is selected the corresponding vocabs are loaded dynamically via AJAX or they can become unhidden via DHTML.

There are basically two ways of creating nodes relevant for og:

- there is the "within group" (from the group details block) method which will select the audience automatically based on which group you choose to create from. Here the vocabs will get loaded and placed under the relevant audience.

- the standard 'create content' from the users navigation block. Here the vocabs will get loaded depending on selected audiences.

eg. in the following example Physics is choosen

AUDIENCE:

Biology

Chemistry

Physics

-- Categorization:

---Topic
-Astronomy
-Classical Mechanics
-Nuclear physics
-.
-.
-More terms

---Type
-Article
-Editorial
-.
-.
-More terms

Politics
.
.
More groups

Another way to do this without any DHTML or AJAX would be like this: You have a checkbox for every audience and a roll-down menu for each vocab (ok - now we can only have one vocab per audience):

eg:

AUDIENCE:-------------------- CATEGORIZATION:

[ ] Biology ----------------------- Choose term (this is a roll down menu)

[X] Chemistry -------------------- Organic chemistry

[ ] Physics ----------------------- Choose term

Kind Regards,
Lennart Kiil

to start, i think we can only show group vocab info if the audience has been indicated. thats means that links form the group details block will have the vocab, and also all node edits. create content links will not.

once we get this done, we can tackle the DHTML display of vocabs on the create content form.

I agree - this would be a sensible solution

Kind Regards,
Lennart

I might have missed something, but how about making it possible to assign a vocabulary to specific groups in the same way vocabularies are assigned to specific node-types? I know this is more site-admin than group-admin oriented, but it would be inkeeping with the current workflow architecture.

A corollary would be to allow group admins (limited) permissions to choose & create vocabularies ... in other words add a couple more levels of permissions-access to taxonomy module, and integrate group-admin with site-wide role permissions.

I get the feeling there's a tendency to want to make each group a mini drupal installation, with the actual drupal installation becoming more like a public service provider than an umbrella organisation. I like the idea but I think it might require too much fundamental reworking of drupal to happen in dribs and drabs. Might be better to start a new SuperDrupal project ;-)

A recent change to the project module may be useful for reference, see http://drupal.org/node/32121. We added an assigned vocabulary (like in forum.module). Also like in forum, we're making special use of the first-level terms (Modules, Themes, etc.). These are the project types. Second-level terms become the categories for this particular project type--so Modules might have "mail", "xml", etc. This is similar to forum.module's "containers" (first-level terms) and "forums" (second and subsequent level terms).

Taking this approach with og might look like:

* assign a dedicated vocabulary (automatically created on first call)
* when a new og is created create a new first-level term for that group in the dedicated vocabulary
* enable adding of subsequent level terms for that group's

Doing this right likely would require some custom taxonomy handling, e.g., on node edit, show a select or checkboxes with just the appropriate 2nd+ level terms before the regular taxonomy selects, and then changed to function taxonomy_node_form() so the dedicated vocabulary could be omitted. It might also be useful to have custom term editing, as in forum.module.

Thanks for the helpful writeup, Nedjo.

Your single vocab solution has the advantage that multiple groups could share the same term (using free tagging or multiple parents feature). It will also save the admin/taxonomy page from growing wildly. Hmmm.

I chatted in IRC with killes and chx and we agreed to pursue nedjo's architecture. We will actually create two vocabs for og - one for forums and one for taxonomy in general. the a single forum term will be auto-created at og creation time. more forum terms could be badded, including containers, using admin/taxonomy page (i.e. only a site admin does this). this simplifies UI issues and 'who owns the term' issues.

i meant that last post as a design decision, not as an indication that anyone is actually working on this. patches welcome.

Has there been any follow up to this?

The design is pretty well decided but this is a significant chunk of work. I'm hoping someone steps up by submitting a patch or funding me to deliver it. Please email me if anyone is interested in doing so.

OK, I have secured some funding for this from Buyblue/Civicspace. If anyone can pitch in (at least US$200 please), that would be helpful. I nany case, it is coming in the next month or so.

Just wondering if any progress has been made with this, given that the funding was apparently secured?

Ok, sorry I posted too soon -- I see that the project exists here though it's still in CVS and has several unresolved issues... http://drupal.org/node/64094

let's use existing or new issues to discuss this further. this one has been implemented