Add extended price lookup policy

[vohmar]

Starting from 1st of May .ee will have minimum 3 month registrations on one end 10 year max registrations at the other. That means 13 different pricelist entries per paied operation. As there are two at the moment for .ee and 5 zones that makes the number of entries to manage 130. This is error prone and therefore current solution is not sufficient.

To solve the problem there should be a model to derive the price from other price list entries if the specific operation, period and zone is missing (ie if entry for 10y registration is missing 1y price is used and multiplied by 10 to get the effective price)

No changes are needed in /admin/prices for price list entry creation and update for this solution. The logic to find the price is done on registry server level.

Logic: hierarchy based price finding process.

hierarchy1: zone and sub-zones - for example .pri.ee is sub-zone of .ee or .pri.ee is parent zone to .example.pri.ee zone. So if there is no required price specified in the zone look for the prices in parent zone.
hierarhy2: operations - create is the base operation. ie if renew is paied operation and it is missing specific pricelist entry, look for the price for create operation. For example renew request for 3 years - if specific price list entry is missing look for the create price for the 3 years
hierarchy3: periods - 1 year is base for any longer full year periods. For example 10 year create request - if specific price list entry is missing for this period look for the 1 year period and multiply it by 10 to get the price for 10 years.
base price for shorter periods than a year is 1 month

full hierarchy:
1y tld create (base) > 1y tld renew > Ny tld create > Ny tld renew > 1y sld create > 1y sld renew etc

Ny - stands for longer periods than 1y ie 2y, 5y, 10y
sld - second/sub level domain. The logic must be extendable to third and fourth level domains as well in case these are managed by the regsitry.

Example: 4y renew request for example.pri.ee domain. There is only 1y create price of 1€ under .ee zone in the price list. The process to have the price for this example is following
Look for the price of 4y renew for pri.ee - 4y renew for pri.ee - 1y renew for pri.ee - 1y create for pri.ee - 4y renew for .ee - 4y create for .ee - 1y renew for .ee - 1y create for .ee (bingo). 1y create price for .ee is taken multiplied by 4 and the price for the example request is 4€.

If a price to use is not found return error 2104 "Billing failure: price not found"

for short term registrations and renewals the base price should be 1m.
The current process does not support odd periods longer than one year ie 18m

admin: /admin/settings

• new options to specify paid operations. In .ee case these are create and renew. This option must support making any epp transform operation payable (create, renew, transfer, update, delete)
• new operation to specify periods allowed for create and renew operations. In .ee case currently the value should be: 3m, 6m, 9m, 1y, 2y, 3y, 4y, 5y, 6y, 7y, 8y, 9y, 10y
• nice to have feature: option to enable/disable the hierarchy logic for price calculation. If disabled the exact price list entry is required for each zone, operation and period.

/admin/prices

• validate option - operation that check if system is able to find a price for any zone, operation and period that is specified as paid in /admin/settings

[artur-intech]

Check "operation_category" conversion

[artur-intech]

How that validation should look like? Do you want a calendar or some list which will show prices that will expire soon?

[artur-intech]

Also, can you define sortable fields that we really need? Given the changes where multiple zones/operations/periods allowed, it makes no sense to sort.

Perhaps you want to add period range filter?

[artur-intech]

Prod queries:

select count(*) from prices where valid_from is null; # 0
select count(*) from prices where duration is null; # 0

[vohmar]

• the primary reason for the validation is to make sure that all the active zones have all the paid operations have prices set. The key here is the date - you check if there is a valid date entry for zones and operations for now or any other specific date. So the validation should first of all enable to check that which operations do not have prices set for 1st of January 2018. sot he result could be all set or the list of zones+operations that are missing price list entry for specified date. As a bonus this feature might also display all the prices set for specified date enabling to check that campaign prices are correctly set for example.
• the validation report must be single row per every zone, operation, period. So we are talking about 130 rows of data currently - 5 zones, 2 operations, 13 periods
• date range does not make sense for validation - you check the situation on a specific moment or date

[artur-intech]

<domain><period>0</period></domain>