On 11/22/2012 02:22 AM, Martin Povolny wrote:
Hi.
I wonder if when assigning costs to hardware profiles and hardware profile
properties, I should use the same privilege as would be used when
editing the hardware profile.
That is:
require_privilege(Privilege::MODIFY, @hardware_profile)
My thinking goes:
I don't want a separate path in the UI for assigning costs, as it would
be even more confusing then now. So in the place where you can find the
UI to edit frontend hardware profile I put the cost assignment for
backend profile.
Given it's in almost the same place and from user's point of view it
deals with the hardware profile, then it would be logical to use the
same privilege.
Thoughts?
Hmm -- so you're editing provider HWPs here not conductor/front-end ones
right? If we're associating with front-end profiles, the above sounds
exactly right to me -- if you can edit the HWP, you can edit its cost.
However, my understanding of this whole model is we're associating costs
with the provider-end HWPs. Provider HWPs aren't editable at all right
now -- we pull them from deltacloud and don't change them. As such, I
think you would instead want to check permissions on the provider. i.e.
if you can edit the provider, you can edit the HWP privileges:
require_privilege(Privilege::MODIFY, @hardware_profile.provider)
As a variation on this, if we have reason to separate users here -- and
have one user that can edit costs but not basic provider stats, we can
handle that too. In that case we want to check for "modify Hardware
Profile" privileges, but on the provider (since, again we don't track
this at the provider HWP level but on the HWP itself.
i.e. you'd want this:
require_privilege(Privilege::MODIFY, HardwareProfile,
@hardware_profile.provider)
(I think I have the syntax correct above)
Then to support the use case for allowing only people that have provider
edit privileges edit these costs, we'd add the (Privilege::MODIFY,
HardwareProfile) privilege to the same roles that currently allow
provider modification.
There's one other complication here -- prior discussions with athomas
were suggesting that we actually drop HWP-oriented permissions entirely
(since we're not really using them now - -but the system is enforcing
them), so I'm not sure how this subject affects that idea.
Scott