Currently OG Vocab allows to associate a vocabulary to exclusively a specific group or none.
In the latter case, the vocabulary applies to all groups ("none" means "all" functionally...)

The problem is that when a vocabulary is to be shared, there are no ways to get that vocab in the specific context of the different groups.

For example, I defined a vocab called "document" for selecting the sort of documents like "News", "Specification", "Reference" that is pertinent among all groups.
However, from the group context, the vocab is inexistent and there are no ways to select the corresponding content using the Group Category Block for example. The Taxnonomy menu module could be used, but it will not restrict the items to the specific group.

Would it be possible to allow browsing the group posts from both specific and global vocabularies?

Thanks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ludo1960’s picture

Subscribing...

jvieille’s picture

This becomes critical for me.
I think this is of critical importance then using OG for groups that have some relationship to each other, and of course for project management which should be a quite favorite type of application for OG.

May we have the opinion of the maintainer on this?

amitaibu’s picture

jvieille,
If you write a patch, I'll review it.

jvieille’s picture

1) I tried something:
in on_vocab.module, I changed at line 285 the form type widget 'select' by "checkboxes":

 $form['settings']['og_vocab']['og'] = array(
       // '#type' => 'select',
        '#type' => 'checkboxes',
        ...

I actually get the possibility to multi-select group for a vocabulary.
However, this vocabulary did not appear in any group, same effect as if I select "none"
Actually, if I edit again the vocabulary settings, it appears that no selection have been saved.

My superficial knowledge of Drupal programming stops here...

2) Maybe another approach would be to not limit the browser block to display the vocabularies of the current group, but to display all the vocabularies that have terms attached to the group nodes.

3) I have read in the module's comments that this block should be integrated with views: in this case, we would be free to customize the corresponding view to make the block showing what we want.

Anyway, that should not be a big deal for a great improvement.

ludo1960’s picture

Amitaibu

How's the review coming along ? :-)

jvieille’s picture

What the maintainers think about this issue?
I would feel that having common vocabularies between selected groups should be a natural feature.
The current behavior is that common (no group specific) vocabularies are ignored by OG.
Their should be at least an option top make no group-specific vocabularies available in the context of the groups.

jvieille’s picture

Beep

jvieille’s picture

this is a really needed feature I think.
Maybe it is just because og_vocab it is designed this way that nobody could figure out the huge benefit of sharing vocab between groups.

I tried to go a little bit further.
I could do something useful by modifying the og_vocab database table.
I changed the nid field from PRIMARY KEY to a simple index.
Then I could add new rows repeating the nid group for the same vid vocab.

As a result, I could get
1) the Category block displaying the extra vocabs with the associated group nodes. (which is what I wanted)
2) the taxonomy group tab displaying the newly added vocabs, allowing any editing on the vocabulary.(which is not necessarily a good thing)

However, this is a very rough implementation that do not accommodate the current module.
When I modify the og_vocab_form_taxonomy_form_vocabulary_alter function:

from

$form['settings']['og_vocab']['og'] = array(
        '#type' => 'select',
        '#title' => t('Group'),
        '#description' => t('Select the group this vocabulary should be associated with. No association means this vocabulary can be used for <em>all</em> groups.'),
        '#options' => array('0' => t('- None -')) + $options,
        '#default_value' => $default_value,
        '#disabled' => empty($options) || !user_access('administer organic groups'),

to

$form['settings']['og_vocab']['og'] = array(
        '#type' => 'select',
        '#title' => t('Group'),
        '#description' => t('Select the group this vocabulary should be associated with. No association means this vocabulary can be used for <em>all</em> groups.'),
        '#options' => array('0' => t('- None -')) + $options,
        '#multiple' => TRUE,
        '#default_value' => $default_value,
        '#disabled' => empty($options) || !user_access('administer organic groups'),

or

$form['settings']['og_vocab']['og'] = array(
        '#type' => 'checkboxes',
        '#title' => t('Group'),
        '#description' => t('Select the group this vocabulary should be associated with. No association means this vocabulary can be used for <em>all</em> groups.'),
        '#options' => array('0' => t('- None -')) + $options,
        '#default_value' => $default_value,
        '#disabled' => empty($options) || !user_access('administer organic groups'),

I can select multiple groups for one vocabulary, but
- only the initially selected group appears - additional groups do not show as associated with the vocabulary
- when saving the vocabulary settings, the corresponding rows in og_vocab are initialized to nid=1

Ideally, what is required is:
- the ability to select several groups for association with for a given vocabulary for browsing purpose -taxonomy tab and group category block)
- the ability to separately decide which group has the ownership of the vocabulary (I think it is best to have only one as currently designed).

My use case is the following
- I have groups which work on separate research topic
- one of the groups is in charge of maintaining a global documentation for all the groups
- the research group can request documentation from the documentation group, which grants the required document to the group
- then the research group gets the documentation within their own context

The simple database tweek made it, but this would need a more proper handling

jvieille’s picture

+1

David Hernández’s picture

Assigned: Unassigned » David Hernández

Hi there,

I'm writing a patch for doing this, but has some problems. Actually the og_vocab table only can store one group per vocabulary ID, so will be required to update the DB table and I'm not sure if the maintainers of the module will agreed with that. The changes on #4 only affect to how the form is rendered and in #8, you changed the table but forgot to change the function to add new vocabs ( og_vocab_write_record ), this function loads the row using the vocabulary ID and if already has a group, updates the row instead of create a new entry. Also is required to change the hook_taxonomy to call the og_vocab_write_record function for each vocabulary.

Maybe tomorrow I will have the patch, but probably will be necessary to change more functios (maybe blocks?).

Regards,
David.

jvieille’s picture

Yes I guessed it was not so simple, and that database change was needed.
Thank you so much for taking care. This will be a huge improvement of OG_Vocab

David Hernández’s picture

Assigned: David Hernández » Unassigned
Status: Active » Needs review
FileSize
4.08 KB

Hi there,

Here is the patch. Is the first one I've done, so I'm not sure if will work. Please, tell me if you find any problem. For me is working fine but I didn't tested too much. I've created and update function in the install file, but I think is better if you uninstall and install the module again.

Regards,
David.

David Hernández’s picture

FileSize
4.04 KB

Hi again,

Please, use this patch instead of the other one. You can use the update function or reinstall the module, both solutions will work.

Regards,
David

jvieille’s picture

Thanks so much, I'll try it as soon I can

jvieille’s picture

On feature would be missing:
a vocabulary shared by several groups allows a consistent classification within groups and easy query for similar info among groups.

However, we shall be able to allocate the rights to modify this shared vocabulary to the only responsible authority(ies).

Maybe a separate issue?

David Hernández’s picture

Version: 6.x-1.1 » 6.x-1.x-dev
Component: Miscellaneous » Code

Hi again,

If my patch is commited to the dev version or to the next head release, will be better to open a new issue. If is not commited, I can try to write other patch to add more permissions but I'm not sure if I will be able to do it.

Did you review the patch and all was working fine? If so, can you change the status to reviewed & tested by the community?

Thanks,
David.

jvieille’s picture

The update fails:

user warning: Multiple primary key defined query: ALTER TABLE og_vocab ADD PRIMARY KEY (vid, nid) in /home/shareontheweb/public_html/includes/database.mysql-common.inc on line 374.

The following queries were executed
og_vocab module
Update #6002
Failed: ALTER TABLE {og_vocab} ADD PRIMARY KEY (vid, nid)

Note that I had to patch manually, because my og_vocab is already hacked (http://drupal.org/node/763308), so I may have made some mistakes.

Thanks for your help

pereljon’s picture

I would LOVE this feature!!

jvieille’s picture

pereljon, can you try this patch?
For me it failed at the update time

jvieille’s picture

One additional benefit for this feature: when someone publishes a node to several groups, it currently not gets tagged for the other groups. Having a common shared vocab would allow a broadcasted node to be properly put into OG vocab navigation for all groups.

I would love testing this patch, but unfortunately, it fails to install.
David, could have a look at what is wrong?
Or tell me what to do manually in PHPMyAdmin (In am not an SQL expert)

I cannot reinstall the module as I will test on a production site where many OG vocab are defined.

Thanks

jvieille’s picture

I deadly need this, any hope regarding this database issue?

I don't know much about MySQL, but the database scheme change in install is done by:
db_add_primary_key($ret, og_vocab, array('vid', 'nid'));

The current scheme is
Keyname_Type___Cardinality__Field
PRIMARY_PRIMARY___1_______vid
nid______INDEX_____0_______nid

Not sure how it should look like after the update.

It was great to issue this patch, it would be fantastic if we could try it!

Thanks

jvieille’s picture

+1

jcarnett’s picture

FileSize
7.93 KB

The attached patch fixes #13's hook_update() bug, a db error when updating a vocabulary, an issue causing vocabularies to disappear from the node form after you assign them to multiple groups, and an issue causing vocabulary/group associations to be lost when editing the vocabulary through the group vocabulary form.

The patch applies against 6.x-1.1 or the current -dev.

jvieille’s picture

I finally found the time to test this new patch: Simply amazing - works as expected, without any problem!
(though I had to apply the patch manually as it does not proceed on my files - maybe because I hacked the . module to address other issues)
I was dreaming for this feature for so long that I can't find the words to thank David Hernandez and Jcarnett.

I would encourage as many people as possible to test this, and also ask Amitaibu to have a look.

Thanks again for this great work!

Just in case of: what would happen if I revert the patch, will the database complain to the existing code because of the changes in the keys?

jvieille’s picture

Just some minor enhancements suggested:

1) number of items
OG Vocab displays the number of nodes for a term. With multiple groups, this number represent the total number of items regardless the group.
- Option 1: remove this indication
- Option 2: make it optional
- Option 3: count the nuber of nodes in the group instead of the total number of tagged nodes

2) Permissions
As multiple groups vocabs can be shared with group the user is not member of, editing / deleting shall be granted only to authorized users regardless their group membership

jvieille’s picture

Problem: vocabularies that are not assigned to any group are no longer available when creating associated content types

For example, I use a vocabulary to create group titles, it is associated to the content type "group"
It is no longer possible to select a term from this vocabulary

The rule shall be consistent with OG vocab current behaviour: a vocab which is not associated to any group is "public", usable everywhere (though not appearing as a vocab of the group in context)

jcarnett’s picture

FileSize
8.99 KB

Here's an updated patch that fixes two issues:

  1. Vocabularies not assigned to any group will now be available when creating associated content types. Thanks jvieille for noticing that one.
  2. Hides the group options from the standard vocabulary form if there are no groups available. It's cleaner, and solves an issue where vocabularies not associated with any groups can still end up with records in the og_vocab table.

I like your recommendations in #25. Unfortunately I don't have time at the moment to work on those. If they do come up during client work or I have some spare time to work on them I'll submit another update.

jvieille’s picture

* This patch solves the issue #26

* However, it deleted the common vocab that was shared by my 50+ groups...
I Had to revert to the previous version and restore the database.

* Regarding the number of items, I removed the indication for the time being - better nothing that an irrelevant information.
// $item = $term_link ." ($count)";
$item = $term_link ;

Thanks for following up this great improvement of OG_Vocab!

jcarnett’s picture

* However, it deleted the common vocab that was shared by my 50+ groups...
I Had to revert to the previous version and restore the database.

Nothing in the og_vocab module or this patch should be able to delete a vocabulary. Did the actual vocabulary get deleted or did it just lose the association to the groups? What steps did you take when applying the updated patch?

jvieille’s picture

I patched "manually" as the patch does not apply using tortoise merge on my files
I don't know what happened,
- everything seemed OK, checking that the non-group associated vocab was behaving correctly.
- I removed a couple of terms in this vocabulary
- For this I check these terms for clean up, by editing and saving the associated nodes to remove the obsolete terms
- Looking at one node that brought me in the context of a group, I did not found the OG vocab block
- going to the taxonomy page, the shared vocab had gone totally: no more vocab, hence terms.

Maybe I'll try to patch correctly from a fresh OG Vocab copy, mine is modified for handling Views based display

jvieille’s picture

I made a new trial.
I suspected that I deleted this vocabulary inadvertently, but this seems not the case.
After reloading OG_vocab with the last patch, everything seemed to work well initially. Then after playing some time, the shared vocabulary totally vanished.

jvieille’s picture

I found the problem:
It has nothing to do with the last patch, I just made more tests on it than on the previous one.

When a group is deleted, all vocabularies associated with the group are deleted. This was fine as long as the group owns exclusively its vocabularies.
With the new feature allowing the same vocab to appear in several groups, this must be handled differently: currently, when a group is deleted, the shared vocabularies are deleted either though is is in use in other groups.

I am not sure how this must be handled:
- let the user delete himself the group related vocabularies: a vocab which is no longer associated with any group becomes a non-og vocab - the user has to delete himself the "orphaned" vocabularies
(probably the simplest)
- add a flag to the vocab to know that it is intended to be used as a group shared vocabulary, and shall not be deleted when one or all related groups are deleted

For the time being, I have just commented out this deletion

function og_vocab_nodeapi(&$node, $op, $teaser = NULL, $page = NULL) {
  switch ($op) {
    case 'load':
      if (og_is_group_type($node->type)) {
        $node->og_vocabularies = og_vocab_get_vocabularies($node->nid);
      }
      break;
//    case 'delete':
//      if (og_is_group_type($node->type)) {
//        og_vocab_remove_all_records($node->nid);
//        foreach ($node->og_vocabularies as $vocabulary) {
//          taxonomy_del_vocabulary($vocabulary->vid);
//        }
//      }
//      break;
  }
}
Majdi’s picture

Hello,
I test The patch attached in #27, its work for me but not in the behavior I want, I will explain what I'm looking for , so maybe it belong to this post or should i Open new issue,

I have content type called articles and its og post , and it should be connected with vocabulary called Articles Category, each og should have its own terms, The only way to do this with OG_Vocab is to let each admin of space to create a vocabulary and link it to that content type "Article" but I don't want to let group admin to create the vocabulary , I want him only to have access to create his own terms , so I used the patch n #27, its work great because what i want is global vocabulary,but I still have one problem which users of og A can see the terms that added by the users of og B

I try to solve this problem by using rules ,

when a content is created 
if that content is og type
{
create og vocabulary  belong to that group and linked to content type articles
}

but in rules I can find "Remove all vocabulary from group"
I think we should have option like "add vocabulary for the group"

Should I do that by write custom php code or a fix should add to that patch to prevent og users to see terms belong to other og, or a rule should be added to create og vocabulary ?

Thanks

jvieille’s picture

If you want your groups to have their own terms, so they need to have their own vocabularies and you don't need this feature.

It is very easy to create automatically a vocabulary called "Article category" and assign it to a group using a rule that fires at a group creation. You can preset some common, useful terms as a start, so that each group has its specific vocabulary; all with the same name, where admins can play at will independently.
I did that before using this patch: to create similar vocabs in all groups

jvieille’s picture

Has anyone else tested this great new feature?
I would seek this committed, but it certainly needs some polishing

jvieille’s picture

Using this for some times now - could we consider that this feature would be committed?
It needs some improvements as mentioned earlier, but already fully functional

fadgadget’s picture

I will be interested in trying this out. thanks for the work.

fadgadget’s picture

I will be interested in trying this out. thanks for the work.

jvieille’s picture

Works great - Just needing some work / fixes
- # 25
- #32

fadgadget’s picture

ooops double posted there. Must have been a sleepy window. Thanks for all your efforts on the thread jv. I think this could be what i am after. Could i explain the way i would like to use it? My patching skills leave a lot to be desired.

Would your "News", "Specification", "Reference" etc appear in the 'Group categories' block menu jv even if they have no posts in that category within the group? I don't want to have 'set in stone categories' per group. Would the 'Group categories' block just show terms used by that group?

thanks

jvieille’s picture

@Fadgadget: as for now, the block shows all terms regardless they are used or not.

If you use the patch as is, you will get the number of nodes for the given terms, but this number is for all groups, not the number of nodes within the group you look from - I removed this feature (see #25)
Also, if you give vocab permissions to someone, he will be able to delete the vocabulary from within his group, destroying this vocab for all groups (see 32)

cray146’s picture

subscribe

jvieille’s picture

Anyone interested on pushing this interesting feature?
some polishing still needed (#25, #32), but it could possibly be committed as is

jvieille’s picture

For those interested, File Framework has an issue for propagating the term to an attached file with this change.
It is fixed here
http://drupal.org/node/1203118

jvieille’s picture

Will this feature be considered anytime soon?
Even in its current incomplete proposal, it is very convenient, it could be committed as is with proper warnings.
Thanks