SolverProcess may not be 'solved' when there are several 'solve()' Activities executed in parallel (#KMS-1126).

  1. Two POLs diverge.
     => Solver Process is created ('draft').
  2. User 'Accept Decision' (Accept Solver) on all of them:
     1) Two Accept Solvers are created in the Solver Process, one per divergence.
     2) SolverProcess.solve() is called, on each Accept Solver:
        1/ AcceptSolver.startSolving() ()
           => Through solver_workflow 'Script (after)': SolverProcess.startSolving()
              => Solver Process is in 'solving' state.
        2/ AcceptSolver.activate().solve()
           => One solve() Activity per Accept Solver.
              => AcceptSolver.succeed()
                 => Through solver_workflow 'Script (after)': SolverProcess.succeed()

The last step, 'SolverProcess.succeed()', will only be executed if and only if
all the other Accept Solver of the Solver Process are in 'solved' state. However,
if both Activities are executed in parallel, each Activity does not see the result
of the other, and thus the other Accept Solver is still in 'solving' state. At
the end the Solver Process may stay in 'solving' state.

Thus try to update solver process workflow state after target solver finished its job
by activity. Also try to update solver process workflow state when a new divergence occurs
and if solver process is still in solving state.

Revert "SolverProcess may not be 'solved' when there are several 'solve()' Activities executed in parallel (#KMS-1126)."

The commit did not solve the problem. solver_process_workflow is needed to set appropriate permissions to Solver Process.

This reverts commit 509b2ca4.

SolverProcess may not be 'solved' when there are several 'solve()' Activities executed in parallel (#KMS-1126).

  1. Two POLs diverge.
     => Solver Process is created ('draft').
  2. User 'Accept Decision' (Accept Solver) on all of them:
     1) Two Accept Solvers are created in the Solver Process, one per divergence.
     2) SolverProcess.solve() is called, on each Accept Solver:
        1/ AcceptSolver.startSolving() ()
           => Through solver_workflow 'Script (after)': SolverProcess.startSolving()
              => Solver Process is in 'solving' state.
        2/ AcceptSolver.activate().solve()
           => One solve() Activity per Accept Solver.
              => AcceptSolver.succeed()
                 => Through solver_workflow 'Script (after)': SolverProcess.succeed()

The last step, 'SolverProcess.succeed()', will only be executed if and only if
all the other Accept Solver of the Solver Process are in 'solved' state. However,
if both Activities are executed in parallel, each Activity does not see the result
of the other, and thus the other Accept Solver is still in 'solving' state. At
the end the Solver Process may stay in 'solving' state.

Considering that transitions of solver_process_workflow are *only* done through
solver_workflow and thus depend on the states of its '* Solver' states, it's better
to just remove solver_process_workflow to avoid concurrency problems and also because
it's not really used anyway.

  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.

zope.{interface,component} implement Interfaces through __implements__,
__implemented__ (both implementedBy instances) and __provides__ (ClassProvides
instance) attributes set on the class itself through implementedByFallback
(zope.interface.declarations).

However, this implementation creates circular references by referencing the
class itself and thus erp5.* classes (and all its Accessors instances) were
never GC even after a reset.

When running testXHTML and installing the Unit Tests bt5s:
  * After 10 resets:  21MB leak (~  7% of Zope process USS).
  * After 20 resets:  70MB leak (~ 18% of Zope process USS).
  * After 28 resets: 122MB leak (~ 26% of Zope process USS).

If it is the case *and* the action script does not redirect, the password will be
in user's browser history.
There can be two different reasons to not redirect:
- not following the API (ie, intentionally not redirecting)
- letting an exception reach ZPublisher
Also, if the non-redirection causes an HTML page to be rendered, resources
loaded by that page will have a referrer containing the password, leaking it
to potentially foreign servers.

Before fixing this bug, 'listbox_previousPage:method' input button was
submitted but with no value (''). However, this was not handled by the
backward-compatibility code and thus next/previous page buttons would
not work properly if erp5_xhtml_style is not updated.

ListBox: Navigation methods should not be created when rendering ListBox (#20161014-741678).

These methods were generated when rendering the ListBox and with the id
of the ListBox in their name. However, a customer reported the following
problem on Accounting Periods ListBox:

  1. Display Accounting Period ListBox on ZEO-1.
       => The ListBox will be rendered and 'listbox_period_list_*' methods will be generated on ZEO-1.
  2.  Click on 'Next Page' button and the user is redirect to ZEO-2 where the ListBox has never been generated.
       => The method does not exist yet and thus a 404 error is raised.

Instead of having one method per ListBox ID, only one is now created (eg
listbox_setPage() for SelectionTool.setPage()) at Zope startup and the
ListBox ID previously defined in the method name is now defined in the
value attributes of the buttons.

Pattern: SIT_1 => RSPL => SIT_1.

Also, this reduces the complexity by not checking objects twice.

Functional Tests: Migration to PDF.js in recent Firefox clears preference to save automatically PDF files to the disk.

/reviewed-on nexedi/erp5!69
Conflicts:
	product/ERP5/bootstrap/erp5_core/DocumentTemplateItem/portal_components/document.erp5.ScriptConstraint.py

Portal Type as Classes: Fix memory leak: Workflow method list was never emptied and thus reset Workflow Methods were never GC.

A bug fix of erp5_core/Folder_delete

See merge request !65
Conflicts:
	product/ERP5/tests/testERP5Core.py

Submit action must be disabled while solver is being updated. End user sometimes click too fast that submit action fails due to lack of 'my_tested_property_list'.

Conflicts:
	bt5/erp5_simulation_fast_input/SkinTemplateItem/portal_skins/erp5_simulation_fast_input/gadget_solve_divergence_dialog.js.xml

Selection.__call__() calls getParams() and as getParams() can be called
directly from many places (such as SelectionTool.getSelectionParamsFor()),
it makes more sense to have it here.

This reverts commit b78933f1.

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.).

Rather than the acquired Property.

Instead, define default values if not set (same as previously hardcoded
ones) and get the value(s) define on the Tester instead as we may want
to check only variation_category_list and not variation_property_dict
for example...

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

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

erp5_simulation: Display Divergence dialog even if there is nothing to solve (same 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.

Selection.__call__() calls getParams() and as getParams() can be called
directly from many places (such as SelectionTool.getSelectionParamsFor()),
it makes more sense to have it here.

This reverts commit 5fac6732:

  When the Divergence is solved and user goes back to the main view, the
  button is visible but when user clicks ont it and if Activities have
  been processed in the meantime, this will raise an AttributeError
  because newSolverProcess returns None and there is nothing to display.

  This happens even when adding Delivery_isDivergent() as a guard
  because it still returns True if Activities are running in background.

count_method was removed from Base_viewFieldLibrary/my_view_mode_module_listbox
used by Resource Module ListBox (76282344) for performance issues when
countFolder is called with a Module containing > ~50k documents but this
should not be relevant for Resource Modules.

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

simulation: MultiPropertyEquivalenceTester was missing from Variation Divergence Tester Portal Type.

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

With Legacy Simulation, when Adopting Prevision, the Builder was called
again and the value was set either at Delivery, Line or Cell level
according to the Movement Group definition. Implement the same kind of
behavior for New Simulation.

With ZODB Components, getBusinessTemplateList() only returns the test
bt5 (as given on the command line, such as BT_TITLE:testFoo) and later
it resolves dependencies.

So filtering bt5 to be updated should be done as late as possible...

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

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

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

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

This makes more sense as all Tester inherits from EquivalenceTesterMixin,
even project-specific EquivalenceTester classes.

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

* 2a188797: "simulation: improve equivalence testers explanations messages"
* df04eb69: "Implement delivery.getQuantity() == 0."

Default values for tested_property and tested_property_title must not
be of type tuple any more since theses properties are no longer multi
valued