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?
- 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.
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