On Jun 22, 2011, at 2:51 PM, Seth Graham wrote: > > On Jun 9, 2011, at 12:10 PM, Alex Dean wrote: >> I started off intending to allow per-view edit access, just like we allow >> per-cluster edit access for optional graphs. The complication is that each >> resource (a view or a cluster) in the ACL is only identified by a simple >> string. Thus you can't have a cluster and a view which share the same name >> - or, if you did you'd probably unwittingly be granting permissions you >> didn't mean to. I thought about introducing some kind of namespacing, and >> then just decided to punt until it was actually needed. >> >> So... maybe that time is now? :) >> >> Something like this wouldn't be too hard to implement: >> $acl->allowView( 'username', 'view-name', GangliaAcl::EDIT ); >> $acl->allowCluster( 'username', 'cluster-name', GangliaAcl::EDIT ); >> >> Please suggest alternate APIs here. That's just my initial brainstorm. > > I finally got a chance to sit down and poke at this. > > The good news is it's easy to implement a permissions system for adding > graphs to an existing view. My method was to edit GangliaAcl.php to add an > 'EDIT_VIEW' resource, and use the add() function along with a clustername to > give a user view editing privileges. After updating the checkAccess() calls > where appropriate in host_view.php and views.php, a user can add graphs to > their view.
That requires that the view name match the cluster name, right? Could you post your changes somewhere so we could see what you did? > > More complicated is the creation of the views themselves. Because views can > have names without any relation to ganglia clusters, the ACL system won't > work. I guess one could put in a restriction that a user can only create > views with the same name of clusters they have edit permissions for, but that > would limit them to owning a single view per cluster. > > (as an aside, is it intended that once a view is created, it cannot be > removed via the web interface?) Probably more of an oversight. Patches welcome! :) > > The more I look at it, the more inclined I am to leave the configuration as > it is. Every idea I come up with limits the flexibility of the Views or > requires more acl maintenance in conf.php. I still want to take a stab at this, I just haven't had the time. Help me understand your use case better. You want to allow some non-admin users to edit a single view, right? Is there a case for limiting the visibility of a view, or are we only concerned with who can change a view? More generally, what permissions do we need? - view a view - create a view - edit a view - delete a view I'd say sensible defaulte are that admins can do all of these things for all views, and anonymous users can view all views which haven't been specifically hidden. alex ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
