Just to throw a wrench into things, is it possible to POST /users and
in the JSON, define the owners to associate with? (similar to how we
were talking about setting the owner on a consumer, only with multiple
instead of just one in this case)
On Mon, May 16, 2011 at 4:03 PM, Bryan Kearney <bkearney(a)redhat.com> wrote:
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
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin