----- Original Message -----
On 05/16/2011 01:57 PM, Justin Harris wrote:
> Hey gang,
> So for this multi-owner stuff, we probably need to change how
> users are created, then associated with an owner. Currently, the
> client will POST to /owners/<id>/users to create a new user under
> that owner. We could keep this the same, but that will likely
> involve a lot of semi-magic logic where we check if that user is
> already in the database and either update or create them.
> Alternatively, we could move the user creation to POST /users and
> then require a second call to associate a user with an owner (and
> subsequent calls when adding more than one owner). The super
> RESTy approach would be to create a /membership resource to
> manage this, which would be fine to implement. All this does mean
> that we break the api for user creation, though I'm not sure how
> heavily we are using this outside of our functional tests. Does
> anyone have an opinion on this either way?
So.. not to throw scope creep into this (But I will) :)
Do we want a simple RBAC for hosted? So.. a user could have a role in
an
org? That is basically your membership concept, but with some enhance
functionality around it. We could go whole hog on RBAC.. but since it
is
a free product..we may not want to.
SUPER_ADMIN would be a bit different.. since it would have no target
owner. But you get the idea.
-- bk
Well, to push back on your scope creep somewhat, we could leave all that out but
still introduce the membership model (basically as a join between owner and user)
which sets us up to go in that direction in the future?
- Justin