[development] Remove top-level admin menu items

[Walt Daniels]

+100 on these comments

There are many other modules that are badly classified making them hard to
find. Every maintainer should take a quick look at where their modules wind
up and fix them. After all it is in your best interest. If they can't be
found they won't be used.

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of Daniel F. Kudwien
Sent: Sunday, February 01, 2009 12:17 PM
To: development at drupal.org
Subject: [development] Remove top-level admin menu items

This goes out to some maintainers, specifically related to

- Notifications / Messaging
- Organic Groups
- Panels

Those and related/dependent modules are implementing top-level menu items,
e.g.

- admin/messaging
- admin/og
- admin/panels

in the style of Drupal 4.7, instead of using the new administrative
categories and structure we have since Drupal 5.x.  This is not only
confusing, but also clutters the administrative interface - especially, if
Administration menu module is installed.

I see no reason why it needs to be this way.  Clearly, for example, Organic
Groups and Panels are both tools to build a Drupal site -- the proper
location would thus be below "Site building".

In the special case of Notifications/Messaging, the situation gets even
worse: It mixes administrative items for different purposes into one
top-level item, meaning that permanent site configuration settings and
continuously required administrative functions are located in one, bloated
container with no clear distinction.  Furthermore, granting administrative
users the permission to administer user subscriptions will expose a new
top-level menu item "Notifications & Messaging" to them -- the proper
location for managing user subscriptions would be below "User management".

Unfortunately, my request for changing this in Notifications was immediately
won't fixed [1], which is why I see the need for a broader community
consensus.  I know that a change like this could probably only done in
upcoming major versions of all affected modules.

If the only thing that prevents this from changing are patches, then I'll
happily submit some.


Thanks,
Daniel

[1] http://drupal.org/node/366489