Merge lp:~elachuni/ubuntu-webcatalog/display-custom-screenshot into lp:ubuntu-webcatalog
Status: | Merged |
---|---|
Approved by: | Anthony Lenton |
Approved revision: | 49 |
Merged at revision: | 47 |
Proposed branch: | lp:~elachuni/ubuntu-webcatalog/display-custom-screenshot |
Merge into: | lp:ubuntu-webcatalog |
Diff against target: |
170 lines (+53/-14) 8 files modified
src/webcatalog/management/commands/import_ratings_stats.py (+4/-2) src/webcatalog/models/applications.py (+1/-1) src/webcatalog/static/css/webcatalog.css (+6/-0) src/webcatalog/templates/webcatalog/application_detail.html (+4/-4) src/webcatalog/tests/factory.py (+2/-2) src/webcatalog/tests/test_commands.py (+14/-0) src/webcatalog/tests/test_forms.py (+10/-0) src/webcatalog/tests/test_views.py (+12/-5) |
To merge this branch: | bzr merge lp:~elachuni/ubuntu-webcatalog/display-custom-screenshot |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Michael Nelson (community) | Approve | ||
Review via email: mp+70956@code.launchpad.net |
Commit message
Display the custom screenshot_url in the application details page, if included.
Description of the change
Overview
========
A branch to display the custom screenshot_url in the application details page, if included.
Details
=======
The screenshot_url field was modified slightly so that it doesn't verify if the page actually exists. This is a bad idea for url fields in general (it expects us to allow arbitrary outbound connections from our DC), but in this case specifically it made even less sense as most of the time the field is populated by a script that doesn't commit typos.
While I was there, I found an issue with the import_
Finally, I added a bit of css to the thumbnail screenshot to make it match the current USC widget: 225px wide, and with a slight white and gray padded border.
Ouch... what is the actual error returned for that query? Is it because the sql ends up way too large? Anyway, great fix!
Nice test for the verify_exists too. I've always wondered about that kind of thing... how far do we go when testing the configuration of our models? We need to check the configuration of our models (required fields, for example), or even valid data when we've customized what's valid and what's not (with custom clean, or a RegExField). Other times we add a test to ensure the configuration isn't reverted.
Great stuff :)