slapos_subscription_request: skeleton of Subscription Change Request

slapos_subscription_request: init reference

slapos_subscription_request: copy property sheets from Subscription Request

slapos_erp5: Subscription Change Request roles

slapos_erp5: business application on Subscription Change Request Module

slapos_subscription_request: add workflow on Subscription Change Request

slapos_erp5: sale only need Auditor role

slapos_subscription_request: add alarm to handle submitted Subscription Change Request

slapos_subscription_request: up

slapos_subscription_request: detect unexpected changes

slapos_subscription_request: unauthorized call

slapos_erp5: wip subscription change request scenario

slapos_subscription_request: archive previous open sale order

slapos_accounting: allow to archive Open Sale Order, even if the item is still valid

slapos_subscription_request: WIP: stop using discount resource, and reduce the quantity of the consumed software product / service

slapos_subscription_request: create discount with a standalone script

slapos_subscription_request: typo

slapos_subscription_request: create discount when closing the open sale order

slapos_subscription_request: comment

slapos_subscription_request: improve titles

slapos_accounting: expand Subscription Change Request discount SPL

slapos_subscription_request: keep subscription request causality link

slapos_subscription_request: fixup project migration

slapos_erp5: test Subscription Change Request local roles

slapos_subscription_request: fixup Subscription Change Request workflow chain

slapos_subscription_request: factorize to create Subscription Change Request

slapos_subscription_request: add one more assertion

slapos_erp5: test: reuse existing script

slapos_subscription_request: user script parameter to set the expected values

slapos_panel: new action to change the ownership of an hosting subscription

slapos_erp5: test: reuse script

slapos_erp5: test: use fixed date to check the movement quantity

slapos_erp5: test: complexify the calculation

slapos_subscription_request: add comment on the discount packing list

slapos_erp5: test: fixup

slapos_subscription_request: quantity precision is not related to the price currency

slapos_subscription_request: XXX did not find if category can have a precision

slapos_accounting: test: discount price calculation has been changed

See merge request nexedi/slapos.core!629

  No need to always set those properties, while no accounting is setup.

  Let the project introduce it if they rely on those payment modes.

   Use subscription_list to calculate Balance amount for the ledger, currency, section from the list. It keeps consistency with the Entity_createDepositPaymentTransaction implementation.

   For now we rely on Base_createExternalPaymentTransactionFromOutstandingAmountAndRedirect for pay subscriptions for customer organisation because it requires update security and review the procedure and how UI will handle it.

  So we invoke directly Entity_createDepositPaymentTransaction with the organisation's subscriptions.

   Use acquisition properly.

   Same as Sale Invoice Transaction to generate payments.

   Merge Deposit and Invoice payments under the same (or nearly similar) implementation.

  Reimplement Entity_addDeposity by creating deposit from a list of subscription

  Ensure will transfer deposit to the proper organisation/person, ledger
  and currency.

  Payment Transaction must preserve website context otherwise it will
  fail over redirections later on.

   It must lead to "Contact us" page. Allow us use accounting for other configurations, so it
   allow the user generate a payment and contact us to make the wire transfer or pay from
   some non-automated system.

   Since payzen/wechat depends on specific currency, so keep default implementation generic, so it allows the user get a contact us message, so it permits the system use wire transfer or non-automatic payments, to proceed with payment.

  whenever the tests need it.

  This should be set from the test or by the user while configure payzen.

   It is more accurate to include testing data via test (on setup), otherwise it can lead to enable undesired configurations and eventually include testing data in production.

   If required, use a separated bt5 for include specific testing data.

   Since it should handle multiple *_section.

   Display a blank page is disturbing in general, so at least show a loading bar with some message.

   The currency as parameter is useful for bootstrap region specific
    tests later on, and allow reuse this script to bootstrap dev environment
    in EUR or CNY to test payments.

   Entity is more accurate since it could be used on B2B context later.

  Make it reusable so that we can inspect the balance of the user for other purposes

slapos_accounting: Entity_getDepositBalanceAmount

  Remove non required code around the topic.

  Include checkInstanceAllocationWithDeposit on tests to checks the use case
    whenever the pay the deposit is required to allocate.

  Update tests to pay precise deposit, since a more accurate use case is
    check and pay a proper amount of deposit and check if the steps are
    working properly (ie.: Subscription request stays in submitted)