test.erp5.testUpgrader.py: update the bt5list in afterSetUp(). Otherwise the user has to invoke genbt5list manually before runnning the test. It was also confusing, because the same test would pass in the server but not locally

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.

Merge work of Ayush Tiwari (@tiwariayush) to support ERP5-side code
execution for Jupyter (= IPython) notebook:

---- 8< ----

Jupyter == IPython Notebook

Features:

1. Module - Data Notebook (To save notebook according to reference from jupyter frontend)
2. Execute python code which might/might not be remote.
3. Save local_variables for specific notebook, i.e, you can use the python
   objects which were created during code execution. After making a successful
   connection(from frontend) to specific notebook, the variables which were saved
   earlier are available while for execution.

Architecture:

- Code from Jupyter cell is being received as string by Base_executeJupyter.
- Code is executed in Base_runJupyter external method.
- Local variables saved via CMFActivity.
- Result as JSON is returned to frontend (contains mime_type of result string also).

Example Notebook:

    http://nbviewer.ipython.org/urls/lab.nexedi.com/nexedi/erp5/uploads/6778782d5753873583bd4843772cf502/Proof_of_concept_Notebook.ipynb
    https://lab.nexedi.com/nexedi/erp5/uploads/6778782d5753873583bd4843772cf502/Proof_of_concept_Notebook.ipynb

---- 8< ----

Current state is: erp5-data-notebook somehow works on server side, but is known
(see slapos!43) to have at least the following limitations:

- errors are not reported properly to users;
- state is not fully saved to ZODB.

the latter point means notebook works only if it is connected to Zope family
with only 1 zope process.

@Tyagov reviewed this work. I'm the person who does the merge.

Slapos part to integrate erp5-data-notebook bt5 and Jupyter frontend
will come in via slapos!43 .

/reviewed-by @Tyagov  (on !29 and on a lot of other places)

So that we can have enough permissions in subobjects of solving Solver Process.

Otherwise test will fail because the user is not indexed yet

test: update causality state explicitly because normal users have no write to modify in solving state.

Because solve() is now unrestecred method.

This reverts commit ab9e6e69.

they are mostly 'Modify portal content' permission.

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

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.

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

all documents must be

This is just to make property type validity constraint happy

This dialog can be used outside of the "creating a response context", so filtering the notification messages to only the response one is not always good.
Introduce a request key "notification_message_response_only" that will apply the filter if true.

This defines wether we check all documents in matching the query or only documents created since the last alarm run.
In other words, make bd3da719 an option which is now false by default.