also make it work for Image portal types

each view has both editable and view mode, they can be accessed and switched
Editable button bring to editable mode
View button select view instead of Tabs which is meaningless

/reviewed-on nexedi/erp5!108

About getSingleCategoryAcquiredMembershipList, getPhysicalPath is so slow that
that cache was useless.

/reviewed-on nexedi/erp5!103

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.