Merge lp:~deryck/launchpad/actually-save-info-type-on-project-create into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Deryck Hodge on 2012-10-04 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 16088 |
| Proposed branch: | lp:~deryck/launchpad/actually-save-info-type-on-project-create |
| Merge into: | lp:launchpad |
| Diff against target: |
206 lines (+66/-14) 4 files modified
lib/lp/registry/browser/product.py (+6/-6) lib/lp/registry/browser/tests/test_product.py (+40/-1) lib/lp/registry/javascript/product_views.js (+13/-7) lib/lp/registry/javascript/tests/test_product_views.js (+7/-0) |
| To merge this branch: | bzr merge lp:~deryck/launchpad/actually-save-info-type-on-project-create |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Aaron Bentley (community) | 2012-10-03 | Approve on 2012-10-03 | |
|
Review via email:
|
|||
Commit Message
Ensure the project creation web UI doesn't error when saving, and ensure that it also saves information_type correctly, when the new private projects feature UI is enabled.
Description of the Change
This branch fixes a couple bugs discovered in the new private projects UI for project creation.
The JavaScript needed to be updated to fill in a value for license_info if the "Other/Proprietary" option was selected. This will prevent the form validation from throwing an error. I added a test inside the excellent test coverage for this new js code.
Also, the project creation web UI was not saving information type. This changes the form to save PUBLIC unless the feature flag is set, then we will save the value returned in form data. I added a couple tests here, too, that ensure that information_type is saved correctly whether the private projects feature flag is set or not/
There are some long lines of lint in the js file, which I'll cleanup before landing.
| Deryck Hodge (deryck) wrote : | # |
Sure, I can make those changes. Thanks for the review.
| Deryck Hodge (deryck) wrote : | # |
I realized now there's no need to hide the form data get behind a feature flag since None is an acceptable value. I've updated again, which makes this a little cleaner still.
| Aaron Bentley (abentley) wrote : | # |
Nice.

This looks reasonable.
Setting information_type to PUBLIC is a bit of a DRY violation, since createProject takes care of that when unspecified or None. It's not the only DRY violation in this regard, as the EnumCol declares a default (but I can't figure out how to access it).
Similarly, declaring private_ projects_ flag is a DRY violation. I would prefer if you moved it to a module-level variable, since it's already used in two other places.