Details
-
Type: Story
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 4.5.0-b1
-
Fix Version/s: 4.6.0-b1
-
Component/s: Staff Interface
-
Labels:None
Description
Add "type" to the pricings table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL
Renewing Services
When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price
This allows 2 things:
- Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price
- Domains often renew at a different price, so it solves the problem with domain renewal pricing
UI Changes
When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column.
OR we can always have a column for renew price, but must click something to activate it for each term. Like a Checkbox.
[x] [input field] (Check the box to set different renew price)
Checkbox unchecked, input field disabled, input box has a placeholder with description of checking the box to set a price.
We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services.
Activity
Field | Original Value | New Value |
---|---|---|
Summary | Add pricing types to Packages | Add additional pricing options to Packages |
Description |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
Description |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. Like a Checkbox. We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
Description |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. Like a Checkbox. We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. Like a Checkbox. [x] [input field] (Check the box to set different renew price) We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
Description |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. Like a Checkbox. [x] [input field] (Check the box to set different renew price) We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
-Add "type" to the _pricings_ table, possibly as ENUM ("new", "renew", "transfer"). By default, all pricing would be set to "new".-
Add the following columns to the pricings table after price: price_renew, price_transfer defaulting to NULL h2. Renewing Services When services renew, they should renew at the price set for "renew" unless it is null, in which case it should fallback to the price defined in pricings.price This allows 2 things: * Staff can set a different price for new vs renewing services. For example, 1 month free trial, or promotion period, and then renewal at a different price * Domains often renew at a different price, so it solves the problem with domain renewal pricing h2. UI Changes When creating/editing a Package we should add a way so that staff can manually set a different renew price if they choose, but for simplicity the field should not be shown by default. Possibly a link under the "Options" section called "More"? Clicking the link would show the Renew column after the Price column. OR we can always have a column for renew price, but must click something to activate it for each term. Like a Checkbox. [x] [input field] (Check the box to set different renew price) Checkbox unchecked, input field disabled, input box has a placeholder with description of checking the box to set a price. We do not need to show the transfer price because the core will not use it. The domain manager will set the price for price, price_renew, and price_transfer on its own. The UI changes here are solely to support the renew price for other services. |
Summary | Add additional pricing options to Packages | Add renewal pricing options to Packages |
Parent | CORE-3026 [ 14184 ] | |
Issue Type | Sub-task [ 5 ] | Improvement [ 4 ] |
Story Points | 5 |
Epic Link | CORE-3025 [ 14183 ] |
Issue Type | Improvement [ 4 ] | Story [ 7 ] |
Summary | Add renewal pricing options to Packages | Add renewal pricing option |
Fix Version/s | 4.6.0-b1 [ 11117 ] | |
Fix Version/s | Short Term [ 10800 ] |
Epic Link | CORE-3025 [ 14183 ] |
Security | Private [ 10000 ] |
Story Points | 5 | 8 |
Sprint | 4.6.0 Sprint 3 [ 79 ] |
Rank | Ranked higher |
Sprint | 4.6.0 Sprint 3 [ 79 ] | 4.6.0 Sprint 2 [ 69 ] |
Rank | Ranked lower |
Sprint | 4.6.0 Sprint 2 [ 69 ] | 4.6.0 Sprint 2, 4.6.0 Sprint 3 [ 69, 79 ] |
Rank | Ranked higher |
Sprint | 4.6.0 Sprint 2, 4.6.0 Sprint 3 [ 69, 79 ] | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4 [ 69, 79, 80 ] |
Rank | Ranked higher |
Sprint | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4 [ 69, 79, 80 ] | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4, 4.6.0 Sprint 5 [ 69, 79, 80, 83 ] |
Rank | Ranked higher |
Status | Open [ 1 ] | In Progress [ 3 ] |
Assignee | Jonathan Reissmueller [ jonathan ] |
Status | In Progress [ 3 ] | In Review [ 5 ] |
Resolution | Fixed [ 1 ] |
Remaining Estimate | 0 minutes [ 0 ] | |
Time Spent | 6 hours, 18 minutes [ 22680 ] | |
Worklog Id | 12102 [ 12102 ] |
Time Spent | 6 hours, 18 minutes [ 22680 ] | 7 hours, 55 minutes [ 28500 ] |
Worklog Id | 12108 [ 12108 ] |
Sprint | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4, 4.6.0 Sprint 5 [ 69, 79, 80, 83 ] | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4, 4.6.0 Sprint 6, 4.6.0 Sprint 5 [ 69, 79, 80, 81, 83 ] |
Time Spent | 7 hours, 55 minutes [ 28500 ] | 1 day, 55 minutes [ 32100 ] |
Worklog Id | 12108 [ 12108 ] |
Time Spent | 1 day, 55 minutes [ 32100 ] | 2 days, 3 hours, 5 minutes [ 68700 ] |
Worklog Id | 12116 [ 12116 ] |
Time Spent | 2 days, 3 hours, 5 minutes [ 68700 ] | 2 days, 4 hours, 11 minutes [ 72660 ] |
Worklog Id | 12137 [ 12137 ] |
Time Spent | 2 days, 4 hours, 11 minutes [ 72660 ] | 2 days, 4 hours, 41 minutes [ 74460 ] |
Worklog Id | 12161 [ 12161 ] |
Time Spent | 2 days, 4 hours, 41 minutes [ 74460 ] | 2 days, 5 hours, 54 minutes [ 78840 ] |
Worklog Id | 12164 [ 12164 ] |
Time Spent | 2 days, 5 hours, 54 minutes [ 78840 ] | 2 days, 7 hours, 8 minutes [ 83280 ] |
Worklog Id | 12165 [ 12165 ] |
Sprint | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4, 4.6.0 Sprint 6, 4.6.0 Sprint 5 [ 69, 79, 80, 81, 83 ] | 4.6.0 Sprint 2, 4.6.0 Sprint 3, 4.6.0 Sprint 4, 4.6.0 Sprint 6, 4.6.0 Sprint 5, 4.6.0 Sprint 7 [ 69, 79, 80, 81, 83, 85 ] |
Status | In Review [ 5 ] | Closed [ 6 ] |