On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:33 AM, James Bowes
<jbowes(a)redhat.com> wrote:
> On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
>> Here is my current plan for refactoring and modelling the role to user
>> and role to permission relationships as resources themselves.
>>
>> - Create a role with POST /roles (json blob containing not much more
>> than a name) Calls UserServiceAdapter.createRole which returns a role
>> with a unique ID.
>>
>> - Add a user to a role: POST /memberships with JSON containing just a
>> username and a role ID. Calls UserServiceAdapter.createMembership()
>> and returns a membership with a unique ID.
>>
>> - Delete a user from a role: DEL /memberships/membershipid. Calls
>> UserServiceAdapter.deleteMembership().
>
> Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual
resource with it's own distinct ID. Up until yesterday it was just a
straight Role-User relationship and created/updated by posting JSON
blobs with the users in it. As Justin pointed out this implies the
caller has to know the full set of users before it can change
anything, and introduces problems with race conditions. We can go back
to straight Role-User and perhaps do something like POST
/roles/id/users/username or DEL /roles/id/username to update the set.
However current path was to treat the relationship like an actual
resource. Should we revert to direct ManyToMany from Role to User?
If there's a reasoning behind it, then that's cool. Perhaps for next rev
of the API we can update the other resources to match.
>
>>
>> - Add a permission to a role: POST /permissions with JSON containing
>> role ID, owner key, and access type. Calls
>> UserServiceAdapter.createPermission().
>>
>> - Delete a permission from a role: DEL /permissions/permissionId.
>> Calls UserServiceAdapter.deletePermission().
>>
>
> The above two points mean that a permission cannot exist on its own,
> right? it has to belong to exactly 1 role at all times. I like this.
Correct. Right now Permissions can exist on their own and are re-used
across Roles, this will change such that it belongs to a specific
Role.
>
>> All three objects, Roles, Permissions, and Memberships, fall into the
>> category of objects we already have which should never be directly
>> queried from a curator in our code base, but rather obtained through
>> the UserServiceAdatper.
>>
>> Seem ok? I can elaborate on alternative approaches but at this point
>> in time it seems like clarity and decisiveness is probably best. :)
>
> Seems ok (except for memberships, maybe).
>
>>
>> Cheers,
>>
>> Devan
>> _______________________________________________
>> candlepin mailing list
>> candlepin(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/candlepin
>
> -James
>
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/candlepin
>
>
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
-James