nexedi / erp5

Fully rewrite portal_simulation.mergeDeliveryList to use builders to reconstruct new
merged delivery.

Add parameter "merge_delivery" to builder. This parameter is used when
merge should be done in such a way that movement group at delivery
level are ignored

Before, when solving a solver, parsing sub objects of solver_process was done directly synchronously
in solver_workflow. And we had the case where you have parallel transactions solving a solver,
each of theses transactions see remaining solver not in solved state, but once all transaction are
finished, all solver are solved. This could lead to the case where solver_process is never moved
to succeeded. Instead of using serialize (which may lead to conflicts), just use activities in queue
with a serialization tag.

When document has pending activities, we refuse changing ID ( because there might be pending `updateRelatedContent` activities if I remember correctly ), but it's done in a way that breaks the "atomic" aspect of the transaction a bit, because we

As a result, this happens sometimes that not all properties user changed are modified. In the example below, the change to *Include Documents in Site Map* is not saved (and also change to *ID*):

![erp5-sorryPendingActivitiesSavePartially](/uploads/ff4bfd6ad0e8a42ba3684cccdc450e21/erp5-sorryPendingActivitiesSavePartially.gif)

( screencast of editing a document to change ids and several other
properties - after clicking save, we can see that changing id is refused
because there is pending activities. Other properties that where changes
at the same times are not all modified, which breaks the
transactionality we can usally expect when editing documents in ERP5 )

The changed here is to use a field validator that refused editing when there are pending activities, so that user gets a:

![erp5-pending-activiities](/uploads/bfe825560bdee34f0443e8e36884f21c/erp5-pending-activiities.png)

( screenshot of the change: now edition is rejected )

and the result is either all changes are applied or no change is applied at all.

This is done by:
 * introducing a new `my_view_mode_id` field in `erp5_core`'s `Base_viewFieldLibrary`
 * using this field as proxy field of all editable `my_id` fields. Maybe I forgot some business templates, I changed only the most common ones. I intentionally did not change all fields of `erp5_ui_test` because I think they are used to compare speed of proxy fields vs traditional fields.

0352f50fd543fda2712bb8ca93d8a8814f975a26 introduces a Zelenium test exercising this new behavior.

/reviewed-on !504

Conflicts:
	product/ERP5/bootstrap/erp5_core/SkinTemplateItem/portal_skins/erp5_core/Base_viewFieldLibrary.xml

to fit to the new behavior related to these changes :
- 2c74e408
- a40266af

  1. 'Solve Divergences' action:
     => Display Delivery_viewSolveDivergenceDialog.listbox:
        -> Delivery_getSolverDecisionList
           -> Delivery_getSolverProcess => create Solver Process in 'draft' state and build Solver Decisions.
  2. Clicking 'Update' button updates Solver Decisions.
  3. Click 'Solve Divergences' button after either 'Adopt Prevision' or 'Accept Decision'.
     => SolverProcess.solve():
        Solver Process transit to 'solving' state and 'solve' Activity is created.

Before this Activity is executed, user can still select 'Solve Divergences'
action and this will create another 'Solver Process' as the current one is not
in 'draft' state anymore. Moreover, another user can still 'Adopt Prevision'
(while the first user selected 'Accept Decision') and this will be actually be
applied despite the first user choice.

Instead, create Solver Process when transiting to 'diverged' state and do not
display 'Solve Divergences' button nor allow access to 'Solve Divergences
Dialog' (Delivery_viewSolveDivergenceDialog) if there is a Solver Process in
'solving' state.

…me as legacy Simulation Dialog).

This fixes the following Site Error when there is no Divergence to solve:
  AttributeError: 'NoneType' object has no attribute 'SolverProcess_getSolverDecisionList'

This may happen if user selects 'Solve Divergence' Action and solve
Divergences, then immediately goes back and selects again this action
whereas there is actually no Divergence to solve.

…b Pages, Web Scripts etc. separate to xml

Followup of: "simulation: improve equivalence testers explanations messages".

With latest simulation, the explanation given to user when solving a
divergence was not good enough :
- Property ids were displayed without possibility to display
  business word (like displaying 'stop_date' instead of
  'Delivery Date'
- Some message was displayed in the solve divergence dialog whatever
  was the equivalence tester behind. Therefore, customizations of
  messages made a equivalence tester level were not displayed to user

Therefore, following was done:
- in solve divergence dialog, include the message generated by the
  equivalence tester
- use tested_property_title to allow using business words to describe
  properties having divergence
- most equivalence testers are written in a way to evaluate divergence
  on a single property. To have better UI configuration of such equivalence
  testers, change tested_property and tested_property_title properties
  type from "lines" to "string". This required to add some backward
  compatible code.
- use Variation Divergence Tester to show a case of an equivalence
  tester using different properties. For this, add a property sheet
  dedicated to multi properties equivalence testers
- update propertysheets to allow translating tested_property_title

Solve divergence dialog was raising unauthorized error when new solver process was created
by this script (when called with someone who was not manager). Therefore use proxy role and
protect call with "View" permission. View is used instead of modify portal content since we could
imagine cases where user might need to solve divergence even though is has no right to modify
delivery.

1. On Tab1, from PurchaseSupply_view, click on 'Purchase Supply Lines':
   Base_viewListMode??proxy_form_id=PurchaseSupply_view&proxy_field_id=listbox

   This Python Script initialise 'list_mode_proxy_selection' with the
   above 2 GET parameters and then displays PurchaseSupply_view.listbox
   indirectly but current Form is Base_viewListModeRenderer.

2. On Tab2, from SaleSupply_view, click on 'Sale Supply Lines':
   Base_viewListMode?proxy_form_id=SaleSupply_view&proxy_field_id=listbox

   This Python Script initialise 'list_mode_proxy_selection' with the
   above 2 GET parameters and then displays SaleSupply_view.listbox
   indirectly but current Form is Base_viewListModeRenderer.

3. On Tab1, filter Purchase Supply Lines.

   As proxy_form_id and proxy_field_id are not given, then
   Base_viewListModeRender fallbacks on 'list_mode_proxy_selection'
   values to find out the Form ID to be called and wrongly display
   SaleSupply_view.listbox (2.).

Remove broken concept of Mapping Properties that was used on legacy
simulation. We do not want to use this concept any more, any mapping
should be done by rule themself. Removing mapping properties leads
to more generic concepts and much simpler code.

With legacy simulation, in case of returned sale packing list
(in case we want to invoice in same sale invoice usual sale packing
list and returned sale packing list) :
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, having mapped_property mapping
           source to destination and vice versa)
      -> SM (source/A, destination/B) builders and solvers
         where doing sm.getMappedProperty('source') which was equivalent
         to sm.getProperty('destination'), thus the mapping was done
         in live time

Now in such case, we should implement mapping directly at rule level,
and this should give:
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, reversing source and destination)
      -> SM (source/B, destination/A) here we directly have properties
         we wish, no need of hacks on builders and solvers

Do not handle solving issues in Workflow_statusModify, use directly script attached to the
dialog of solving divergence. Also, previous code was no longer working properly with latest
simulation

For some base categories like specialise, the order of categories is important.
list.sort implements a stable sort so we can use it here.

-Titlecase terms, uppercase abbreviations, avoid jargons, add titles to empty title forms....

All interactions and activity tags are reviewed to fix bugs like duplicated
root applied rules, and also reduces the amount of duplicated/useless work, e.g:
- Simulation trees are not expanded anymore when simulated objects are modified.
- 'expand' activities are merged (i.e. dropped) with any other 'expand' activity
  for an ancestor.
New implementation exposes new API that hides much complexity to the developper
about activity dependencies.

By default, expand() now automatically defers any work if the current
transaction takes too long time. This method also gains a parameter to
explicitely choose when to expand, which is often important in unit tests or
solvers. In particular, when postponing work, it takes care of setting proper
activity dependencies.
- If you have any code requiring to expand everything immediately, you'll have
  to replace 'expand()' by 'expand(expand_policy="immediate")'.
- On the contrary, you should replace any 'activate().expand()' by
  'expand(expand_policy="deferred")'.
expand() still accepts activity parameters for any extra needs.

In causality workflow, 'building' state is clarified and now means
« delivery may diverge but we can't know now ». A delivery remains in draft
as long as it does not contain any movement built from simulation.
After init/clone/builder/etc. scripts used to call 'startBuilding' &
'updateCausalityState': this calls must be removed since only
SimulatedDeliveryBuilder should take care of move to 'building' state and
workflows now triggers 'updateCausalityState'.

Disguised interactions have been unhardcoded and either deleted, or moved to
appropriate interaction workflows, which have been reorganized. Those
that triggers update of portal_workflow can be easily customized or disabled.

New API:
- updateSimulation() on deliveries and subscription items. It takes care of
  creating root applied rule, expanding and reindexing parts of simulation
  trees. It somehow replaces:
  - Delivery_updateSimulation
  - Delivery_updateAppliedRule
  - Delivery.applyToDeliveryRelatedMovement
  - Delivery.updateAppliedRule
  - Delivery.expand
  - Delivery.expandRuleRelatedToMovement
  - SubscriptionItem.expand
  - SubscriptionItem.updateAppliedRule
- Delivery.localBuild() is the new way to do local building and replaces
  Delivery_expandAndBuild. Private method Delivery._localBuild replaces
  Delivery_buildOnComposedDocument.
- Simulation Movements that are being built by a builder are reindexed with
  the following tag: 'built:<delivery_path>'. Any after_path_and_method_id
  dependency against 'related_simulation_movement_path_list' and reindexing
  methods should be replaced by this after_tag.

After builder scripts used to confirm the delivery in a separate activity,
which was useless.

It is required anyway to install it in order to respect BT dependencies.

…hey should not be used as they are in real applications.

… to update the dialog first.

The report tree is used really often, so just reuse Applied Rule listbox's
configuration.

Add view and property-sheet for Specialise Divergence Tester so that only specialise links of specific portal types can be divergence tested (or, alternatively excluded from divergence testing).

Use the accessors above to restrict which specialise links are selected for testing on the movement by the Specialise Divergence Tester.