Merge lp:~bac/launchpad/bug-639703-pg-bugs into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Gavin Panella on 2010-10-07 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 11737 |
| Proposed branch: | lp:~bac/launchpad/bug-639703-pg-bugs |
| Merge into: | lp:launchpad |
| Diff against target: |
557 lines (+242/-74) 13 files modified
lib/canonical/launchpad/pagetitles.py (+0/-2) lib/lp/bugs/browser/bugtask.py (+12/-2) lib/lp/bugs/browser/tests/test_bugtask.py (+108/-2) lib/lp/bugs/configure.zcml (+6/-0) lib/lp/bugs/stories/bug-release-management/xx-review-nominated-bugs.txt (+4/-4) lib/lp/bugs/stories/bugs/xx-front-page-search.txt (+2/-2) lib/lp/bugs/stories/bugs/xx-portlets-bug-milestones.txt (+13/-1) lib/lp/bugs/stories/bugs/xx-portlets-bug-series.txt (+13/-1) lib/lp/bugs/stories/bugs/xx-project-bugs-page.txt (+1/-1) lib/lp/bugs/stories/bugtask-searches/xx-advanced-people-filters.txt (+1/-1) lib/lp/bugs/templates/buglisting-default.pt (+77/-54) lib/lp/soyuz/stories/packaging/package-pages-navigation.txt (+1/-2) lib/lp/testing/views.py (+4/-2) |
| To merge this branch: | bzr merge lp:~bac/launchpad/bug-639703-pg-bugs |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Gavin Panella (community) | 2010-10-04 | Abstain on 2010-10-07 | |
| Henning Eggers (community) | code ui* | 2010-10-04 | Approve on 2010-10-07 |
| Curtis Hovey (community) | ui | 2010-10-06 | Approve on 2010-10-06 |
| Matthew Revell (community) | text | 2010-10-04 | Approve on 2010-10-05 |
|
Review via email:
|
|||
Commit Message
Correctly report bug tracking status for project groups.
Description of the Change
= Summary =
Currently if a project group has sub-projects but none use Launchpad for
bug tracking a user will be allowed to attempt to file a bug. At the
next step the user is informed there are no projects that track bugs in LP.
== Proposed fix ==
Prevent such a project group from displaying the portlets and providing
links to bug reporting and other bug activities.
== Pre-implementation notes ==
Talk with Curtis
== Implementation details ==
As above
== Tests ==
bin/test -vvm lp.bugs -t test_bugtask
== Demo and Q/A ==
Create a project group and see that it states it does not use Launchpad
for bug tracking. Add a project that does not use bug tracking and
ensure the message is the same. Set one of the project to do bug
tracking and observe the change in the page.
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
./lib/lp/
2201: Line exceeds 78 characters.
| Brad Crittenden (bac) wrote : | # |
| Henning Eggers (henninge) wrote : | # |
Hello Bac,
thanks for making Launchpad a bit more user-friendly! ;-) I still need to send
you on another round-trip, though. Please find my comments below.
Henning
Am 04.10.2010 15:44, schrieb Brad Crittenden:
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> @@ -168,6 +168,7 @@
> ObjectImageDisp
> PersonFormatterAPI,
> )
> +
> from canonical.
> from canonical.
> from canonical.
> @@ -2987,8 +2988,17 @@
> return False
>
> @property
> + def should_
> + """Return False if a project group that does not use Launchpad."""
> + if not self._projectCo
> + return True
> + involvement = getMultiAdapter
> + name="+
> + return involvement.
This seems odd, to create a view just to get a property that is really a
property of the context. The "official_malone" property should be defined in
ProjectGroup and could be implemented like this: ;-)
@cachedproperty
def offcial_
return any([product.
Unless I misunderstood something, I see this misuse of a view as a real
blocker for landing this. This earned you the "need-fixing" ;-)
> +
> + @property
> def form_has_
> - """Return True of the form has errors, otherwise False."""
> + """Return True if the form has errors, otherwise False."""
Good catch! ;)
> return len(self.errors) > 0
>
> def validateVocabul
>
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
[...]
> @@ -418,6 +424,88 @@
> view.form_
>
>
> +class TestProjectGrou
> + """Test the bugs overview page for Project Groups."""
> +
> + layer = LaunchpadFuncti
> +
> + def setUp(self):
> + super(TestProje
> + self.owner = self.factory.
> + self.projectgroup = self.factory.
> + owner=self.owner)
> +
> + def makeSubordinate
> + """Create a new product and add it to the project group."""
> + product = self.factory.
> + with person_
> + product.project = self.projectgroup
> + expected = {True: 'LAUNCHPAD',
> + False: 'UNKNOWN',
> + }
> + self.assertEqual(
> + expected[
This looks like a forgotten sanity check? If you wish t...
| Matthew Revell (matthew.revell) wrote : | # |
Very happy to see this change, thanks Brad.
I'd like to suggest some alternative text:
Sorry, you can't report a bug for the $ProjectGroup project group. None of the
projects within the group use Launchpad for bug tracking. Please check the
$ProjectGroup website for details of where they track bug reports.
I have suggested this change because I think the most important thing about the message is that you can't report the bug you wanted to. Only then should we explain why. I think we should then give the person a next step ... ideally we should link to their external bug tracker, or as a second-best we should link to the project's website. If we can't do either, I think the above text is a nod towards being helpful.
| Brad Crittenden (bac) wrote : | # |
On Oct 4, 2010, at 22:39 , Henning Eggers wrote:
> Review: Needs Fixing code
> Hello Bac,
> thanks for making Launchpad a bit more user-friendly! ;-) I still need to send
> you on another round-trip, though. Please find my comments below.
>
Thanks for the review Henning.
> Henning
>
> Am 04.10.2010 15:44, schrieb Brad Crittenden:
>> === modified file 'lib/lp/
>>
>> @property
>> + def should_
>> + """Return False if a project group that does not use Launchpad."""
>> + if not self._projectCo
>> + return True
>> + involvement = getMultiAdapter
>> + name="+
>> + return involvement.
>
> This seems odd, to create a view just to get a property that is really a
> property of the context. The "official_malone" property should be defined in
> ProjectGroup and could be implemented like this: ;-)
>
> @cachedproperty
> def offcial_
> return any([product.
>
> Unless I misunderstood something, I see this misuse of a view as a real
> blocker for landing this. This earned you the "need-fixing" ;-)
It does look odd, Henning. For a lot of pillars, including ProjectGroup, the official usage flags are set in PillarView. The pattern you see here is repeated elsewhere.
On IRC we discussed landing this branch and later looking at moving the settings to the appropriate models. The bug for that work is bug 655036.
>
>> @@ -418,6 +424,88 @@
>> view.form_
>>
>>
>> +class TestProjectGrou
>> + """Test the bugs overview page for Project Groups."""
>> +
>> + layer = LaunchpadFuncti
>> +
>> + def setUp(self):
>> + super(TestProje
>> + self.owner = self.factory.
>> + self.projectgroup = self.factory.
>> + owner=self.owner)
>> +
>> + def makeSubordinate
>> + """Create a new product and add it to the project group."""
>> + product = self.factory.
>> + with person_
>> + product.project = self.projectgroup
>> + expected = {True: 'LAUNCHPAD',
>> + False: 'UNKNOWN',
>> + }
>> + self.assertEqual(
>> + expected[
>
> This looks like a forgotten sanity check? If you wish to keep it in here you
> should give it its own tests and mention in the comment their sanity nature.
Yes, it serves no purpose and is removed.
>
>> +
>> + def test_empty_
>
> This one and the next three tests belong in the model tests for
> ProjectGroup.
Deferred.
>> + def test_project_
>> + # A project group that has no projects using Launchpad ...
| Brad Crittenden (bac) wrote : | # |
Thanks for the text changes Matthew. On IRC we agreed on:
You cannot report a bug for <tal:name replace="name"/> as none of
the projects within the group use Launchpad for bug tracking.
Please check the individual projects for details
of where bugs are reported.
| Henning Eggers (henninge) wrote : | # |
So, the code is good now. Thanks for adding the XXX and filing the bug.
UI-wise I find the page too empty and inconsistent with similar pages we have on project groups and projects. Please have a look here:
http://
http://
The page will at least need a page heading and bread crumbs. The text should most likely be <strong> like on the other pages to indicate that it needs attention. Add a help link for bonus points. ;-)
Thanks
approved code
needs-fixing ui*
| Brad Crittenden (bac) wrote : | # |
Hi Henning,
Thanks for the UI review. I have added the page heading and breadcrumbs:
http://
http://
I have not yet added a help link but will do so, pending Curtis' UI mentoring review.
| Curtis Hovey (sinzui) wrote : | # |
Thanks Brad and Henning. This is a very nice fix and I am very pleased we fixed some 3.0-ism too. As Henning pointed, we want a consistent experience:
The page should show the owner the same help link as is shown on projects:
(i) Getting started with bug tracking in Launchpad.
<https:/
There is a secondary issue that help does not explain exactly what bug tracking features project groups provide. Actually, Lp has a poor understanding of what PGs provide. I think PG documentation is a secondary issue. We will discuss PGs over the next few months and decide their fate.
| Henning Eggers (henninge) wrote : | # |
All good now, thanks for improving this! ;-)
| Gavin Panella (allenap) wrote : | # |
Looks like this is all reviewed, so abstaining on behalf of Launchpad code reviewers.

Screenshot at http:// people. canonical. com/~bac/ pg-no-buggy. png