On 05/16/2011 02:15 PM, Justin Harris wrote:
----- Original Message -----
> On 05/16/2011 02:08 PM, Justin Harris wrote:
>>
>>
>> ----- 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
>>
> so.. to be clear...
>
> 1. you would remove the owner attribute on the user, but keep the
> super
> user one.
> 1. you would create an instance of membership which joins owner and
> user. And the assumption is that the users is a super-admin.
>
> Is that correct? It would not surprise me if we would need a "Normal"
> user or read only. Which is why I like the Role model... but as you
> said.. it is a step in the right direction.
>
> -- bk
Yes, I think that is the general idea - we can then add roles to the membership as a
later story
if we want to go in that direction. This way a user can be e.g. and admin for one owner
and a
basic user for another owner.
hmm.. membership sounds soooo much like a role :)
-- bk