Menu affiliation lost when editing a node in a group, improve menu settings on administer node type form.

The problem only occurs if you have the content type configuration set to not allow the node to be added to any menus. Here's a shot at a patch against 3.x-dev. I didn't dig too deeply but a better solution would be to see if there's any way to make menu_parent_options() pick up our OG menus properly.

I can corroborate azinck's description of the conditions that the issue occurs. This is also an issue back in 7.x-2.x. I also agree about the suggestion for a better solution that shoots at the root of the issue, this is my solution which also helps restore the interface for allowing the user to place the node in the menu.

I think the comments in the code document it as well as I could reexplain, check it out.

This code might be better in hook_node_prepare?

Also:

The problem only occurs if you have the content type configuration set to not allow the node to be added to any menus.

This known architectural issue has had some mentions in previous issues.

This code might be better in hook_node_prepare?

Which code and why? justindodge and I took rather different approaches.

any code that add the needed info when there is no menu enabled

re:

The problem only occurs if you have the content type configuration set to not allow the node to be added to any menus.

imo, we should have a setting to enable nodes for use with og_menu.
I also thought about providing a widget for og menu specifically, instead of "hacking" the normal menu widget.
Ideas, thoughts and opinions are welcome. This may change a lot of things.

@rv0:

This code might be better in hook_node_prepare?

I think the suggestion for hook_node_prepare may be a good one, this could prevent the need for menu.module's hook_form_alter to be potentially called twice and so make things a little more efficient.

imo, we should have a setting to enable nodes for use with og_menu.

Actually, my first approach to this task was to alter the content type administration form to add a new "pseudo" menu called "OG Menus". This would essentially have been the first condition checked before executing the rest of my patch. I like that the user still wouldn't see all of the OG Menus in the form and be potentially overwhelmed with clutter, but still have a control per content type for allowing nodes into the OG Menus. I think this is the best approach that I can come up with, but I was finding some complication with the implementation and opted to go for this incremental improvement which at least solves the original issue (and was more time permitting).

I think it would be over doing it to have per-node control, at least by default - but I'm not sure if were implying this.

I also thought about providing a widget for og menu specifically, instead of "hacking" the normal menu widget.

Personally I'm pretty happy with the approach of having the widget in the normal location - it keeps the UI familiar and less confusing. I feel like the "hacking" is kept to a minimum since we are still relying on the menu module to fill in the form values - a widget duplicating (or nearly so) menu.module's widget actually feels more hacky to me. Plus, I think your suggestion for hook_node_prepare makes it feel altogether less hacky in general. Just my two cents.

Sounds reasonable.

I tried the content type administration approach a few times too, but got stuck and/or ran out of time for it too often.

I'm setting this to needs work and hopefully we'll find a way to cleanly solve this issue once and for all for the 7.x branch.
The latest 2 commits might have broken the current patches (have yet to try)

I provided a patch in #1872228: Rewrite og_menu_form_node_form_alter() that partially rewrote some of og_menu_node_prepare(). With that patch, I do not suffer this bug.

Patch from #10 has been committed but the bug is still there.

Changing version
For 7.x-2.x-dev => Just enable a menu for the content type, and only allow group users to "administer menus" on group level.
The plan is to fix this in 7.x-3.x-dev, then perhaps backport it

Upping priority

Changing to more descriptive title

marking #1801204: Improve OG Menu activation in Menu Settings (administer node type form) as duplicate

Setting to needs work

rv0: my fix in #2 is not very ambitious. I change very little and do not attempt to load the interface for menus on the node edit form (as justindodge attempts). My patch simply prevents the problem of a node getting removed from the OG menu when a node is edited. Getting my #2 in might be very easy low-hanging fruit. You could then try to tackle the broader interface and architectural problems later.

@azinck
If you like, this bug can be circumvented by just enabling a menu for the node type.. There's no side effects in doing that, besides that users with global administer menu permission will also see those menu options.

The high-hanging fruit is usually a lot more tasteful.

rv0: Your call. The current behavior is destructive if people don't know about the quirk. My simple fix prevents such destruction while awaiting a more full-fledged fix.

The menu affiliation bug, I am not suffering that in 3.x, is that a 2.x bug?

@bulldozer2003: i think you need a user without administer (og) menu permissions to test it.
I'm able to reproduce the issue on my development site, a fix is near.

This should be fixed in latest commit:
http://drupalcode.org/project/og_menu.git/commit/8baa699

This introduces a setting on the node type form to enable OG Menu for the node type.
Run update.php to enable this for all your group types, and the bug will be gone.
Also updated the readme file.

I'm still experiencing this with version 3.1, and the main menu workaround worked for me. It's not on a clean install though and makes use of subgroups, menu attributes and special menu items.

subgroups might be your problem anthonys.. og_menu code relies heavily on og_context function, which may not be set properly with subgroups.