Limit Menu Items During Content Creation

Work on this should be tested and fixed in testWorkbenchAccessMenu().

Sure. Sorry for the delay, I've been out of office for 2 weeks.

BTW, the reason we don't do this now is that it's actually pretty hard to do correctly.

Yes it is hard, for my part I resolved partially the needing like this. I didn't thicked the "Limit Menu Items During Content Creation" box as some of my section are purely lists of teaser and then it would have been impossible to create a menu item for each content created within this section.

However, for the rest of the website, I am using this snipper on node_form_alter:

<?php

  $parent_links = array();
  $parent = $form['menu']['link']['parent'];
  // Format the list of provided menu items by mlid, this will allow easier
  // sorting and filtering in the next algorithm section which aim to restrict
  // the menu link to allowed only.
  foreach (array_keys($parent['#options']) as $parent_key) {
    // The menu options are in the following form: headlines:0. Explodes them to
    // get the parent section in the case the mlid is equal to zero, or the
    // current section with its corresponding menu link ID.
    list($section, $mlid) = explode(':', $parent_key);
    // Treats menu link ID 0 as a parent section, otherwise as a sub-section.
    $parent_links[empty($mlid) ? $section : $mlid] = $parent_key;
  }

  $parent_options = array();
  $active_options = workbench_access_active_options();
  // Do not allow itself to be its own parent, as it can cause high troubles
  // with potential infinite loops deep in the menu system.
  $active_options = array_diff_key($active_options, array($form['menu']['link']['mlid']['#value'] => ''));
  // Restricts menu selection to user available sections only.
  foreach (array_keys($active_options) as $section_key) {
    $parent_key = $parent_links[$section_key];
    $parent_options[$parent_key] = $parent['#options'][$parent_key];
  }

  // Replaces the menu parents options with the restricted list of user section
  // access only. This way a user cannot create a page in a section he cannot edit.
  $form['menu']['link']['parent']['#options'] = $parent_options;
?>

Then in the hook_node_insert:

<?php
// Creates the section object to be passed at the workbench access API.
    $section = array(
      // The access id is the newly menu link ID (mlid). This value is computed
      // by the menu API and the link is created at this moment of the process.
      'access_id' => $node->menu['mlid'],
      'access_type' => 'menu',
      'access_scheme' => 'menu',
      // Added @ to suppress warning for the sake of writing a one liner code
      // instead of writing a variable declaration then array_shift...
      'access_type_id' => @array_shift(explode(':', $node->menu['parent'])),
    );
    // Assigns this node to the newly created workbench section. That way user
    // can create menu hierarchy on-the-fly on the section he is assigned.
    $node->workbench_access = array($node->menu['mlid']);
    // Creates a workbench section when not already existing. The function
    // bellow uses the value 'workbench_access_exists' under the hood to define
    // if updating or creating a new section.
    workbench_access_edit_form_submit((array) $node, $section, $node->menu['link_title']);
    // When a section is created for the first time, also assign the node's
    // author to this section. The user becomes the first owner of this
    // section and is able to create on-the-fly sub-sections without the need
    // to manually assign itself in the workbench configuration screens.
    workbench_access_user_section_save($node->uid, $node->menu['mlid'], 'menu');
?>

It has the effect creating a workbench section based on the new menu item created, and affect the author as the newly created section. This way the author can create sub-sections and so on without granting him the full menu admin access.

To solve completely the problem, I think you gave some directions, which is to limit the menu editing on sub-sections only, I'll have a check at submenu reorder.

Hi everyone,

I found a "solution". Configure Workbench access and check "Limit available menu items based on Workbench Access.".

Then, add a module with 1 hook. It's a copy-paste from the menu module which add the menu tab in the node editing form with one change : the "access". I putted '#access' => user_access('access content'), but you can add a hook_permission and define your custom permission.

function yourmodule_form_node_form_alter(&$form, $form_state) {
  // Generate a list of possible parents (not including this link or descendants).
  // @todo This must be handled in a #process handler.
  $link = $form['#node']->menu;
  $type = $form['#node']->type;
  // menu_parent_options() is goofy and can actually handle either a menu link
  // or a node type both as second argument. Pick based on whether there is
  // a link already (menu_node_prepare() sets mlid default to 0).
  $options = menu_parent_options(menu_get_menus(), $link['mlid'] ? $link : $type, $type);
  // If no possible parent menu items were found, there is nothing to display.
  if (empty($options)) {
    return;
  }

  $form['menu'] = array(
    '#type' => 'fieldset',
    '#title' => t('Menu settings'),
    '#access' => user_access('access content'),
    '#collapsible' => TRUE,
    '#collapsed' => !$link['link_title'],
    '#group' => 'additional_settings',
    '#attached' => array(
      'js' => array(drupal_get_path('module', 'menu') . '/menu.js'),
    ),
    '#tree' => TRUE,
    '#weight' => -2,
    '#attributes' => array('class' => array('menu-link-form')),
  );
  $form['menu']['enabled'] = array(
    '#type' => 'checkbox',
    '#title' => t('Provide a menu link'),
    '#default_value' => (int) (bool) $link['mlid'],
  );
  $form['menu']['link'] = array(
    '#type' => 'container',
    '#parents' => array('menu'),
    '#states' => array(
      'invisible' => array(
        'input[name="menu[enabled]"]' => array('checked' => FALSE),
      ),
    ),
  );

  // Populate the element with the link data.
  foreach (array('mlid', 'module', 'hidden', 'has_children', 'customized', 'options', 'expanded', 'hidden', 'parent_depth_limit') as $key) {
    $form['menu']['link'][$key] = array('#type' => 'value', '#value' => $link[$key]);
  }

  $form['menu']['link']['link_title'] = array(
    '#type' => 'textfield',
    '#title' => t('Menu link title'),
    '#default_value' => $link['link_title'],
  );

  $form['menu']['link']['description'] = array(
    '#type' => 'textarea',
    '#title' => t('Description'),
    '#default_value' => isset($link['options']['attributes']['title']) ? $link['options']['attributes']['title'] : '',
    '#rows' => 1,
    '#description' => t('Shown when hovering over the menu link.'),
  );

  $default = ($link['mlid'] ? $link['menu_name'] . ':' . $link['plid'] : variable_get('menu_parent_' . $type, 'main-menu:0'));
  // If the current parent menu item is not present in options, use the first
  // available option as default value.
  // @todo User should not be allowed to access menu link settings in such a
  // case.
  if (!isset($options[$default])) {
    $array = array_keys($options);
    $default = reset($array);
  }
  $form['menu']['link']['parent'] = array(
    '#type' => 'select',
    '#title' => t('Parent item'),
    '#default_value' => $default,
    '#options' => $options,
    '#attributes' => array('class' => array('menu-parent-select')),
  );
  $form['menu']['link']['weight'] = array(
    '#type' => 'weight',
    '#title' => t('Weight'),
    '#delta' => 50,
    '#default_value' => $link['weight'],
    '#description' => t('Menu links with smaller weights are displayed before links with larger weights.'),
  );
}

Sorry for my English!

Thanks,

Anyone care to work this into a proper patch?

FYI, if your module weight is after workbench access then it won't filter the menu items and basically overwrite the work/filtering it did. I had to add

// Fix our menu items.
  menu_workbench_access_default_form_alter($form, $form_state, $options);

To the bottom of that code snippet above. Or you will need to adjust your weight in the database. I think the workbench_access module should add the above so it can be handled correctly and then it would only be processed once.

Scratch comment #7 and my last comment. All that is unnecessary.

In workbench_access.module line 1417 it checks for a custom form. I am assuming this is the Section required field a user must select to place their content into. Correct?

Then in the else, you have the workbench_access_default_form_element() function that actually adjusts the menu accordingly. Why is it setup this way?

I hacked around and did this to test:

  // Determine which form element to target.
  if (variable_get('workbench_access_custom_form', 1)) {
    // Provide a form element.
    workbench_access_node_form_element($form, $form_state);
    $options = workbench_access_active_options();
    // Call the function.
    $func = 'menu_workbench_access_default_form_alter';
    if (function_exists($func)) {
      $func($form, $form_state, $options);
    }
  }
  else {
    workbench_access_default_form_element($form, $form_state);
  }

Then in the file menu.workbench_access.inc is did this start of line 218

 // If no options, then no access.
  if (empty($options)) {
    $form['menu']['#access'] = FALSE;
    return;
  }
  else {
    //@todo set a variable to override menu access without having to rely on the global control.
    $form['menu']['#access'] = TRUE;
  }

By setting the menu access to TRUE, it will have the menu show up and be filtered accordingly. This also allows you to not give administer rights to the role for menus.

I'm still playing around with stuff so just want to put out what I have done so we can figure out why we can't include the required form element and still have the menu filtered and displayed.

Here is an initial patch to address this issue. I ran into a problem when you are using the required field form and the limit the menu setting and applied two fixes for that. Check it out and let me know if there is a better way to do it.

Hmm, how do I add patches now? Update the issue?

Patch added.

I can't comment on whether or not this is the "right" approach, but I did test and found this approach to work. That said, I think this should be a permission since it's an issue of granting access and you may want to have different access for different roles.

This patch makes the default variable consistent so there's not a false positive on install and fixes a typo in the setting description.

This patch breaks configuration detection for me when using the menu access scheme with "Require a workbench access form element" enabled; every node under workbench access' control displays a warning saying it is not configured due to workbench_access_default_form_element() being called all the time instead of only in the else clause.

FWIW this seems to be resolved by enabling Node menu permissions and assigning the following permissions.

• Create menu link in any menu for any content
• Edit menu link in any menu for any content
• Edit menu link attributes (title, description, etc) for any content
• Override menu link for any content

Workbench Access will still limit the available menu items to those the user can publish to. No need to enable "Administer menus and menu items"

It might still be preferable to get the patch committed instead.

Patches in #12 and #13, and a work around in #15, so setting to needs review.

Anyone still on this? Need this working for any meaningful access provisioning during page creation.

@ashleywilson I'm working on this today for a client. Hope to post a working patch shortly.

I actually got this working with some custom code using a menu reference field on the taxonomy terms. It was a lot easier than I thought.
Ideally it would be an option inside the workbench area but this works for my needs.

Basically using a form alter for the node edit form, I load up the taxonomy terms used for access control on that node and grab the menu reference value from the field on the taxonomy term.
I than loop through the menu options and disable the ones they do not have access to.

Drupal didn't have the ability to add disabled to the select dropdown options so I had to use a custom theme function. I also had to write some validation to make sure the editor couldn't re-enable the option through web inspector before saving the node.

When I have some time I can try to post an example.

This updated patch applies on 7.x-1.x-dev. Note for this to work correctly you'll need to uncheck "Require a Workbench Access form element". Ideally this could be fixed as the code noted below seems to be the culprit. Simply removing that code just breaks the ability to assign a section, although the menu filtering still works. Hopefully someone can offer a suggestion and we can roll another patch fixing it for good.

@@ -1598,6 +1603,9 @@ function workbench_access_default_form_element(&$form, &$form_state) {
  * @see workbench_access_get_assigned_fields()
  */
 function workbench_access_find_form_elements(&$form) {
+  if (variable_get('workbench_access_custom_form', 1)) {
+    return;
+  }

Test fails are coming from the addition from earlier patches. Going to work on this a bit more to see if that is really needed or should be handled in a different manner.

@@ -713,6 +713,11 @@ function workbench_access_node_presave($node) {
   if (isset($node->workbench_access) && is_array($node->workbench_access)) {
     $node->workbench_access = array_unique($node->workbench_access);
   }
+
+  // Make sure we have an array or our tokens will fail out.
+  if (!is_array($node->workbench_access)) {
+    $node->workbench_access = array($node->workbench_access);
+  }
 }

Anyone working on this. Same issue happens in my side..