Merge lp:~bac/launchpad/bug-490518-link-suggestion into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Curtis Hovey on 2010-01-28 |
| Approved revision: | not available |
| Merged at revision: | not available |
| Proposed branch: | lp:~bac/launchpad/bug-490518-link-suggestion |
| Merge into: | lp:launchpad |
| Diff against target: |
409 lines (+249/-61) 7 files modified
lib/lp/app/templates/base-layout-macros.pt (+18/-0) lib/lp/registry/browser/configure.zcml (+7/-0) lib/lp/registry/browser/sourcepackage.py (+58/-3) lib/lp/registry/browser/tests/sourcepackage-views.txt (+64/-0) lib/lp/registry/stories/packaging/xx-sourcepackage-packaging.txt (+4/-3) lib/lp/registry/templates/sourcepackage-index.pt (+1/-55) lib/lp/registry/templates/sourcepackage-portlet-associations.pt (+97/-0) |
| To merge this branch: | bzr merge lp:~bac/launchpad/bug-490518-link-suggestion |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Martin Albisetti (community) | ui | Approve on 2010-01-29 | |
| Curtis Hovey (community) | code | 2010-01-25 | Approve on 2010-01-28 |
|
Review via email:
|
|||
Commit Message
Allow users to set upstream associations via a new portlet on the sourcepackage page.
| Brad Crittenden (bac) wrote : | # |
| Curtis Hovey (sinzui) wrote : | # |
..
=== modified file 'lib/lp/
--- lib/lp/
+++ lib/lp/
...
> @@ -294,3 +301,49 @@
> """A View to show Answers help."""
>
> page_title = 'Help and support options'
> +
> +
> +class SourcePackageAs
LaunchpadEditFo
the case here; it is creating Packaging object though an indirect method.
Why was this base class used instead of LaunchpadFormView? It is because
it can be used to update the Packaging object after it is set? If so,
the view will have to be registered on IPackaging, which does not exist in
this scenario.
> + """A view for linking to an upstream package."""
> +
> + schema = Interface
> + custom_widget(
> + 'upstream', LaunchpadRadioW
> + product_suggestions = None
> +
> + def setUpFields(self):
> + """See `LaunchpadFormV
> + super(SourcePac
> + # Find registered products that are similarly named to the source
> + # package.
> + product_vocab = getVocabularyRe
> + matches = product_
> + # Based upon the matching products, create a new vocabulary with
> + # term descriptions that include a link to the product.
> + self.product_
> + vocab_terms = []
> + for item in matches:
> + product = item.value
> + self.product_
> + item_url = canonical_
> + description = """<a href="%s">%s</a>""" % (
> + item_url, product.
I think this needs escaping. product.displayname may contain [?><].
> + vocab_terms.
> + upstream_vocabulary = SimpleVocabular
> +
> + self.form_fields = Fields(
> + Choice(
> + title=_('Upstream project'),
I have been pondering cases where we need to be clear that we are showing
*registered* launchpad projects. Many of the confusing-ui issues is that users
do not understand that someone must register the project for it to be used.
Does the use of *registered* provide a clue that someone may need to register
the upstream project to complete the task?
> + default=None,
> + vocabulary=
> + #description=
I suppose this is not needed.
> + required=True))
> +
> + @action('Link to Upstream Project', name='link')
> + def link(self, action, data):
> + upstream = data.get(
> + self.context.
> + self.request.
> + 'The project %s was linked to this source package.' %
> + upstream.
> + ...
| Brad Crittenden (bac) wrote : | # |
Thanks for the review Curtis -- all good suggestions and all changes made except for the plural issue. I'll work with you today to extend and incorporate your macro.
| Brad Crittenden (bac) wrote : | # |
Curtis, based on your macro I created:
<metal:plural-msg define-
<tal:comment condition=
Expected variables to be defined in a containing tag or global:
count - value to check to determine plural form
singluar - string to use when count == 1
plural - string to use when count > 1. If no plural is given it defaults
to the singular value + 's'.
</tal:comment>
<tal:singular
condition=
replace=
<tal:plural
define=
condition=
replace=
</metal:plural-msg>
And invoked it like:
>
<b>
</b>
That's all good but it is longer to use than the old way and required me to create a new property on the view class (product_
What do you think?
| Curtis Hovey (sinzui) wrote : | # |
Your changes look good. I am going to merge your plural marcro into my branch and use it because your implementation is more universal.

= Summary =
The source package page needs a portlet to display upstream information if known -or-
allow the user to set it if not known.
== Proposed fix ==
A portlet is created that creates a widget of likely Launchpad projects the user can
pick from to set the upstream for the source package. A link to go to the existing
package editing form is also provided.
== Pre-implementation notes ==
The work is based on the design proposed by Curtis at /dev.launchpad. net/Registry/ UbuntuLinkUpstr eam. He and I had discussions
https:/
before and during the implementation.
== Implementation details ==
Pretty straightforward: create the portlet and DTRT.
== Tests ==
bin/test -vvt sourcepackage- views.txt
== Demo and Q/A ==
In launchpad.dev, remove the association for evolution to hoary and then view: /launchpad. dev/ubuntu/ hoary/+ source/ evolution
https:/
= Launchpad lint =
Checking for conflicts. and issues in doctests and templates.
Running jslint, xmllint, pyflakes, and pylint.
Using normal rules.
Linting changed files: registry/ browser/ configure. zcml registry/ browser/ sourcepackage. py registry/ templates/ sourcepackage- index.pt registry/ browser/ tests/sourcepac kage-views. txt registry/ templates/ sourcepackage- portlet- associations. pt
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
== Pylint notices ==
lib/lp/ registry/ browser/ sourcepackage. py interface' (No module named restful)
28: [F0401] Unable to import 'lazr.restful.