If you've been following my blogs about the various administrative interfaces we've been playing with, you'll know that I've proposed the idea of building a system through which these sorts of administrations could be deployed by site administrators without the need to understand what it would take in terms of module development to do so for themselves. Since I started playing with this stuff ctools has really become very common place, and it's page_manager module is perfect for doing this sort of work. With that in mind we're announcing Contextual Administration module.
Contextual Administration is a ctools dependent module designed to deploy single page interfaces that would be impractical to deploy in a panels type interface. It comes with a number of built in plugins for things like node creation, user creation, and taxonomy administration. Creating your own plugins is easy (though I'm still working on the documentation for that particular feature).
Why not just use panels?
This is a completely legitimate and understandable question because well... panels is awesome. The reason our plugins don't just interface with panels is because while having node_creation forms as plugins to panels would be cool, it gets impractical pretty quickly if people start trying to utilize multiple forms together. For the sake of simplicity (and sanity) we chose to just provide our own interface to page_manager. The upside to this is that we get the ability to mix our variants with panels variants so we still get the best of both worlds and it's simple enough that anyone can deploy a context_admin page without needing to understand everything that panels can do.
What features come with it out of the box?
Our main focus in developing context_admin was to provide a menu based administration system that could be deployed anywhere at any time. Personally I use this to deploy new administrations through "tabs", or MENU_LOCAL_TASKs for the more technically inclined.
Since we've interfaced with page manager, these page definitions can already be exported, and will bundle into features module with no additional work. You can bundle them just like you would a panel.
Out of the box we currently (beta4) provide plugins to allow for:
- node creation of node type X
- node creation of node type X as a menu child of the parent node (requires a node/%node/* path currently)
- node creation of node type X with an automatic node reference (requires a node/%node/* path currently)
- taxonomy term edit
- taxonomy vocabulary edit
- taxonomy vocabulary term list
- taxonomy vocabulary term add
- taxonomy term add as sub term (requires taxonomy/term/%term/* path currently)
- user creation (with tons of configuration here, you can auto-assign roles, status, and more)
- Node administration of node type X via a views_bulk_operations style view (requires views_bulk_operations module)
- Administration Sections (these can only be used in conjuncture with a /admin/something path. You simply add one of these, and then add links to that through the typical menu system, and it will build up your own administration section just like "site building" or "site configuration")
We intend on doing a user administration via VBO as well but it's not in the current beta release just yet. We may also provide our own actions that don't require various user perms to make the VBO based administration a bit more usable without having to hand out administrative privs to users.
WHOA?! Isn't that a security issue?
Uh... "YES", yes it is a "security issue". With that said, let's cover that topic for just a moment. Any time we're allowing for nodes to be created w/o the user having the perm to do so, that's a "security issue" as well. What is worth pointing out here, however, is that there's still security here, it's just up to the site administrator instead of being hardcoded by drupal core. Drupal 7 has already been altered to work this way in a number of places, not the least of which is node creation and user creation. It's frankly sad that VBO was forced to alter its existing functionality to cripple this power to begin with.
What that really means is this: Drupal 6 utilizes a number of additional checks over those already provided by the menu system to determine if user X should have access to perform task Y. Now the menu system actually did this check already (for example, "create page nodes"). The menu system is already running a user_access() check against that perm, and if it's NOT it's because some other module has altered the menu to do something else. The node_add() function does an additional check against this same set of parameters before it will allow a user to actually even visit the node creation form for pages. If the menu is altered, then this blows up spectacularly (which is why context_admin is actually providing its own version of node_add()). This same is largely true for user creation, except it's a lot messier there. Both of these functions have gotten some love in drupal 7 so that the menu system is the one in control, and thankfully this means that as developers we got a LOT more flexibility out of drupal core. It also represents a bit of a shift from a security perspective in that we're recognizing that the menu system really should be in charge of these things. Thus I would say the logic goes for VBO (and context_admin) in the same way. The site administrator is in charge of preventing users from visiting these administration pages, and if he doesn't it's not actually a security issue for the module.
Why are you bringing this up?
It's sort of odd to be pointing out issues in a module I just released, but I'm afraid I need to make my argument FOR my approach before I start getting security issues filed against me. I feel VBO was unfairly picked out in this regard as well, as views provides a perfectly good solution for access control to a view. The point is, drupal 7 has already embraced this logic in many places, and we get a LOT more development power out of it.
Quick aside, I've been using this in production for a while and am quite happy with it.
Kris "EclipseGc" Vanderwater
