Justin du Coeur (jducoeur) wrote in querki_project,
Justin du Coeur

Do these sound like the right "standard" roles?

On the to-do list in the not-too-distant future is a task that I think of as "Make Security Management Not Suck".

The thing is, Querki's security model is *very* powerful, and massively customizeable: I've been putting in place a lot of fairly fine-grained permissions, and the list is growing quickly. Each of those permissions can be applied at the Space, Model and Thing level. In the long run, if we go as far as I'd ideally like to (adding programmable permissions), we may wind up with the most powerful security model I've ever come across. For power users, it's pretty excellent.

But for everybody else, it's horrible.

I'm pretty sure that at *least* 99% of users are never going to care about all that flexibility, and that it will just annoy them. Indeed, even for power users -- heck, even for me -- I expect that they won't care about all that for most of their Spaces. What folks want is a *very* short list of sensible options to choose from.

So here's my first-draft guess of what the standard "roles" should be. These are basically the buckets that Members go into, and will be the "standard" way of thinking about security. You'll be able to tweak the definitions of these (and/or define your own Roles/Groups), but I'd like to have the defaults be correct enough that people usually don't need to.
  • Commentator: can read Things, leave Comments and give Ratings, Reviews and any other User Values that are defined for this Space.

  • Contributor: can do everything a Commentator can do, plus create and edit Instances. Can moderate contributions from Commentators and the Public, if those are allowed in this Space. (Moderation should be opt-in, but Contributors are offered the opportunity to do so.)

  • Manager: can do everything a Contributor can do, plus design Models, manage most Permissions, edit the Space itself, issue invitations and accept join requests. Managers are essentially Admins, and can take *most* actions.

  • Owner: can do absolutely everything. There is exactly one Owner at any given time, and it is defined as the entity paying the bills. Only the Owner can assign people as Managers, delete or give the Space to someone else.
I'm deliberately avoiding the Google Docs concept of "co-Owners", to avoid ambiguity: in the final analysis, *somebody* has the ultimate say, and that should be whoever is ultimately responsible for this Space. But the intent is that Managers are *almost* Owner-level, with a very high level of trust.

The feature I am most on the fence about is Model design: I'm honestly uncertain whether it belongs in Manager or Contributor. I'm also on the fence about whether Moderation belongs in Manager or Contributor. I've considered adding a middle "Editor" layer to reflect that, but I'd prefer to keep this list as short as possible, so I'm seeing whether it works without that.

Opinions? Does this seem like the right list? Am I off-base in where I'm assigning features? Would it make more sense with an "Editor" level between Contributor and Manager, with Moderation and Model Editing rights? Do the names make sense? Changing these roles once they are in the wild is going to be dangerous, so I'd like to get it more or less correct out of the gate...
Tags: security, usability

  • Turning off China for the moment

    [Mostly an FYI, on the off-chance anyone cares.] It's a sad statement about the state of the Net, but we've decided, for at least the short term, to…

  • Coarse-grained security (seeking opinions)

    [Thinking out loud here -- comments highly encouraged.] Setting aside the question of "user levels" that we discussed last week (I'm going to put…

  • How best to display a "choice"?

    So one of the more-common requirements for Querki Spaces is a field that is essentially a "choice". (h/t to tpau for suggesting the…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded