I posted a general 'Audience required' does not work in the forums but now after more investigation it is more complicated than that.

My settings:
Visibility of posts: Only within targeted groups.
Audience required: Required

If a group member goes to 'Create content: book page' under his navigation menu (so the URL is .../node/add/book) he cannot submit a post if he does not choose a group.

However, if he navigates to his group page and creates content from there (so the url is .../node/add/book?edit[og_groups][]=54), even though his group is checked by default, he can uncheck his group and he can create a post which does NOT have a group. This post then disappears since it is not 'public' viewable as well

I am using 4.7.2 with the following modules (no other node access modules used besides OG)

attachment; basicevent; blog; book; comment; contact; diff; event; filemanager; forum; gallery; help; logintoboggan; menu;minutes; notify; og; og_baisc; og_block_visibility; og_calender; page; path; pathauto; quote; recent_blocks; rsvp; search; search404; simplenews; site_map; story; taxonomy; tinymce; user_status; webform

Weird huh?

JH

CommentFileSizeAuthor
#10 diff.diff3.23 KBwebchick

Comments

moshe weitzman’s picture

moshe weitzman commented

if true, this might be a form api bug, not og

mj2308’s picture

mj2308 commented

should I report this in the form api issues page then?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Well. This sounds rather "by design" to me. They're checkboxes. So yes, you can uncheck them. Now that the collapsed fieldset thing works you have to go rather out of your way to do so though. Say you weert looking at "Foo" group, decided to make a post, and during the course of creating it decided, "No, this really belongs more in the Bar group," you can switch audiences.

Are you advocating "hard-coding" the group as checked when you use the "create XX" link in the group details block? If so, we'd need to add a #value attribute to the current group's checkbox that could not be overridden and probably remove the checkbox widget or set it with '#attributes' => array('disabled' => 'disabled') for consistency.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Duh. I missed the "Audience Required" setting part of the bug. ;) I guess maybe check to see if the checkbox is getting a #value attribute (which cannot be overridden) rather tahn #default_value (which can) attribute or else in the validation function, if no groups were selected, select the one that matches the current group context.

mj2308’s picture

mj2308 commented

Hey Webchick =) I also ran into you for help in using the og-block-visibility module, thanks for your help!

I don't know any php or mysql, but I tried to look through the og module and these seem to be the relevant sections per your suggestion at looking for #default_value and #value.

First piece:

$options = array(t('optional'), t('required'));
  $form['og_settings']['node_form']['og_audience_required'] = array('#type' => 'radios', '#title' => t('Audience required'), '#default_value' => variable_get('og_audience_required', FALSE), '#options' => $options, '#description' => t('Do you require that all posts be affiliated with a group? If so, new users will be unable to complete a post until they join a group. Note that changing this setting has affect existing posts when they are edited.'));

Second piece:

    switch ($vis) {
      case OG_VISIBLE_BOTH:
        $form['og_nodeapi']['og_public'] = array('#type' => 'value', '#value' => 1);
        break;
      case OG_VISIBLE_GROUPONLY:
        $form['og_nodeapi']['og_public'] = array('#type' => 'value', '#value' => 0);
        break;

The first piece of code seems more relevant (not sure..) and it has #default_value, so should it be changed to #value? The second code also talks about visibility of posts though and it uses #value... Urp that's the limit of what I can do..

Thanks!
JH

moshe weitzman’s picture

moshe weitzman commented

the way i read this bug report, #required is either not being set or not being honored by form api. not much to do with anything else.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Yeah, I've confirmed this problem. Audience required works fine if you're creating a node from "create content" but if you access a link like "create forum topic" from the group details block, even though the Audience heading gets a red * like a normal required field, it happily lets you post.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Looks like this is related to the &edit[og_groups][]=# that's appended to the form action.

If I stick:

$form['#action'] = '?q=node/add/page';

in og_form_add_og_audience, the required field triggers fine.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I'm not sure this is a bug with core form API though... because for example the "Title" and "Body" required fields validate properly in both cases. Hrm.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
StatusFileSize
new diff.diff3.23 KB

As a troubleshooting measure, I stuck a print_r($form) just before the form_render call in drupal_get_form, saved the node/add/page output in one file, and the node/add/page&edit=blahblah, then diffed the two and ended up with this.

Most of these are "no-brainers" -- the current date changes, there's a default value for the group, etc. The #value => 1 change seems a little strange... otherwise, the only real difference between the two seems to be the form action?

moshe weitzman’s picture

moshe weitzman commented

i looked at this for a while and couldn't figure out the problem. anyone?

bejam’s picture

bejam commented

I am using the category module and organic groups. This problem crops up with cat module 'required' fields too. i.e. if creating a new page from the og block (with edit[og_groups][]=x appended) then the form submits even though category fields have not been completed. Would this lend back to the idea that it is a core bug triggered by appending the og group selector?

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (fixed)

no feedback. unclear.

mj2308’s picture

mj2308 commented
Status: Closed (fixed) » Active

Hi Moshe,

I just did a clean install of latest 4.7 OG on 4.7.4 and verified that the problem still exists (no other contrib modules installed).

- user navigates to any group he is in
- clicks on create content link under the Group Details block (so that the URL is http://www.example.com/?q=node/add/story&edit[og_groups][]=7)
- he can uncheck the 'Audience' checkboxes and essentially post to no audience.
- No error is thrown, the content is not registered under the group as the group's content, and the content is invisible to anyone without administer node permission.

Note that under OG settings I have 'Audience required'

- this bug happens even if the user is subscribed to only one group
- happens for all 4 types of groups, closed, moderated, open etc
- using this method, he can also post to any other group he is a member of even though the URL is of a specific target group (but I don't think this is a big problem)

When the user creates content the 'usual' way by just going to http://www.example.com/?q=node/add/story, he cannot post to no audience and he is told to select an audience.

Hope this helps..
JH

DaveNotik’s picture

DaveNotik commented

Moshe marked my issue (http://drupal.org/node/90950) as duplicate of this. I had seen this, but my issue is a little different (though I'm sure related):

The audience selection doesn't show at all, even using an older version of the module.

Administrator does not have this problem.
Authenticated user.
Accessing create content from the main navigation menu.
User is *not* subscribed to any groups.

Once user creates and owns a group, Audience field *does* show up.
I deleted the group created by user and instead subscribed to another group, Audience field *does* show up.
..so it seems Audience field does not show only if user does not have any groups (owner or subscribed to).
When Audience field does show, it correctly requires an Audience selection before the node can be submitted.

Hope that helps track this down.

--D

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Fixed

great sleuthing guys. fixed in 4.7 and TRUNK

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
dbassendine’s picture

dbassendine commented

Unfortunately I seem to still be getting this issue, on 4.7.4 and the latest 4.7 og (November 11, 2006). Posts submitted from group pages do not require an audience setting, whereas those from "create content" do.

I have tested under a stock 4.7.4 install, and the problem still occurs - so it can't be my theming or any module conflict.

Any ideas?

Thanks, David.

dbassendine’s picture

dbassendine commented
Status: Closed (fixed) » Active

(above)

moshe weitzman’s picture

moshe weitzman commented

what are your settings on the admin/settings/og page? does your user have administer nodes permission?

dbassendine’s picture

dbassendine commented

My admin>setting>og>node authoring form are: *Audience checkboxes: Y; *Visibility of posts: chosen by author/editor, private default; *Audience required: Y - do you need other settings?

Happens for users with and without "administer nodes" permission. Without "administer nodes", private posts that are not affiliated with a group simply disappear - but they do reappear outside the group context (e.g. under blog) if the user is subsequently granted "administer nodes". With "administer nodes" the post shows up, but outside group context.

Interestingly, when a normal user does select a group for a post, the audience checkbox option is no longer available when editing that post. It is available for a site admin user. I haven't tracked down which specific permission is responsible - but granting "administer nodes", "administer organic groups" does not have any effect. This is probably a separate issue?

Hope that helps, David.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Fixed

ok, i think i fixed this ... note that i had to change the syntax for passing group nid to the node form. it was edit[groups][]= and now it is simpler - gids[] =. the old syntax was confusing fapi.

i also changed 'required' preference so it does not apply to node admins.

i would appreciate if folks could test this out. this audience code has become a bit complicated, sadly.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)