This looks fairly innocuous, but it has an interesting side-effect: it
means that redefining `_return_url` in subclasses is now effective, when
previously it wasn't because the `next_url` and `cancel_url` names were
bound to the definition in the superclass. As a result, I don't think
the property in the subclass (`POTemplateEditView`) was being called in
practice. Arranging for it to be called caused failures in
`lib/lp/translations/stories/standalone/xx-potemplate-admin.rst` and
`lib/lp/translations/stories/standalone/xx-potemplate-edit.rst`. I
considered simply removing the property in the subclass, but based on
the comment at the top there does seem to be a point to it, so I made
the effort to repair it.
The problem was that `POTemplateEditView._return_url` failed to check
whether it needs to construct a new URL in the case where the default
return URL is provided by a hidden input in the form; but that's
normally the case when an edit form is being submitted. Moving the
check for whether the default return URL contains "/+pots/" out one
level, so that it's called regardless of the source of the default
return URL, fixes the problem.
I also removed `POTemplateEditView._return_attribute_name`, since it was
only used by `LaunchpadFormView._return_url` which is now overridden
here, so it had become effectively dead code.
Commit 65e983ad01a81e2ec3d6ceb0bb08bf7868b67e7f changed
`MaloneView.error_message` from being initialized to None to being a
property that returns None, due to needing to convince `mypy` that its
type was compatible with that of `LaunchpadView.error_message`.
However, this caused test failures in
`lp.bugs.browser.tests.test_bugs.TestMaloneView.test_redirect_unknown_bug_fail`
and
`lp.bugs.browser.tests.test_bugs.TestMaloneView.test_redirect_list_of_bug_fail`,
because `MaloneView._redirectToBug` expected to be able to assign to
`error_message`.
I think it's best to rearrange `MaloneView` to conform to the
expectations of the base class for `error_message`: that is, assignments
to it must be either None or an `IStructuredString`. The `structured`
helper makes it easier to write pages in a way that avoids XSS attacks
by separating fixed text from interpolated variables such that
interpolations are HTML-escaped. As it happens I satisfied myself that
this page was already XSS-safe, but this approach makes it a bit clearer
in a way that's more usual for Launchpad, and makes it easier to keep
the type-checker happy.
The default value was changed from None to "" in commit
551507a0b01442f3c6ca7b827195298fadad64a0, but they should actually stay
as None and be explicitly annotated as optional strings.
`LaunchpadScript.__init__` behaves differently if they're None vs.
empty.
This caused test failures in
`lib/lp/bugs/doc/checkwatches-cli-switches.rst` and
`lib/lp/translations/doc/distroseries-translations-copy.rst`.
When creating a `SourcePackageRelease` from a `CIBuild`, we have to take
the release's source package name from the namespace of the build's Git
repository, since that means everything is grouped together properly
under the same source package name, and it also allows us to handle
source package types whose true package name can't be used as a source
package name (notably Go modules); teams building these also generally
try to use the same source package name as used in Ubuntu, to make it
easier to associate fixes in different distributions.
However, this meant that we published Python sdists to the wrong paths
if their true package name didn't correspond to the repository
namespace. To fix this, pass through the true package name via
`SourcePackageRelease.user_defined_fields` and use that in the
publishing machinery.
Ensure that getUserDefinedField works consistently
`SourcePackageRelease.user_defined_fields` returns an empty list if the
corresponding database column is NULL, but
`BinaryPackageRelease.user_defined_fields` didn't match that, causing
`BinaryPackageRelease.getUserDefinedField` to raise an exception in that
case. This made it difficult to write code that works with both types.
Currently, this command runs the mypy checks on `lp.answers`. In future
we can add more subpackages to the list once they pass.
If you want to lint another subpackage, e.g. `lp.bugs`, you have to run
```
tox -e mypy -- lib/lp/bugs
```
Please note that you cannot run tox from within the LXC container on
Xenial as the available mypy version has issues with finding Python
files (recursion does not work properly).
Additionally, this commit fixes issues reported by mypy in lp.answers.
