Merge lp:~jtv/launchpad/bug-590688 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Jeroen T. Vermeulen on 2010-06-07 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 10957 |
| Proposed branch: | lp:~jtv/launchpad/bug-590688 |
| Merge into: | lp:launchpad |
| Diff against target: |
249 lines (+60/-28) 4 files modified
database/schema/security.cfg (+1/-0) lib/lp/testing/__init__.py (+12/-0) lib/lp/translations/scripts/tests/test_translations_to_branch.py (+28/-1) lib/lp/translations/tests/test_autoapproval.py (+19/-27) |
| To merge this branch: | bzr merge lp:~jtv/launchpad/bug-590688 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Henning Eggers (community) | code | 2010-06-07 | Approve on 2010-06-07 |
|
Review via email:
|
|||
Commit Message
Missing database privilege for translations-
Description of the Change
= Bug 590688 =
The fix for bug 409686 involves sending an email notification to the owners of any branches that are set up to have translations exported to them, but have never been created in codehosting. (This happens when a user goes through the "register a branch" process in the UI but fails to push a branch to the newly reserved location). For various reasons we have discussed elsewhere, just creating an empty branch is not the right thing to do.
In composing the notification email, the fix for bug 409686 accessed a Branch property that triggers a SELECT on the SeriesSourcePac
I'm also adding a becomeDbUser method to TestCase, to encourage more realistic testing, and updating an older test to make use of TestCaseWithFactory instead of unittest.TestCase.
To test:
{{{
./bin/test -vv -t translations_
}}}
To Q/A, see that translations export to branch starts working again on staging. Since none of the branches set up for translations export in the staging database normally have their code hosted on staging (the database being a copy of the production database), all runs of translations-
Jeroen
| Jeroen T. Vermeulen (jtv) wrote : | # |
Thanks. A better name would be welcome, of course.

<henninge> jtv: I wonder if the method should not be called "switchDbUser" like the Layer function.
<jtv> henninge: I wanted this to be "attractive" and have a name that doesn't say "you probably don't need to know about this." At the same time, this doesn't just switch the db user but also commits because otherwise the switch doesn't make much sense. So naming it after one part of the task would be misleading.
<henninge> I had a feeling you'd say something like that ... ;)
<jtv> ah :)
<henninge> jtv: I am not sure I go a long with your assesment of "attractive" method names but it's not all that important, I guess.