On 05/16/2011 02:28 PM, Justin Harris wrote:
----- 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?
well.. today we have a role of SUPER_ADMIN which is really a
collection
of permissions on the assume parent owner.
If we move the word "SUPER_ADMIN" to the membership.. then that
membership becomes really a set of permissions.
-- bk