Now, instead of a web page object the demo integration of PivotTableJs inside
ERP5 is a Page Template object.

pivottablejs is a very useful pivot table implementation in Javascript that
alllows the user to create his own tables and charts. And also they had examples
of integration with Pandas.DataFrame objects and Jupyter. So this is highly
based on that.

**ATTENTION**: this is an experimental integration and does not follow the ERP5
Javascript standards. It will be refactored in the future to use RenderJS and
JIO.

The integration generates an HTML page template which starts the pivot table and
have a placeholder for the data, that will be later replaced with a Data Frame
data as CSV. After this replacement the page is stored in the memcached server
and then served from there, through a Script (Python) object, inside an HTML
iframe. The iframe is necessary because a lot of Javascript libraries that are
not included in the Jupyter web page are loaded.

A web page with id "PivotTableJs_getMovementHistoryList" was created to demo
how pivottablejs can be integrated within ERP5, either using AJAX or not.

In the process of this integration a simple external method to render
iPython's display classes (Images, Video, Youtube, IFrame, etc) was created. It
will be refactored and polished along with the kernel itself in the future.

Variations and industrial phases where not displayed at all

Avoid the need to go through planned state before cancelling

@kirr, @Tyagov and @tatuya, please review.

Now the ERP5 Jupyter kernel automatically renders errors that happens in the
user-side code. Errors are captured during the AST tree creation (to be able to
detect syntax errors) and at execution time. The current transaction is
automatically aborted on error detection.

/reviewed-on nexedi/erp5!85

/reviewed-on nexedi/erp5!107

testXHTML: Accept non proxy field, because for some reason the developer probably have a good reason to not proxify it

Former version looked for a matching predicate on caching policy and a Enable304
property set to true. No we stop on first predicate, thus disabling 304 answer
when enable 304 is not selected

When running this alarm by hand, we do not want to wait.

the .selected is too general and was applied to selected action tab in erp5_xhtml_style ui

This was early designed replaced by Individual (Product|Service) Variation

This conflicts with category accessors generated from variation base
category

  The orginal method fail to check test_suite_title

By default, Base._edit first tests each property with getProperty, not to
modify the object when values don't change. Here, getProperty costs a lot
(in particular for categories) and rarely/never avoids the use of setters.

So here, the main gain is to do something like _edit(force_update=1).
As an additional small optimization, we directly use _setProperty instead of
_edit. We also stop copying int_index from the Amount Generator Line because
it's not useful enough:
- float_index may be used instead
- or dependency-based sorting is enough
- as a last resort, properties can be fetched directly from the causality
  value, or dynamically with asPredicate and mapped_value_property_list

We could go further by changing the API to not cast the result into tuples.

fixup! AccountingTransactionModule_getAccountingTransactionList: Workaround poor column mapping for reference filtering.

Use a single query for count and stat methods, caching the result in request
(for lack of a better idea).
Also, stop defining editable columns, as listbox auto-detects such fields
anyway.

AccountingTransactionModule_getAccountingTransactionList: Workaround poor column mapping for reference filtering.

node_category adds a join with catalog which tends to be preferred by query
optimiser over the agrgegate relation (because there are fewer accounts than
there are aggregared documents), which makes displaying a payment group
proportional to the number of payments on the accoutns instead of
proportional to current group's related aggregate list.
Also, drop parent_portal_type condition, as payment lines aggregated to a
group should be children of a Payment Transaction (and it saves one more
join - although much less costly than the node_category one).
Also, make aggregate relation condition strict (there should be no group
sub-objects from which we would want to get related aggregates).

This allows to have a nice default behavior for isDeletable without
the need to bother which arguments we can pass.

Also, make isDeletable of simulation movement supporting keyword arguments
to avoid failures when generic action checking isDeletable is called

The criterion is on indexation_timestamp, not creation date

business process could be acquired from parent, here we only want to select a transformation

mrp: consumption view on production orders, use getAggregatedAmountList and avoid displaying unused variation

Previous code was looking to transformation and checking object inside, but now we have
getAggregatedAmountList which is able to greatly do this job.

Also, do not show stock of variations we are not consuming, it could be very disturbing.

Also, remove orginal _getOmitQuery which was dead code, and merge
_buildOmitQuery into its only remaining caller.
Also, factorise two pieces of code generating omit queries.

- Correctly ignore parent_portal_type condition when all possible
  portal types are listed.
  This typically saves one stock-catalog join.
- Expand node_category_uid into lists of node_uids.
  This saves one very costly stock-catalog join, as nodes member of given
  category should typically be the minority, inciting MySQL query optimiser
  to use the index materialising this join, preventing use of actual stock
  indexes.
  As there should be few nodes involved in accounting reports, listing
  them all and passing them to queries should not matter much.

Also, add support for src__ parameter.
Also, assorted coding style improvements, changes and code factorisation.

Also, simplify code a bit while reading it.

Fixes a bug when select_list is present in related_key_dict_passthrough but
group_by_list is not.
Also, reduce the number of code paths.

Also, reduces dependencies on zpt_* skin folders.