Duplicated get_policy_target() method across code

Bug #1317238 reported by Lin Hua Cheng
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Fix Released
Wishlist
Sam Betts

Bug Description

This chunk of code is copied all over the place:

def get_policy_target(self, request, datum=None):
    project_id = None
    if datum:
        project_id = getattr(datum, 'tenant_id', None)
    return {"project_id": project_id}

(Though sometimes with a different key in the return dict.)
Would it make more sense to create a mixin or update a super-class somewhere?

Revision history for this message
Kieran Spear (kspear) wrote :

+1. Sounds like a good idea to me.

Changed in horizon:
status: New → Triaged
importance: Undecided → Wishlist
Sam Betts (sambetts)
Changed in horizon:
assignee: nobody → Sam Betts (sambetts)
Changed in horizon:
status: Triaged → In Progress
Revision history for this message
Sam Betts (sambetts) wrote :

Fix proposed to branch: master
Review: https://review.openstack.org/115251

Revision history for this message
Julie Pichon (jpichon) wrote :

I like the direction of the patch, this is definitely an improvement.

Could we consider improving things further by having instead one mixin (or superclass update) that sets most expected keys (e.g. user, project, domain ids) rather than just the one id that happens to exist in the default policy?

It seems to me we're currently blocking deployers from flexibly adapting policies. Because we expect a specific action to require a project_id, if a deployer want to change that so that for example only the owner can perform an action (e.g. allow a user to delete only an instance if they created it themselves) deployers are stuck, because we wrote a rule that only expects a project_id for this and doesn't know the user_id.

Then perhaps additional mixins for components that have additional keys, like neutron with network:tenant_id, etc, though to be honest I wouldn't particularly mind having them set generally and set to None when unneeded, there doesn't seem to be that many.

Revision history for this message
Sam Betts (sambetts) wrote :

I have pushed a new patch set, that hopefully addresses some of the issues that you brought up here.

Changed in horizon:
assignee: Sam Betts (sambetts) → Akihiro Motoki (amotoki)
Akihiro Motoki (amotoki)
Changed in horizon:
assignee: Akihiro Motoki (amotoki) → Sam Betts (sambetts)
Changed in horizon:
assignee: Sam Betts (sambetts) → Akihiro Motoki (amotoki)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (master)

Reviewed: https://review.openstack.org/115251
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=107cf8b328f7cf1b7418fdbbad60c490ee1b1038
Submitter: Jenkins
Branch: master

commit 107cf8b328f7cf1b7418fdbbad60c490ee1b1038
Author: Sam Betts <email address hidden>
Date: Tue Aug 19 10:27:47 2014 +0100

    Add mixin to replace replicated get_policy_target

    Fix adds a mixin to replace the replicated get_policy_target
    function. Duplicated code is removed from many classes and mixin is
    inherited.

    project_id, user_id and domain_id are now default in the generated
    policy_target dict but are set to None if the data doesn't support it,
    this is to provide the most flexibility for operators writing policy.json
    as discussed in the bug report.

    policy_target_attrs attribute added by the mixin is overwrittable by
    sub-classes of the mixin to override the defaults for custom policy_target
    information.

    Change-Id: I26759f145b8756bd1eef585c8107160277061523
    Closes-Bug: 1317238

Changed in horizon:
status: In Progress → Fix Committed
Akihiro Motoki (amotoki)
Changed in horizon:
assignee: Akihiro Motoki (amotoki) → Sam Betts (sambetts)
milestone: none → juno-rc1
Thierry Carrez (ttx)
Changed in horizon:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in horizon:
milestone: juno-rc1 → 2014.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.