this demonstrate another potential problem of carelessly using path portal_type/X/** to export portal type configuration

With portal_type of portal_type, when we export the portal type configuration as path portal_types/XXX/** then portal type "configuration items"  (roles, actions, etc) id is not stable. This may be workaround by not setting last_id, but this will still cause problem when updating I guess ...

We have to duplicate the same configuration ( actions, workflows) as Base Type

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.

[erp5_data_protection] Drop filename too, to prevent triggering guess mime type interaction workflow which run with user permission

erp5_officejs: No Default jIO  storage and Redirect to jio configurator if no storage is defined on jIO call

* do not repeat columns in more columns
* let listbox decide which columns are searchable / sortable
* add owner_title in more column
* add group more columns for all group calendar assignments columns ( I had to use the infamous isDelivery hack to make them searchable / sortable )

/reviewed-on nexedi/erp5!110

getLocalRolesGroupIdDict is supposed to return sorted & cast
allowed_roles_and_users value already.
Also, use "x in y" pattern over y.has_key(x) for readability.

Fix a misnamed local.
Use iteritems.
Move variables next to the loop they act on.
Rewrite comments to better reflect the intention when it is not obvious in
the implementation.
Move a loop-invariant out of loop ((user, role) not in optimized_role_set).
Do not use set.update on an iterable constructed just for the call, call
set.add on each item.

Global role computation is very expensive, don't do it when all we are
interested in is user existence.
Also, list all users having local roles in one call to reduce the effect
of per-call overhead.
This should improve indexation speed by a large fraction: pprofile
statistical run on and activity node busy reindexing objects shows:
- 57% of time spend generating (13%) and executing (44%) SQL
- 42% of time spent preparing object for indexation:
  - 29% in _getSecurityParameterList, all in getUserById
  - 12% in getCatalogVariablesFor (workflow variables to index)
So an improvement of close to 30% is expected.

Its parameter is a loop invariant, so avoid looking the same user up once
per local role.

Also cleanup existing documents

Sometimes, we need to generate amounts with and without aggregation.
With this new method, we avoid duplicate computation.

The purpose is to generate amounts only once and

multiplyQuantity() is dead code since
commit 74838d44

- In-browser jslint does not warn about it.
- It's like C/C++ and 'gcc -Wall' does not warn either.