Delayed workflow transition works with 3 states:
- initial state: where we are
- final state: where we want to go
- waiting state: where we wait for the right time to transition to final state
The main advantages of the waiting state are:
- prevents multiple transitions from being scheduled
- allows customising object security (ex: preventing unwanted edits)
- allows storing intended execution date in a transition comment

Do not require caller to cast between these types when they can all make
sense to appear in the same list.

in most cases, where ASCII-range characters are less than 80% of input
non-utf8 string, the result is same but we can reduce needless string
replacement calls. in rare case, for example wrongly iso-8859-1
encoded properties or PDF data, the result becomes different, i.e.
before: ASCII-range characters + escaped characters => after: base64
encoding, but the meaning is still same.

* stop using deprecated string functions.
* reduce lambda creation inside functions.
* move import statements outside of function.

* remove needless copy of sub objects that are already recursively
  copied by their top most object.
* remove needless manage_beforeDelete() calls when copying objects.

- Document_viewSVGEditor/my_data changes web illustration content type
- WebIllustration_viewSVGEditor/my_text_content does not change it

Installation of business template may change the encoding of a document to utf-8.
Nonetheless, export should preserve the original encoding.
This test creates a ZopePageTemplate with output_encoding of 'iso-8859-15'
and checks that while installed version becomes 'utf-8', when exported it
keeps the original one.

Only xml metadata should be exported in this case.
In the previous version the check of hasattr could pass
if attribute is defined as an attribute of the class and not of the instance,
causing also AttributeError later when the code tries to invoke delattr.

Also, restructure export. First try to delete property and then
export as separate file.

Test also added.

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