----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Einav Cohen" <eco...@redhat.com> > Cc: "Andrew Cathrow" <acath...@redhat.com>, "Eldan Hildesheim" > <i...@eldanet.com>, engine-devel@ovirt.org, "Simon > Grinberg" <sgrin...@redhat.com>, "Eldan Hildesheim" <ehild...@redhat.com> > Sent: Friday, May 18, 2012 1:50:17 AM > Subject: Re: [Engine-devel] custom properties sheet feature page > > On 05/17/2012 04:08 PM, Einav Cohen wrote: > ... > >>> Hi, > >>> > >>> Please review/comment on the Custom Properties Sheet feature > >>> page: > >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > >>> > >> > >> It looks great. > >> Are all the keys going to be exposed in the dropdown, or will we > >> have > >> private keys that the user has to know about? > > > > All keys will be exposed; not sure what you mean by "private", but > > all keys are treated the same today. > > If we want some kind of differentiation between the keys, it is a > > another feature... > > [I could, of course, be missing something, please clarify if I did] > > > > in the future, we may want to give permissions to which users are > allowed to use which custom properties. > not relevant for now.
Is this cool looking design be also available from the user portal? If so how do you prevent any user that just have permission to Edit VMs to do damage? With custom property you can do almost anything. Consider the case where there is a hook that allows to directly attach a LUN/Add Tap/more destructive options. It is intended for use of the sys admins but any user can use. You would say correctly that this was always the case. But with the old textbox interface the user would need to know that the option exists. Now we actually tell him what he can use. Cool for the webadmin / kind'a dangerous from the user portal until you get permissions per users feature for it. The minimum that is needed is an option to disable this properties tab in the user portal. Better have MLA for using properties at all if per property can't be accommodated. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
