LocationError: 'tags_cloud_data' on project bugs' page
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Critical
|
j.c.sackett |
Bug Description
As seen on OOPS-1853K1502:
Module zope.traversing
return traversable.
__traceback_info__: (<zope.
Module zope.traversing
raise LocationError(
__traceback_info__: (<zope.
LocationError: (<zope.
This should OOPS when we go to the project bugs' page, but it doesn't. What happens is if you try to access a project which apparently doesn't have tags, the portlet is empty, but it doesn't OOPS. If you try to access directly the url of the portlet, it results on that OOPS.
1) https:/
2) https:/
Not sure how bad this is, as we can't reproduce that unless accessing the portlet url directly. Maybe we should display the empty tagcloud with a title or just doesn't show the empty box at all (but that would be another bug).
Related branches
- Henning Eggers (community): Approve (code)
-
Diff: 87 lines (+44/-3)3 files modifiedlib/lp/bugs/browser/bugtarget.py (+1/-1)
lib/lp/bugs/browser/tests/test_bugtarget_tags.py (+39/-0)
lib/lp/testing/factory.py (+4/-2)
Changed in launchpad: | |
assignee: | nobody → j.c.sackett (jcsackett) |
status: | Triaged → In Progress |
tags: |
added: qa-ok removed: qa-needstesting |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
This isn't actually a LocationError, or at least, the same error can be reproduced on lp.dev and isn't actually a LocationError.
There's a line in the tags_cloud_data property that's causing the error, which gets trapped and raised as a LocationError.
>>> tags = [ tag for tag in tags if tag['tag'] in official_tags + popular_tags]
official_tags is a stormset, popular_tags is a list. You can see this on http:// bugs.launchpad. dev/mozilla/ +bugtarget- portlet- tags-content; casting official_tags to list before this line fixes it (which one might as well do anyway, as one iterates over official_tags several times in the method).