Target Bundles settings not retained for content types

+++ b/og_ui/og_ui.moduleundefined
@@ -891,6 +891,7 @@ function og_ui_form_node_type_form_alter(&$form, &$form_state) {
+    $target_bundles = variable_get('target_bundles_' . $node_type, array());

We can't rely on the variable as it's deleted in og_ui_node_type_save(). We should use field_info_field() to get the bundles.

> is deleting a different variable name

Oopsi :) fixed.

> I'm not seeing target bundle information in the field instance settings

It should be in field_info_field()

> he other is to create a new field for every instance

This is probably the best solution.

Hi Amitaibu

Not sure why it is better creating a new field per instance, It seems that this will lead to a masive change in the og module. In the other hand the migration of the attribute settings to the instance doesn't seem time consuming, can you confirm?

Julian Mancera

@Amitaibu and @john.p,

I really need this feature to work, can you please give me an starting point start the development and submit a patch?

Regards,

Julian Mancera

Thanks for working on this.

> This patch is backward compatible with existing sites that have the default target audience field.

We don't need BC, because this is still not a final release. Let's keep our code simple.
Also please fix coding style.

+++ b/og_ui/og_ui.moduleundefined
@@ -890,7 +890,28 @@ function og_ui_form_node_type_form_alter(&$form, &$form_state) {
+        $description .= '<br/>' . t('Changes to Target Bundles will also affect these content types:') . ' ' . join(', ', $other_affected_bundles);

You should use a token (e.g. @names) inside the t(), so it will sanitize the content type name.

+++ b/og_ui/og_ui.moduleundefined
@@ -957,9 +978,11 @@ function og_ui_node_type_save($bundle_name) {
+    // Create a unique field for each bundle so settings can be different for each content type
+    $og_field_name_for_bundle = OG_AUDIENCE_FIELD . '_node_' . $bundle_name;

Lets remove this. It's a matter of taste, but for now I prefer to keep things simple and use same field.

+++ b/og_ui/og_ui.moduleundefined
@@ -968,6 +991,16 @@ function og_ui_node_type_save($bundle_name) {
+  elseif (variable_get('og_group_content_type_' . $bundle_name, FALSE)) {
+    $group_audience_fields = og_get_group_audience_fields('node', $bundle_name, FALSE);
+    $target_bundles = array();
+    if ($group_audience_fields) {
+      reset($group_audience_fields);
+      $field_info = field_info_field(key($group_audience_fields));
+      $field_info['settings']['handler_settings']['target_bundles'] =  variable_get('target_bundles_' . $bundle_name);
+      field_update_field($field_info);
+    }

I don't understand why we need this code?

> My issue was that I didn't want that to be the case.

Your issue is for more advanced users. That's why I think it's not needed.

If I might throw in my 2 cents.

If all group entities have the same field, and the target bundle information is set at the field level (rather than the instance level), then all groups must have the same target bundles.

IMHO, a novice user is more likely to be confused by different content types using the same field settings.

Separate instances are created for users and nodes, the logical extension of that is to create an instance for each bundle.

@john.p.baldwin.jr,
I need to think a bit more about your good ideas, I'm leaning towards the unique name. Give me a bit more to think about it :)

Ok, lets go back to #12

Please update also og_field_create_instance().

+++ b/og_ui/og_ui.moduleundefined
@@ -968,6 +991,16 @@ function og_ui_node_type_save($bundle_name) {
+  elseif (variable_get('og_group_content_type_' . $bundle_name, FALSE)) {
+    $group_audience_fields = og_get_group_audience_fields('node', $bundle_name, FALSE);

I think instead of letting the user edit the field here, at this stage we need to let them know any change to the field should be done via the field settings page.

Thanks, I'll revisit this as soon as #1730678: Provide a "complex" widget instead of "Primary" and "Secondary" fields. is more stable (mostly just adapting the tests), as it might need to change a bit.

#1730678: Provide a "complex" widget instead of "Primary" and "Secondary" fields. is in.

I'd like to take a different approach, with "field name callback" in the hook_og_field_info() array.

@ john.p.baldwin.jr,

While working on the migration #1774348: og_migrate is triggering error "Attempt to create a field with a name longer than 32 characters" poped-up. To make a long story short, I think what we need to keep from the patch, is just the text information about the field being shared in other instances. The unique field name is probably for more advanced usage, where I'd expect you to build your own fields.

We can also probably add this into the README, under "best practices".

there was no UI to create the custom settings for the fields og creates

In 2.x you didn't need that anymore for the group-audience, you can create a field via the field-ui with what ever name you like.

I tried patch #30.
"Content create links" will show all the content type with og_group_ref enabled "Entity reference prepopulate" and will not follow the "Target bundles".
If use autocomplete for og_group_ref, all bundles will be displayed and not follow the "Target bundles".

For "Entity reference prepopulate", please think about http://drupal.org/node/1813218 .

Isn't the main problem here that the og_group_ref field has the Target Audience under 'settings' instead of 'instance_settings'? This causes any change to said field to be globally applied to all og_group_ref instances instead of just the one you want.

Is there a status on fixing this issue?
I don't necessarily agree that the issue of having different group audiences per group is an advanced user case.
The example given about not having recipes in the sewing group, is valid and pretty simple.
My case specifically is creating a group within a group, but I can't get the behavior I need because of this issue.
I would be happy to contribute to solving this issue if some additional codereview is needed?

Is this the same issue I'm having over at #1851042: Custom group reference fields do not show up on node creation? I think it is.. which is good..

I was told to create two different "Og reference" fields via the Field UI and not use the default og_group_ref field.

But, there are two problems with that..

1) It doesn't work at all (see screenshots in the issue mentioned above)

2) How can developers then rely on OG_AUDIENCE_FIELD to determine which groups were selected?

> It doesn't work at all (see screenshots in the issue mentioned above)

It works for me on several installation, Anyway, let's deal with that in the other issue, and figure what's wrong with that.

> How can developers then rely on OG_AUDIENCE_FIELD to determine which groups were selected?

They shouldn't rely on OG_AUDIENCE_FIELD. That's where og_get_entity_groups() or using the wrapper (e.g. $wrapper->{$field_name . '__og_membership'}->value())

I mentioned several times that you *cannot* use functions like og_get_entity_groups(), when you're inside a hook like hook_node_validate() for obvious reasons. Not sure if that wrapper will work there or not..

But let's keep this issue on track.. I'll open another issue about the field constant.

First, thank you for your work on this awesome module!

As a novice user I completely agree with bulldozer2003 and john.p.baldwin.jr's reasoning for his patch which moves the organic group bundles to the instance rather than the global field settings. To me the current requirement to have to manually create new OG fields with different machine names in order to achieve anticipated results is not intuitive.

I was incredibly confused by the way OG is dealing with the default Groups Audience field. IMHO users walking through the OG UI would not expect that changing the target bundles on a new group content type will also change all the target bundles on all their other group content types.

Consider my use case. I am building a collaborative case study system where a case study consist of evidence content types (witness, testimony, photos, etc). I setup the case study content type as a group. Then I setup each evidence content type as a group content type with the case study as a target bundle.

The "Testimony" content type, however, is related to both a Case Study and a Witness. No problem I edit the Witness content type to also be a "Group" and edit the Testimony target bundles to include Witness. Uh-Oh! Now all evidence is able to be attached to a witness?

I can see benefits to both routes. All said, now that I am familiar with the process it makes sense. Perhaps this should be a documentation issue?

> which moves the organic group bundles to the instance rather than the global field settings.

That's Entity-reference does this. In D8 the bundles are indeed on the instance level.

> All said, now that I am familiar with the process it makes sense. Perhaps this should be a documentation issue?

I'd be happy if you could contribute that.

Possibly related to this, but I am seeing a problem in og_ui_node_type_save():

    $og_field['field']['target_type'] = variable_get('target_type_' . $bundle_name);
    $og_field['field']['settings']['handler_settings']['target_bundles'] = variable_get('target_bundles_' . $bundle_name);

$og_field['field']['target_type'] should be $og_field['field']['settings']['target_type'], I think.

@Amitaibu

> That's Entity-reference does this. In D8 the bundles are indeed on the instance level.

I see now, thanks. It seems the decision to create a new field for each instance achieves the same results.

> I'd be happy if you could contribute that.

Since I don't have development skills to contribute, I will test my documentation skills instead. :)

Organic Groups Version 7.x.2.x describes "How to setup a basic group?" through OG UI. That page has a note "-- Temporary save, to be continued --". I am considering adding a new child page "HowTo: Setup advanced groups and group content manually". Does this seem appropriate?

> I am considering adding a new child page "HowTo: Setup advanced groups and group content manually". Does this seem appropriate?

Very good idea.

You could take the content I added to the main page under 'Using other entity types as groups and group content' and move it into the new page too.

Guys,

This may or may not be related to this issue, but I have a problem and would like to know if its on anyone's radar to fix..

I have two "Group" content types:

Contant Type: Account (Organic Group)
Content Type: Group (Organic Group)

I have two "Page Type" content types:

Content Type: PageType1 (Group Content)
Content Type: PageType2 (Group Content)

In PageType1 I added the field
Label: Account Field: og_group_ref Type: Entity Reference

In this field, I have selected "Target Bundles" to be "Account"

In PageType2 I added the field
Label: Group Field: og_group_ref Type: Entity Reference

In this field, I have selected "Target Bundles" to be "Group"

The issue is that the field is "og_group_ref" and when I configure the targt bundle for this field, it is selected across all "Content Types" so the PageType1 and PageType2 cannot select their own Target Bundle.

I find no way to add another "og_group_ref" field.

Can there be only one og_group_ref? Is this the way it's suppose to work? Are you suppose to be able to select the Target Bundle individually in each ContentType where this field exists?

How is this supposed to work? Is it a bug?

Thanks all!

If you want different settings for different fields, you can add another group reference field with a different name. There are some disadvantages to this, in that if you're using Rules for OG notifications you'll have to create separate rules for your new field (since the [node:og-group-ref] token will only work for the content types which have the field with that name) and someone else reported that it breaks the Node Create Links functionality (I couldn't get that to work — maybe that was why; I ended up building my own but will have to edit it if a new group content type were added). But if you do this it will allow you to have separate settings for separate content types.

Hi jbarwick you are experiencing the same hurdles I did with OG. Someday when I get some time I am going to update the docs on this (creating advanced groups and group content). There is a work around which does not require coding. In short you will need to create your own fields and content create links. I used OG 2.x, Entity Reference Prepopulate, and Panels to do this.

The target bundle settings are currently not configurable at the field instance level but are unfortunately at the global level. In order to achieve different target bundles for difference content types, each content type needs its own distinct og reference field. Additionally, you cannot create multiple distinct og ref fields from the og fields ui. You need to go to admin/structure/types/manage/[YOUR_CONTENT_TYPE]/fields/. Here are the basic steps:

1. add entity reference field with unique name
2. set entity selection > mode to "og groups", other settings as desired
3. set widget type to og reference

Content create links can be achieved using entity reference prepopulate (must be at least og version 2). Just add a link to the content type using your preferred method with this format /node/add/[YOUR_GROUP_CONTENT_TYPE]?[GROUP_CONTENT_TYPE'S_OG_REF_FIELD]=[GROUP_CONTENT_ID_TOKEN]. I added each of my group content links to individual panel panes which allowed me to use visibility rules to show/hide each link depending on the user's permissions in that group.

I summarized some steps there, let me know how it goes.

What is the use of providing the target bundels for different content type if the settings for all of them needs to be remained same. Stucked with this anonying issue. Can we get some help on this please.

> if the settings for all of them needs to be remained same.

Create a different group-audience field in the "OG field settings" page

@erankyt — yes I agree we needed that functionality, but 7.x-2.x provides it by allowing you to create multiple group reference fields.

Also, FYI, if you assign an issue to yourself that means you're taking responsibility for resolving it! So I removed your name — I don't think you meant to do that.

@ Amitaibu - Thanks, it resolved my problem.

@ BrightBold - Thanks for correcting my mistake.

Got the error (Undefined index in og_user_access() on line 2076 of og.module) (after creating a different group-audience field in the "OG field settings" page). However that I have fixed as below:
$temp_perm = isset($perm[$identifier][$account->uid]) ? $perm[$identifier][$account->uid] : "";

But I am not able to access the admin page of the groups created with different group-audience field as it is giving me "You are not authorized to access this page. " even though I am logged in with the super-admin account.

Please suggest something for it.

Thanks in advance.

@erankyt — Rather than repurposing an existing issue, you should create a new issue for your error in #49 (assuming you've searched and you can't find a preexisting issue on that same problem). That way this issue stays focused on the target bundle cardinality. If issues cover multiple topics, it's hard for people to troubleshoot them and hard to know when to close them.

I had created this as an individual issue http://drupal.org/node/1941828/ , but have commented here as this issue is somewhat related to it.

I've been struggling with this scenario on a large project. We have about half a dozen different group types (node bundles that can be groups). Other content types that can be posted to a group have specific groups they're allowed to be posted do. I had noticed the settings were on the field and not the instance which led me to try to use separate fields. That led to quite a few other issues...

- Views could no longer be generic for the og_group_ref field.
- Rules had to be replicated for each field.
- Integration with search (Search API / Solr) had to be customized.
- Unable to use prepopulate.

I'm wondering if effort should be put into making entity reference move target bundle settings to field instance which should nearly fix this issue. #1340098: Move target bundle to the field instance settings It's an older issue so it's probably more about trying to backport the D8 implementation.

Question... if the entityreference module was patched to allow target bundle at the field instance level, what else would need to be done with OG?

#30: og-show_target_bundle_setting-1674078-30.patch queued for re-testing.

#30: og-show_target_bundle_setting-1674078-30.patch queued for re-testing.

+1 for #52. Having to create multiple duplicate Rules and Views to cover each specific instance of the group reference field was a major pain. I weighed in on the entityreference issue (#1340098: Move target bundle to the field instance settings) — maybe we can get that one moving and then see what else would have to happen with OG as caschbre asks.

I was caught by this issue today, in the context of testing out making subgroups.

I wanted content types Organisational Unit, Division and Team, each being an organic group with the next as the only allowed child node type. Without the target bundle in field instance settings, I'm unable to do this.

I'm trying it for a quote for a potential customer, so if the contract goes ahead I'll be creating and posting a patch.

Same problem.
When changing "Target bundles"
Groups audience > Groups audience field settings > Entity selection > Target bundles
at one content type, it makes same changed for all others.

Same problem.
When changing "Target bundles"
Groups audience > Groups audience field settings > Entity selection > Target bundles
at one content type, it makes same changes for all others.

To anyone getting this far down the thread, I think there is a fix in Organic Groups 7.x-2.x that doesn't require any custom coding. I'm still testing it on our website, but it seems to be working. You're going to be adding a new groups reference field and removing the old og_group_ref field. In the example below I'm modifying a Node type "Client". Replace "Client" with your node or entity bundle in the instructions below.

1. Go to admin/config/group/fields
2. Select the appropriate Bundle for the field (example: Node → Client)
3. Under Fields, choose "Group Audience" if it's not already selected
4. Under Field name, enter a unique field name, replacing the default og_group_ref (example: og_group_client_ref)
5. Click the Add field button at the bottom of the page
6. Now, go to the "Manage fields" page for your content type (example: admin/structure/types/manage/client/fields)
7. Your new field should be visible in the list. Apply the same settings to this new field that you used on the old field. On this new field, you will be able to choose unique settings for settings like "Target Bundles", etc.
8. Lastly, remove the old group reference field (with the machine name og_group_ref. BE AWARE that removing this field will remove any values currently stored in the field.

Does this work as I expect it should? Like I said, so far haven't run into any issues.

+1 for @thirdender comment #60. Thanks for documenting and posting the solution!

After seeing the admin/config/group/fields groups UI from step #1, everything becomes clear(er). A person can easily manage OG references for content types, and create unique relationships where necessary.

$0.02 .= As far as OG is concerned this seems to me to be more of a documentation issue and not so much a "bug", as it appears to be a byproduct of the current entityreference design, and OG already offers a clear UI with an effective and logical workaround to that entityreference design (see #60 step 1).

One more note: After following the instructions for #60, the OG Audience fields do exist on the content types, and are customizable for each. However, the fields are not shown in my UI at admin/config/group/fields, where the new OG Audience reference fields were originally added. I'm guessing this is due the machine names of the custom OG Audience fields not being recognized by that UI?

If true, I'm assuming we need to enforce/prepend a machine name prefix, then query by that?

I don't know that this is causing any problems other than my own confusion, but wanted to point it out.

@thirdender - thanks, you saved me a lot of trouble. I had already started writing my own code and messing with the database, when I find this thread and your post. Problem is now solved!

Thanks. @thirdender (or any other volunteer) maybe it's worth adding this into the docs, linking this here, and then closing the issue.

Done. I added the instructions here: https://www.drupal.org/node/2014781

Thanks!

Note for readers who skip to bottom: comment #60 @thirdender explains how to create unique organic group references between entities (eg: content types), where each OG reference retains its own unique settings.

Thread reminder: Per my comment #62, in my install I'm not seeing custom OG references/relationships in my Groups UI at admin/config/group/fields. The same relationships are accessible through the Manage Fields UI (and Views) for each content type, so they are perfectly usable, but they disappear from the Groups UI (where they are created) as noted above. Assuming it's not just me, of course. I'm guessing this is due to a query looking for specific machine names?!

The reference/relationship did show up within the Groups' Fields UI while I was creating them, but then disappeared when I returned to that page to verify settings. I may have cleared caches in the interim, but can't say for sure. At this point I have created three "custom" groups references, and although perfectly usable and functional, none of them appear in the Groups' Fields UI.

Should I create this as a separate issue?

It's not really related to the current topic, so I'd start a new thread on the matter.

I don't think it is necessary to create a new "Group audience" field in all cases like is said on #60.

What is necessary is to just edit the "Group audience" field that you already have through "Manage fields" and then change the "Target bundles" field's value. The settings there does save correctly. Notice bug here only affect when saving "Target bundles" on content type's edit page. You only have to add a new "Group audience" field If you need to have different targets in different content types.

I think this should be done:

1) @Jaypan: in that instructions you have made, I suggest to mark with bold style the sentence I reproduce here:

content types with og_group_ref can only point to either Group A or Group B, and changing the value in the og_group_ref field on any content type, will change it for all other content types.

I think this is a key sentence, so it would be better for new users to find this in bold.

2) (Patch required) User experience improving: Maybe sentence on 1 can be added on edit field form so when users edit "Group audience" field settings, they would have inline help. Another option would be a direct link to instructions made by @Jaypan.

3) (Patch required) User experience improving: Hide Target Bundles on Content Types edit pages in order to avoid users confusion. In any case it is unusable.

This issue should be fixed by a patch in some way

@rcodina: I'm new here, and I could be wrong, but re: #70 my understanding is that the og_group_ref is actually inheriting its behavior from the entityreference class(?), where one machine_name refers to one configured entityreference. My guess is that if there's going to be a patch, it's probably going to have to happen at the Entity Reference module.

On your numbered points in #69:

1) The heading for that paragraph calls attention to the specific issue, and the documentation is brief, clear, and easy to understand. My opinion is that the addition of "bold" might be distracting from an already concise paragraph.

2) & 3) I generally agree, and wouldn't mind seeing some kind of message(s)/disabled fields informing the user about this issue and referring back to @Jaypan's docs. This thread itself implies its utility. Even if it was simply referenced in the readme? Just my $0.02.

@jweirather It is just a drupal field behaviour. Fields with the same name have the same settings sitewide. I'm not asking to patch Entity Reference (ER) module, just to patch this module to avoid user confusion: just hide that field on Content Type edit page and add an info message on "Group audience" field settings. That is a Organic Groups (OG) module patch, not ER.

1) I disagree. Bold sentences are the first read sentences. Don't make users feel lost, OG module is already a module which is not very user friendly. Myself for example, took me a lot of time to find out what was going on until I read that sentence more than two times. Most site builders look for a fast solution that bold text would bring to them. The point is, to add bold style to all key sentences.

2 & 3) OG is not very user friendly, so a few more help inside drupal UI would be an improvement. Most users don't want to checkout issue list to get their problems solved:

https://www.drupal.org/node/161085

An alternative to OG which I love is Group. I like it because it has no need of documentation given the fact user interface is intuitive.

New thread readers, you may want to check out comment #60, which offers simple, step-by-step instructions to create multiple, unique group references.

@rcodina, with all sincerity, and in order: My point was that if this og_group_ref field is inheriting its properties from a class/field provided by the Entity Reference module, a module where this exact same discussion is open and ongoing, then perhaps that module is where energy should be directed, solving two issues with one patch. That said, it seems you have a better grasp on this task than I do. If you want to provide a patch, then I'm sure the community will be happy to review and test it.

1) A bold typeface is used to add emphasis (not clarity). By definition this interrupts and distracts from the flow of a page, sentence, or paragraph. The Drupal Style Guide, provided to maintain consistency and readability*, only specifies the use of bold or the <strong> tag for use in headlines and references to titles or labels.

Myself for example, took me a lot of time to find out what was going on until I read that sentence more than two times.

Clarity would be provided through better wording. If a sentence is confusing then it should be reworded. Or maybe given a more descriptive title or heading. I don't believe bolding that sentence would make it any easier to understand. Either way, if you feel that "strongly" (ha ha) about it, then I believe you can make the change on the documentation page. It appears to be open for editing by the community.

2) and 3): I think we're all in agreement about that documentation could be improved. I hope to find time to contribute to this in the near future.

As an aside, I make it a practice to look at the issue queue before I download and/or enable a module. I find that the active issues and the level of community support is often more relevant to my site building than what I find on the project page. I feel like most new users should be instructed to do the same. I've learned far more about Drupal in the issue queue than on any documentation page.

Thanks for the tip about the Group module, I'll check that out!

*If you feel the style guide should be updated, you can contact them here.

Maybe Drupal.org should offer an "expert mode" for logged-in site builders? With its own style guide, "gists", snippets, etc., to allow more advanced users to more quickly find the information they need? That might be interesting.

@jweirather Doesn't matter what is inherited from ER module, a temporary and simple CSS rule could be done to hide that "Target bundles" on content type's edit page. That issue on ER module will take so long to get solved (already 3 years old). Meanwhile a lot of users will get lost and have to lose time checking out issue list.

1) Ok, I understand.

2) Nevermind, I think this is related to drupal field module: A change on a field setting will affect every content type that have that field.

3) Using temporary CSS rule can be solved.

In any case, I just wanted to help with my comments.

@rcodina: Understood.

1) No worries, 2) I understand, 3) I understand, and inline help might be helpful too (as you mentioned).

I too was just trying to be helpful and offer feedback, I hope my tone didn't imply otherwise. Thanks for your contributions, and cheers!

@jweirather Thanks!

It's good to know that this is documented on https://www.drupal.org/node/2014781. But as jweirather mentioned in #67, the groups audience fields, with other names than 'og_group_ref', are not shown on the '/admin/config/group/fields' admin page.

Issue:Target Bundles settings not retained for content types

Solution:
Under organic group field settings (admin/config/group/fields) Add bundle for your required content type under NODE.
Add field as GROUP AUDIENCE and change the field name (og_group_ref) to unique name (like og_group_ref_1). So that each bundle gets the field name as unique machine name. Add field.

Go to manage fields of that content type and edit the GROUP AUDIENCE field, under ENTITY SELECTION select the required Target bundles and that bundle will get retained even if you select other target bundle for other content type.

TRY this solution as it worked for me.

Thanks for adding this - it was already given as a solution in #60, and added to the documentation here: https://www.drupal.org/node/2014781