Don't override uid 1 menu settings!
| Project: | Menu Settings per Content Type |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
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
#1
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
}
}
}
#2
I've marked #343369: Administrator full access to menus? as a duplicate of this issue. In that issue, vasike (the maintainer) stated the following:
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?
#3
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.
#4
+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.
#5
+1
Good module but indeed uid 1 is a superuser and should be able to access everything within the Drupal setup.
#6
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.
#7
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
#8
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
#9
Agreed! :)
Cheers