Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 5.1.0-b1
-
Component/s: None
-
Labels:None
-
Epic Link:
Description
Domain Synchronization
The actual task will have been added in CORE-3787 so all that should be done here is the implementation.
Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI.
Once daily we should loop over every service assigned to a 'registrar' type module and make a call to the module to get the service's expiration date using the module's getExpirationDate() method (introduced by CORE-3813). This date should be used to set the renewal date for the service.
Some TLDs require early renewal, perhaps we should add an option to the TLD Pricing page to set the number of days before the expiration date that a service should be renewed.
Issue Links
- is blocked by
-
CORE-3790 Domain Manager: TLD Pricing page
- Closed
Activity
Field | Original Value | New Value |
---|---|---|
Description |
h1. Domain Synchronization
Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI. Once daily task is probably sufficient. |
h1. Domain Synchronization
The actual task will have been added in CORE-3787 so all that should be done here is the implementation. Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI. Once daily we should loop over every service assigned to a 'registrar' type module and make a call to the module to get the service's expiration date using the module's getExpirationDate() method (introduced by CORE-3813). |
Description |
h1. Domain Synchronization
The actual task will have been added in CORE-3787 so all that should be done here is the implementation. Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI. Once daily we should loop over every service assigned to a 'registrar' type module and make a call to the module to get the service's expiration date using the module's getExpirationDate() method (introduced by CORE-3813). |
h1. Domain Synchronization
The actual task will have been added in CORE-3787 so all that should be done here is the implementation. Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI. Once daily we should loop over every service assigned to a 'registrar' type module and make a call to the module to get the service's expiration date using the module's getExpirationDate() method (introduced by CORE-3813). This date should be used to set the renewal date for the service. Some TLDs require early renewal, perhaps we should add an option to the TLD Pricing page to set the number of days before the expiration date that a service should be renewed. |
Parent | CORE-3809 [ 15171 ] | |
Issue Type | Sub-task [ 5 ] | New Feature [ 2 ] |
Story Points | 5 |
Epic Link | CORE-3025 [ 14183 ] |
Sprint | 5.1.0 Sprint 2 [ 126 ] |
Rank | Ranked higher |
Rank | Ranked higher |
Security | Private [ 10000 ] |
Fix Version/s | 5.1.0-b1 [ 11703 ] | |
Fix Version/s | Short Term [ 10800 ] |
Sprint | 5.1.0 Sprint 2 [ 126 ] | 5.1.0 Sprint 3 [ 127 ] |
Rank | Ranked lower |
Assignee | Jonathan Reissmueller [ jonathan ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Remaining Estimate | 0 minutes [ 0 ] | |
Time Spent | 43 minutes [ 2580 ] | |
Worklog Id | 14782 [ 14782 ] |
Time Spent | 43 minutes [ 2580 ] | 1 hour, 40 minutes [ 6000 ] |
Worklog Id | 14783 [ 14783 ] |
Sprint | 5.1.0 Sprint 3 [ 127 ] | 5.1.0 Sprint 4 [ 131 ] |
Rank | Ranked lower |
Assignee | Jonathan Reissmueller [ jonathan ] | Abdy Franco [ abdy ] |
Sprint | 5.1.0 Sprint 4 [ 131 ] | 5.1.0 Sprint 5 [ 132 ] |
Rank | Ranked lower |
Time Spent | 1 hour, 40 minutes [ 6000 ] | 1 day, 1 hour, 32 minutes [ 34320 ] |
Worklog Id | 14888 [ 14888 ] |
Time Spent | 1 day, 1 hour, 32 minutes [ 34320 ] | 1 day, 4 hours, 46 minutes [ 45960 ] |
Worklog Id | 14892 [ 14892 ] |
Status | In Progress [ 3 ] | In Review [ 5 ] |
Resolution | Fixed [ 1 ] |
Description |
h1. Domain Synchronization
The actual task will have been added in CORE-3787 so all that should be done here is the implementation. Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI. Once daily we should loop over every service assigned to a 'registrar' type module and make a call to the module to get the service's expiration date using the module's getExpirationDate() method (introduced by CORE-3813). This date should be used to set the renewal date for the service. Some TLDs require early renewal, perhaps we should add an option to the TLD Pricing page to set the number of days before the expiration date that a service should be renewed. |
h1. Domain Synchronization
The actual task will have been added in CORE-3787 so all that should be done here is the implementation. Every domains expiration date needs to be updated in Blesta to match reality. If a domain is renewed through the registry directly, then we want to notice that change and update it internally so that we do not bill the client for it, and so that we show the correct value in the UI. Once daily we should loop over every service assigned to a 'registrar' type module and make a call to the module to get the service's expiration date using the module's getExpirationDate() method (introduced by CORE-3813). This date should be used to set the renewal date for the service. -Some TLDs require early renewal, perhaps we should add an option to the TLD Pricing page to set the number of days before the expiration date that a service should be renewed.- |
Time Spent | 1 day, 4 hours, 46 minutes [ 45960 ] | 1 day, 5 hours, 10 minutes [ 47400 ] |
Worklog Id | 14896 [ 14896 ] |
Status | In Review [ 5 ] | Closed [ 6 ] |
See CORE-3034 for the inspiration to the specifications