We should have done before committing 76ecef89
but doing it now with a dummy merge also works.

Unfortunately, this is not really useful for blame, because all lines are
rewritten, at least to remove the trailing '\n'.

Files that have already been modified in 'master' branch are excluded.

Desactivate DMS to speed up restrictedTraverse document retrieval and so, speed up jIO sync

/proposed-by @jerome

Use MIME encoded words also for names.
https://en.wikipedia.org/wiki/Email#Message_header

It would be surely better to have matrixbox having possibility to
define which widget we use to display matrix variation labels.

catalog/stock: avoid duplicate calls to getInventoriatedQuantity and use better naming for variables

The business template erp5_calendar had a customized version of z_catalog_stock_list
to have possibility to index a movement like it was several movements through method
asMovementList. This is particularly needed for group calendar assignments which needs
to insert as many movements as there is periods in a given time range.

So instead of keeping it as a duplicated z_catalog_stock_list, include in the generic
z_catalog_stock_list the generic concept of one movement indexed as several movements.

This should change nothing for existing usage of stock table, since asMovementList returns (self,)
for about all movements

also set _p_changed=True in deletePropertyTranslation().

Even if this is incorrect to allow grouping lines where mirror account does not match, we want to make it possible for sites where mirror account is not used consistently to group without having to migrate the data. So we make this possible by leaving them a chance to customize AccountingTransactionLine_getGroupingExtraParameterList to ignore mirror account.

Gadget fields from erp5_core are also cleaned up.

This fixes the case of gadget fields in listboxes.

Now 'extra' can be used to set a custom class on the gadget element.
Note that 'css_class' property has a different purpose: it sets a class
on the grand-parent div.

make it as similar as Foo_view in behavior point of view

1. go to an organisation
2. click on its listbox title
3. go back to the organisation
4. click on a person in the listbox
5. go back to the organisation - the listbox results changed because of polluted selection

It is not possible to use the one from xhtml_style yet, due to different relative url

Update xhtml_style version to the latest.

This is now based on getMovementHistoryList + grouping_date instead of
Base_zGetNotGroupedMovementList

Person.getTitle used to return first/last name properties when defined, as the title property was always dropped.

This fixes nexedi/erp5@2155dbf5

Please, review this: @Tyagov, @kirr and @tatuya. 

## Kernel improvements: 

* Automatically render last-returning objects as HTML through "processors" 
  - These so called "processors" are classes responsible for rendering certain objects as HTML depending on their type 
  - The user can add his own customized processors, either by editing the JupyterCompile extension itself or using the variable `_processor_list` in the code cells

## ERP5 Jupyter kernel integration with [PivotTableJs](https://github.com/nicolaskruchten/pivottable)

* Implemented as an external method that receives a Pandas.DataFrame as parameter, along with the url of the ERP5 instance (is there a way to detect this instead of hardcoding all the time?)
* Works through an IPython.lib.display.IFrame object, that is added to the result of the code cell. Inside this IFrame the pivot table will be rendered with data from the DataFrame
* The IFrame is stored/hosted in the (volatile, for now) memcached sever of the instance, using his own HTML representation as key and accessed through a Script (Python) object

## Notes

There's more detailed information about the implementation in the commit messages and a little bit more in comments inside the JupyterCompile extension, where the kernel lives.

The demo web page included in the bt5 will only work if the Wendelin software release is installed, as it depends partially on things from the ERP5 repository and part from things on the following merge request to Wendelin: nexedi/wendelin!10 . Should I move it there or keep it here?

~~I'm still refactoring to completely remove those global variables from the code. Will add the commit here ASAP.~~ 

Global variables completely removed!


/reviewed-on nexedi/erp5!63

This is the proper way to refer to the URL on which ERP5 is being served.