The new versions do not include any price informations.
It is needed to create new Trade Condition which inherite from those versions.

Update preference to use those latest trade conditions.

slapos_accounting: factorise code

slapos_wechat: use reference sale trade condition

slapos_erp5: check sale trade condition reference

sale trade condition are versionned.

Clarify trade condition title

Prices are defined on Supply Line inside Sale Trade Condition.

Drop prices from Subscription Condition.
Instead, link the Subscription Condition to a Sale Trade Condition.

Apply the Sale Trade Condition on the created Open Sale Order.

Stop duplicating properties from the Subscription Condition to the created Subscription Request.

Payment is managed by the 'payment' category, and not the language.

This allows to remove all '==zh' conditions.
Instead, use custom Sale Trade Condition.

slapos_accounting: rename script for hosting subscription

slapos_accounting: revert failure error

slapos_accounting: force open order line to have an Instance tree and a hosting subscription

slapos_accounting: hosting subscript will host the date info

slapos_accounting: set open order periodicity on the hosting subscription

slapos_accounting: typo

slapos_accounting: hosting subscription will contain the periodicity

slapos_accounting: create hosting subscription

slapos_accounting: fixup start/stop date confusion

slapos_accounting: fixup

slapos_cloud: add hosting subscription workflow

slapos_cloud: stop using Instance Tree as Subscription Item

slapos_accounting: move periodicity view on hosting subscription

slapos_erp5: open order line have 2 items now

slapos_cloud: open order line has 2 items now

slapos_accounting: simulation is expanded from Hosting Subscription

slapos_accounting: validate hosting subscription

slapos_accounting: check all aggregate value

slapos_accounting: revert aggregate tester

slapos_accounting: simulate from hosting subscription

slapos_accounting: constraint is on hosting subscription

slapos_accounting: interaction are on hosting subscription

slapos_subscription_request: periodicity is on hosting subscription

slapos_accounting: open order line has 2 aggregate

slapos_cloud: hosting subscription have a workflow again

slapos_cloud: add hosting subscription template

slapos_accounting: do not create open order if it was not allocated

slapos_accounting: script renamed

slapos_cloud: update HS_view

Base_acceptContractInvitation is an infinite loop

slapos_jio_ui_test: wait for content loaded to delete project

slapos_jio_ui_test: wait for page to be loaded

  Those files tend to be modified quite often, including on the sub projects.

See merge request nexedi/slapos.core!387

 The site and translation data is updated after the installation,
 causing the delta. For now we ignore it and we update translation
 later.

   The purpose of the restricted parameters were to keep hidden values which weren't part of the schema on the parameter form, for a simplified version of the form.

   Since the user can always edit the raw values (over XML) this feature is undesirable, since if produce inconsistent outcome.

   It is the duty of software release to produce a simplified version, with a restricted list of acceptable parameters.

  Drop non required new line (it will be added anyway).

See merge request nexedi/slapos.core!385

  The "bad" sample are examples that are miss used, but it should still works (as expected by the format).

  The first example are from the implementation of boolean using enum + strings.

   Boolean should be handled as boolean not as strings.
   Selection should include default value even if they are outside the enum list.

   Keep the xml_output as it is even if the form is Invalid, this allow the user force post (since it is the user decision).

   If the textarea is blank/empty, add the default xml (empty values) in place, otherwise the user cannot re-render the parameter form back.