Use the precache script to get the list of gadgets.
Ensure to also check the launcher gadget.

Report subgadget service error.

Replace it by domsugar.

This speed up gadget class generation (handlebars template parsing is
slow).

This attribute is only needed for the translateHTML method.
There is no reason for it to be kept in the final DOM HTML.

Add service worker precache script.

Add service worker precache script

renderJS now correctly handles relative URL.

This allow edit scripts or interactions to change the status message or
the status level using the same way as workflow scripts: script can set
the status text in request['portal_status_message'] and the status level
in request['portal_status_level'].

Note that part of this was already checked in accidentally in 97c40dcb

import from production

changed caused by : nexedi/erp5@9e530f6a

testBPMCore: update test for nexedi/erp5@9e530f6a

payment condition is added by
647142e5

Because we often want to manage those through simulation.

For consistency with all other default builders

index

we have a scriptable key for title_or_reference :
from Products.ZSQLCatalog.SQLCatalog import Query, ComplexQuery

query = ComplexQuery(
  Query(title=value),
  Query(reference=value),
  operator="OR")
return query

Add "planned" state to Purchase/Sale Packing Lists so that builders first build planned deliveries.
Then if there is no expected additional movement, the delivery is automatically moved to "confirmed".
This allows to support partial build that could come with global builders. Now builders will complete
only "planned" deliveries. This also solve the split of packing list when the same date was used,
the builder was updating current delivery. Now we can change packing list only in confirmed state
(not in planned state), therefore the builder will never add movement to the delivery the user is
changing.

This was adapted from seb commit to project repo. The difference is that here we do not confirm if
related movements belong to more then one root delivery value (packing list). This way we try to
handle the case of multiple split on the same date where the user first splits a packing list and
then splits again. In this case we want these splitted movements end up in the same packing list,
so the created packing list still has to be able to receive new movements, it is thus kept in
planned state. The user then hast to confirm this packing list manually.