This module looks great - one bugbear that I have tho, is that despite its ease of use, I really think that overriding menus for uid 1 is a bad way to go.

By default, all modules will basically ignore the admin user in their functionality, and let them do whatever they want. As such, I feel this module should add a check for uid 1 and provide all menu api functionality as normal for that user.

It is a simple change. The main reason for this is that it is perfectly valid to have menu items for nodes that may not normally be assigned to menus, but that the admin user may wish to assign there themself.

Ways around that would be:

1) check for uid 1 and leave it alone, rendering the menu as normal on all node add forms
2) add a setting in a config screen to allow bypassing of the admin user (ie "I definitely never want to add nodes to a menu outside of what CTM offers me")
3) Add a permission that basically achieves rendering of menu api items per role

CommentFileSizeAuthor
#6 ctm.module.patch687 bytesKoCo

Comments

niklp’s picture

niklp commented

A quick look at the code required to achieve 1) above seems to lead me to thinking that simple wrapping the contents of the _menu_alter function will be enough...? I could be wrong - it has been known.

function ctm_form_alter(&$form, $form_state, $form_id) {
  global $user;
  if ($user->uid != 1) {

    // Menu Setting for content types - Content Type Form
    if ($form_id == 'node_type_form') {
      // etc
    }

  }  
}
rickvug’s picture

rickvug commented

I've marked #343369: Administrator full access to menus? as a duplicate of this issue. In that issue, vasike (the maintainer) stated the following:

The administrator is the one who set the menu settings for content type, so i don't see why should still have all the menus in the menu settings for content editing?
the purpose of this module is simplify the menu settings for content editing for all users.

While I believe this to be true in most cases, normally user 1 is the "super user" and has full access to everything, all of the time. There is a president for user 1's settings remaining unchanged. That said, I think option #2 above would be best. The only downside in my mind is the potential of creating an administration screen for just this one global option. Can you think of a good pre-existing place to put this option? Is that even a good idea, considering that the addition wouldn't be obvious to most users?

niklp’s picture

niklp commented

There is no need to make this an option - it's an unwritten rule that all functionality should be available to uid 1, so just "make it so". Doing anything else is just confusing, as it bucks the trend. If you ask around, I'm positive you'll receive confirmation for this from all sides. Ask in IRC maybe.

tomws’s picture

tomws commented

+1

I would also expect ID1 to have full menu available. Since it's just a small code change, it would be good to have it implemented in the module rather than requiring a manual patch.

Great module. Just what I needed.

bartezz’s picture

bartezz commented

+1

Good module but indeed uid 1 is a superuser and should be able to access everything within the Drupal setup.

KoCo’s picture

KoCo commented
StatusFileSize
new ctm.module.patch687 bytes

I agree, a superuser has to remain a superuser.
But enforcing to set the menus per node type is usefull. I you don't want any menu's, then don't set them so even the superuser isn't bothered with a too large of add/edit form.

bartezz’s picture

bartezz commented

I'm not understanding your post I think, are you still trying to set certain permissions for uid 1???

UID 1 is meant for configuration only! Not to maintain a website in any way!!
Create a webmaster role for a semi-superuser, let this guy not be bothered with a too large of add/edit form
Create a moderator role for a content moderator, let this guy not be bothered with a too large of add/edit form

Do whatever you want but never make it so that settings, menus or content are hidden for UID 1!!!!

One of the main reasons is debugging, if even the superuser can't bypass permissions then how can one debug???

Cheers

KoCo’s picture

KoCo commented

I do agree, however for debugging purposes I believe some (just a very little) should be done to let the superuser search and debug more easily. Too much of add/edit items could actually hinder the debugging process. Although, there are modules out there to help with debugging.
Nevertheless, it has been agreed that the superuser should have all access. Not only to allow debugging in a totally free environment, but also because we cannot predict which fields/modules would require debugging. I tend to follow this reasoning in the vast majority of cases.

However, having reviewed and tested the first patch, I found the middle way acceptable in this case. Thus releasing a patch for those who also think the menu-field can be disregarded entirely in certain cases. My patch was never intended to be committed. If one ought to be committed, it's the one giving the superuser access to all menus.

Cheers

bartezz’s picture

bartezz commented

Agreed! :)

Cheers

rootwork’s picture

rootwork
he/him
Primary language English
Location 🇺🇸 US-Pacific 🌎 Chinook (Multnomah, Clackamas) & Cowlitz lands 🌹 Portland, OR
commented
Category: task » feature

This is a great module, and I agree with this thread that uid1 should have full menu access control. It also strikes me that there could be other roles ("site editor," say) that you'd want to give this ability to. As I see it there are two ways you could do this:

1. Tie it in to the existing "administer menus" permission. If a user is a member of a role that has this permission, they always have the ability to put a node in a menu (and any menu) regardless of what the ctm settings on that content type are.
2. Create a new permission specific to this module called something like "post content to any menu" that does the same thing. And by default this should be set for uid1.

At a minimum, though, I agree that uid1 shouldn't be constrained by ctm settings.

mattiasj’s picture

mattiasj commented

This is indeed a very great module but I agree that uid1 never should be limited. For example we want to use this module for our clients to make a nicer experience but for ourselves we need access to all menus.

finex’s picture

finex commented

I agree that uid=1 should never be limited.

bartezz’s picture

bartezz commented

Vasike, this thread is over a year old, do you care to respond?

Cheers,
Bartezz

rootwork’s picture

rootwork
he/him
Primary language English
Location 🇺🇸 US-Pacific 🌎 Chinook (Multnomah, Clackamas) & Cowlitz lands 🌹 Portland, OR
commented
Priority: Normal » Critical

I'm moving this to critical. This continues to create problems for my site administrators, and goes against the principles of Drupal (allowing uid=1 to have all permissions). The thread is in general agreement, a patch has been offered, and this issue needs to be resolved.

I'm happy to help test or even code to move this forward. However, I notice there has been just one full release of this (in D6) and it was in 2008. It does seem like dev has been worked on, though, so at the very least it would be nice to move this into dev.

vasike’s picture

vasike
Location Ramnicu Valcea
commented
Status: Active » Closed (fixed)
rootwork’s picture

rootwork
he/him
Primary language English
Location 🇺🇸 US-Pacific 🌎 Chinook (Multnomah, Clackamas) & Cowlitz lands 🌹 Portland, OR
commented
Version: 6.x-1.0 » 6.x-1.1

Why was this ever closed? This was not fixed. Has there been progress on fixing it? (Perhaps it's in the dev version?)

rootwork’s picture

rootwork
he/him
Primary language English
Location 🇺🇸 US-Pacific 🌎 Chinook (Multnomah, Clackamas) & Cowlitz lands 🌹 Portland, OR
commented
Category: feature » bug
Status: Closed (fixed) » Active

Also, overriding uid1 permissions is a bug. A bug that it would be great to get fixed.

I'd be happy to help test patches, but as far as I can tell this bug is still present.

vasike’s picture

vasike
Location Ramnicu Valcea
commented
Status: Active » Fixed

i don't know what happen. anyway now it has to fixed in the dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.