Details
-
Type:
New Feature
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.0.0.b3
-
Fix Version/s: Short Term
-
Component/s: None
-
Labels:None
Description
We need an advanced option for packages, that allow the package to automatically be changed at renewal.
There would need to be at least 2 options for this feature.
1. Which package to change to (drop down)
2. What term for that package to change to (drop down)
Package change must occur at time of renewal, just prior to invoicing and bumping renew date.
This is effective for free trials, where the initial package is free, but after the trial the user must pay.
Example:
Take for example a 15 day free trial. This package has a paid package attached. User orders the free package. Days before renewal is 5, so on day 10 the following happens..
1. The package is changed to a 1 month paid package.
2. The service is invoiced, for the paid package.
3. The renew date is bumped on the service, to be +1 month.
What's interesting is that the package you switch to could be set up to switch them again so it would be possible for the package to change each time it renews.
The package you switch to MUST use the same module. There are no module actions performed, it will not do any kind of upgrade action to the module.
We should discuss where to place this on the package edit/create page, but I'm thinking a toggle-able option so that it's hidden by default.
Also, editing a package should warn if a term is removed that is used by another package for switching to.
Activity
Paul Phillips
created issue -
Paul Phillips
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | bonfire-screenshot-20130601-231301-764.png [ 10563 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.2.0 [ 10002 ] | |
| Fix Version/s | 3.1.0 [ 10001 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.3.0 [ 10100 ] | |
| Fix Version/s | 3.2.0 [ 10002 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.3.0-b2 [ 10507 ] | |
| Fix Version/s | 3.3.0-b1 [ 10100 ] |
For simplicity, we can start by saying the package switches when it renews. So, we would not have an option for the number of renewals before it switches, and would not need to track that. This will cover many cases. For example, if you want to offer a 60 day trial instead of a 30 day trial, then just set a 60 day term.
This is becoming increasingly important for free trials.
With my suggested change, we would only need 2 fields, instead of 3:
1. Which package to change to (drop down)
2. What term for that package to change to (drop down)
Paul Phillips
added a comment - For simplicity, we can start by saying the package switches when it renews. So, we would not have an option for the number of renewals before it switches, and would not need to track that. This will cover many cases. For example, if you want to offer a 60 day trial instead of a 30 day trial, then just set a 60 day term.
This is becoming increasingly important for free trials.
With my suggested change, we would only need 2 fields, instead of 3:
1. Which package to change to (drop down)
2. What term for that package to change to (drop down) Paul Phillips
made changes -
| Fix Version/s | 3.4.0 [ 10400 ] | |
| Fix Version/s | 3.3.0-b2 [ 10507 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.5.0 [ 10401 ] | |
| Fix Version/s | 3.4.0 [ 10400 ] |
Paul Phillips
made changes -
| Security | Private [ 10000 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.5.0-b2 [ 10701 ] | |
| Fix Version/s | 3.5.0-b1 [ 10401 ] |
Paul Phillips
made changes -
| Fix Version/s | 4.0.0 [ 10603 ] | |
| Fix Version/s | 3.5.0-b2 [ 10701 ] |
Cody Phillips (Inactive)
made changes -
| Fix Version/s | 4.0.0 [ 10603 ] |
Paul Phillips
made changes -
| Fix Version/s | Short Term [ 10800 ] |
Paul Phillips
made changes -
| Assignee | Cody Phillips [ cody ] |
Paul Phillips
made changes -
| Summary | Automatic package switching after x renewals | Automatic package switching after activation |
Paul Phillips
made changes -
| Description |
We need an advanced option for packages, that allow the package to automatically be changed after a certain number of renewals.
There would need to be at least 3 options for this feature. 1. Which package to change to (drop down) 2. What term for that package to change to (drop down) 3. Number of renewals until change occurs (drop down or text box, integer required but can be 0) Package change must occur at time of renewal, just prior to invoicing and bumping renew date. The # of renewals would be determined by the # of invoices with line items assigned to the service ID unless it can be tracked more efficiently otherwise. This is effective for free trials, where the initial package is free, but after a period of time the user must pay. Example: Take for example a 15 day free trial. This package has a paid package attached, with 0 set for # of renewals to switch. User orders the free package. Days before renewal is 5, so on day 10 the following happens.. 1. The package is changed to a 1 month paid package. 2. The service is invoiced, for the paid package. 3. The renew date is bumped on the service, to be +1 month. This simple feature allows for lots of possibilities. We should discuss where to place this on the package edit/create page, but I'm thinking a toggle-able option so that it's hidden by default. Also, editing a package should warn if a term is removed that is used by another package for switching to. |
We need an advanced option for packages, that allow the package to automatically be changed after activation.
There would need to be at least 2 options for this feature. 1. Which package to change to (drop down) 2. What term for that package to change to (drop down) Package change must occur at time of renewal, just prior to invoicing and bumping renew date. This is effective for free trials, where the initial package is free, but after the trial the user must pay. Example: Take for example a 15 day free trial. This package has a paid package attached. User orders the free package. Days before renewal is 5, so on day 10 the following happens.. 1. The package is changed to a 1 month paid package. 2. The service is invoiced, for the paid package. 3. The renew date is bumped on the service, to be +1 month. We should discuss where to place this on the package edit/create page, but I'm thinking a toggle-able option so that it's hidden by default. Also, editing a package should warn if a term is removed that is used by another package for switching to. |
Paul Phillips
made changes -
| Summary | Automatic package switching after activation | Automatic package switching at renewal |
Paul Phillips
made changes -
| Description |
We need an advanced option for packages, that allow the package to automatically be changed after activation.
There would need to be at least 2 options for this feature. 1. Which package to change to (drop down) 2. What term for that package to change to (drop down) Package change must occur at time of renewal, just prior to invoicing and bumping renew date. This is effective for free trials, where the initial package is free, but after the trial the user must pay. Example: Take for example a 15 day free trial. This package has a paid package attached. User orders the free package. Days before renewal is 5, so on day 10 the following happens.. 1. The package is changed to a 1 month paid package. 2. The service is invoiced, for the paid package. 3. The renew date is bumped on the service, to be +1 month. We should discuss where to place this on the package edit/create page, but I'm thinking a toggle-able option so that it's hidden by default. Also, editing a package should warn if a term is removed that is used by another package for switching to. |
We need an advanced option for packages, that allow the package to automatically be changed at renewal.
There would need to be at least 2 options for this feature. 1. Which package to change to (drop down) 2. What term for that package to change to (drop down) Package change must occur at time of renewal, just prior to invoicing and bumping renew date. This is effective for free trials, where the initial package is free, but after the trial the user must pay. Example: Take for example a 15 day free trial. This package has a paid package attached. User orders the free package. Days before renewal is 5, so on day 10 the following happens.. 1. The package is changed to a 1 month paid package. 2. The service is invoiced, for the paid package. 3. The renew date is bumped on the service, to be +1 month. What's interesting is that the package you switch to could be set up to switch them again so it would be possible for the package to change each time it renews. The package you switch to MUST use the same module. There are no module actions performed, it will not do any kind of upgrade action to the module. We should discuss where to place this on the package edit/create page, but I'm thinking a toggle-able option so that it's hidden by default. Also, editing a package should warn if a term is removed that is used by another package for switching to. |
The idea behind this one is for support for trials and similar. Buy for cheap or free, and then it switches to another package at the next renewal, or after x renewals and invoices at that package rate.
The package must use the same module.