A “member” on most of the sites I go to is someone who can post comments or suggest stories. It’s not someone who can actually edit stories or maintain content in any meaningful way. It’s not a very powerful role at all.

What I hear you describing is what I’ve termed a “Site Editor” or “Site Maintainer”: Someone who can publish new pages, add to the navigation, read webform submissions, add and adjust blocks, and do a few other important things. This is, for me, the most important role to be able to create, and right now, it’s a damned hard role to create — and not for any terminological reason, but because there are a lot of things that aren’t controllable at a fine-grained enough level to strike the balance between power and safety that is really needed for such a role.

I really do think that additional roles beyond anon and auth user are best left to installation profiles, and not added to core.

vote +1

As Mark and Jen and others have noted above, this is all about trying to take the decision-making out of creating roles for people who are newer to Drupal and who don’t understand the intricacies of how this all works (and it is pretty confusing, you have to concede).

So, I’m agreeing with Catch that the ‘member’ role I was proposing actually already exists, it’s the ‘Omnipotent God Of This Website’ Admin role that doesn’t exist (as a role you can share with others at any rate) and which needs to be created.

In terms of implementation this looks like adding an admin role to core, and that role having the ‘use admin header’ permission out of the box. I’d completely support a change like that.

Please ignore the meta-role discussion, that’s not on the table.

http://www.smashingmagazine.com/2009/05/27/modal-windows-in-modern-web-design/

which discusses appropriate uses and good techniques for modal windows…

So for someone in my context, I’d vote for a third default role of an admin. I don’t have any brainstorms for better terminology, but guest, registered, admin are the 3 roles I’d like to see as default. Every site I build I create this as one of the first steps, since I’ll be a full admin and need a separate role for registered users.

(As an aside, on catch’s comment: “(it’s very possible to have permissions in Drupal to enable a module, but then not to configure it, unless you go and give yourself the permission”…yes and yes! This annoys me to no end when installing and configuring modules. If I have permission to install, I should have permission to immediately configure. This is especially true when field-level permissions are enabled – having to go give myself permission to access every field I just created is tedious at best.

Now, I must confess I’m not sure of an elegant solution at this point – the Admin Role module helps, as does just having my account be user-1 (bad Michael, I know! But it speeds up the admin workflow so much).

Oh, and the same is true of running updates…if I’m a full admin, but not user-1, I can enable and configure a module, but then I need to switch to user-1 to run update.php when I update modules. Why is that? Could access to update.php also be a permission that user-1 can set?

Sorry, that got off-topic…it’s all related to admin vs. member roles though…kinda… )

+1 vote for default guest, member, and admin roles…

Either the new (overlay) interface is a usability improvement for both beginners and experienced content creators, and then we want it for all users.

Or: It’s a usability improvement only for experienced content creators. But then it should be a separate permission, not coupled to the admin role/permission. (You might have authors who create a lot of content but don’t have any admin powers, and admins who spend most of the time administering the site, and very seldom create content.)