----- Original Message -----
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
Maybe this is just a difference in semantics, then. I was thinking a role is, for
example, admin. A membership
would be a combination of a user, role, and owner. Maybe my working definition of a role
is really a role type?