Merge lp:~sinzui/launchpad/entitlement-3 into lp:launchpad

Proposed by Curtis Hovey on 2012-03-13
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
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: mp+97300@code.launchpad.net

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._setLicenses()
      * 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
        subscription is not renewed and the project is still proprietary
        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://qastaging.launchpad.net/projects/+new and create a
      non-proprietary project.
    * 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://qastaging.launchpad.net/projects/+new and create a
      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/lp/registry/subscribers.py
    lib/lp/registry/emailtemplates/product-license-dont-know.txt
    lib/lp/registry/emailtemplates/product-license-other-open-source.txt
    lib/lp/registry/emailtemplates/product-license-other-proprietary.txt
    lib/lp/registry/tests/test_subscribers.py

TEST

    ./bin/test -vv lp.registry.tests.test_subscribers

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/lp/registry/subscribers.py
    lib/lp/registry/emailtemplates/product-license-dont-know.txt
    lib/lp/registry/emailtemplates/product-license-other-open-source.txt
    lib/lp/registry/emailtemplates/product-license-other-proprietary.txt
    lib/lp/registry/tests/test_subscribers.py

To post a comment you must log in.
Steve Kowalik (stevenk) wrote :

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.

review: Approve (code)
Curtis Hovey (sinzui) wrote :

/me checks old email.
Yes I can and just have removed the old generic email

Preview Diff

Empty