Merge lp:~sinzui/launchpad/entitlement-3 into lp:launchpad
| Status: | Merged |
|---|---|
| Merged at revision: | 14953 |
| Proposed branch: | lp:~sinzui/launchpad/entitlement-3 |
| Merge into: | lp:launchpad |
| Prerequisite: | lp:~sinzui/launchpad/entitlement-2 |
| Diff against target: | 0 lines |
| To merge this branch: | bzr merge lp:~sinzui/launchpad/entitlement-3 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Steve Kowalik (community) | code | 2012-03-13 | Approve on 2012-03-14 |
| Dan Harrop-Griffiths | text | 2012-03-14 | Pending |
|
Review via email:
|
|||
Commit Message
Send the appropriate email about project licensing and show a notice about the complimentary commercial subscription
Description of the Change
Pre-implementation: StevenK
We want to give proprietary projects complimentary commercial subscriptions
to ensure that projects can be configured setup to no disclose information
from the start. This solves outstanding issues.
This branch replaces the generic email sent to the user about a special
licensing situation with one specific the the case.
-------
RULES
PREVIOUS BRANCHES
* When a OTHER/PROPRIETARY license is added to a project, and the
project does not have any commercial subscriptions add a commercial
subscription that expires in 4 weeks.
* We check for previous active and expired commercial subscriptions
to ensure that users cannot get extra time by reconfiguring their
project.
* Product.
* Use StevenK's example from the LaunchpadFactory to create a
commercial subscription without a voucher.
* Move license email code from the view to the model so that API changes
work.
THIS BRANCH
* The UI and an email is sent to inform the user of the complimentary
commercial subscription and it will explain when it expires and how
to active the proprietary features. There is a link to learn more
more about commercial subscriptions and how to purchase them.
* This email probably replaces the existing email that explain Lp's
licensing and purchasing rules.
FUTURE BRANCHES
* At 4 weeks and 1 weeks before a commercial subscription expires, a
reminder is sent to purchase a commercial subscription.
* the email also explain that the project will be deactivated if the
to ensure proprietary is not added added.
* Users can choose an Open source license. Branches and bugs will
remain proprietary because we understand that confidential information
can never be disclosed, but new bugs and branches will be public...
the project's focus of development must be set to a public branch.
* Bonus points if there is a clear way to identify a Canonical owned
project and set the commercial subscription to expire in 10 years.
QA
* Visit https:/
non-
* Verify it does not have a commercial subscription
* Use Change details to set the license to proprietary.
* Verify it has a commercial subscription that expires in one month.
* Verify a notice explains the situation and that privacy features
are available.
* Verify an email was sent to the maintainer explaining how to
purchase a commercial subscription and what they provide.
* Visit https:/
proprietary project.
* Verify it has a commercial subscription that expires in one month.
* Verify a notice explains the situation and how to configure proprietary
features.
* Verify an email was sent to the maintainer explaining how to
purchase a commercial subscription and that privacy features are
available.
* Force the license to expire.
* Set the open project project's license to proprietary
* Verify an email explains that the commercial subscription has expired.
LINT
lib/
lib/
lib/
lib/
lib/
TEST
./bin/test -vv lp.registry.
IMPLEMENTATION
I split the generic licensing email into messages that explained the exact
situation. I think this will reduce the number of confused users who send
emails to <email address hidden> because the old email described situations
that were not pertinent. I updated the LicenseNotification object to create
a specific message about the state of the commercial license and include
it in the email and browser notices. The _indent() helper was unused, as
was some of the interpolated variables so I removed them.
lib/
lib/
lib/
lib/
lib/
| Curtis Hovey (sinzui) wrote : | # |
/me checks old email.
Yes I can and just have removed the old generic email

This looks like excellent work. Will the current e-mail to commercial project owners be removed in a later branch? I'm happy with the code, and have no comment, but would like Dan to +1 the text of the mails.