On 04/04/2012 01:31 PM, Jason Guiditta wrote:
On 30/03/12 09:37 -0400, Scott Seago wrote:
> Rather than paste in the entire text, I'm just linking to the wiki
> writeup. Please read the whole thing first and if you want to comment
> on anything specific, quote it and comment on this thread.
you say in that page:
'As for UI, we won't need any get/set UI, although it might be useful
to make the permissions UI "swappable" -- i.e. a toggle to switch
between direct grants (that you can add/remove) and derived grants (so
you can see in one place everyone that has access to the resource).'
What about api? Is there any expectation of needing to allow a user
to manipulate any of this, or would it all be exposed in some other
way? I suspect no, as this looks to be all done behind the scenes,
API a separate question entirely. The whole point of the permissions
denormalization is that it does _not_ affect the get/set API -- the
records that are manipulated by the UI are unchanged by denormalization
-- the new objects are maintained via hooks.
Now if you ask "what about a permissions get/set API?" -- why, yes, we
need that -- whether or not we denormalize the permissions, so I'd
consider that out of scope for the 'denormalizaiton' effort but it
should definitely be included among the "build out API for $foo" tasks
(along with launching instances, creating providers, etc.)
I don't see mention of any of the *_image family of objects, but
would be included in this, as they will reside in conductor db now,
Sure, but that's not part of this work. This task is to take the current
models that are permissioned and denormalize them. Part of the "pull
images into Conductor" work will include making sure the new Image model
includes PermissionedObject, works with list_for_user, etc.
If the new image work is done _after_ denormalization impl, then the new
image models will simply implement permissions using the new model from
Aside from those minor clarification points, this looks like a good
improvement to the perms structure.