Merge lp:~jtv/launchpad/bug-662552-view-permissions into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | 11818 |
Proposed branch: | lp:~jtv/launchpad/bug-662552-view-permissions |
Merge into: | lp:launchpad |
Diff against target: |
112 lines (+19/-19) 3 files modified
lib/lp/translations/browser/pofile.py (+4/-9) lib/lp/translations/browser/tests/test_translationmessage_view.py (+1/-2) lib/lp/translations/browser/translationmessage.py (+14/-8) |
To merge this branch: | bzr merge lp:~jtv/launchpad/bug-662552-view-permissions |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Tim Penhey (community) | code | Approve | |
Launchpad code reviewers | code | Pending | |
Review via email: mp+39481@code.launchpad.net |
Commit message
Re-use POFile edit permission info across message sub-views.
Description of the change
= Bug 662552: View and Permissions =
I'm cutting some dead wood out of the POFile:+translate page, which has been timing out.
One thing that can get a bit costly (especially in terms of the number of database queries issued) is checking whether the user has permission to edit the translation that's being browsed. That check is done for each of the messages displayed, normally 10 but up to 50 per page.
This branch hoists the check out of the view constructors (the batched on for the POFile as well as the single-message view) and passes the result in as an argument. That way, the POFile view can do the check once and re-use the outcome for each of the message views it creates. The code for the check is quite complicated and can involve many queries, depending on the user.
While I was at it, I also passed the POFile itself as an argument. A current problem is that TranslationMessage officially doesn't have a reference to a POFile any more, but the view code does still need that reference. We work around that in a few places with a memory-only attribute called browser_pofile. By passing the POFile as an argument, I get to eliminate one use of that malodorous attribute.
There's some legacy lint, most of which I left untouched because we're cleaning it up in other branches. None that I introduced though.
Jeroen
I don't see anything wrong with this, but I'll have to take your word that it does what it says it does.