Makes future table structure changes easier.

instead of class gadget field

- Respect run_only/remote_code_url_list if given.
- When page templates have errors, there may be no Zuite Results, in which case
  testFunctionalTestRunner waits forever, until it gets killed (after a few
  hours). It's easier to fix this issue by check PT at the beginning of
  testFunctionalTestRunner, instead of doing it in a separate test method.

The validation state "hidden" put a class "hidden" on the field. And then field was hidden.

8ba29de3

/reviewed-on !113

in order to avoid timing attacks

/reviewed-on nexedi/erp5!115

When changing listbox display mode (ex: from domain tree to flat list),
remove domain tree from selection, so filtering comming from domain tree
does not apply.
Requested-by: Thierry Brettnacher <tb@nexedi.com>

For other temporary objects, there may be interactions on edit(),
like Document_base_convertable_edit (document_conversion_interaction_workflow),
tested by test_02_VolatileCacheConversionOfTempObject (testOOoConversionCache).

  The parameter test_suite_title passed do not correspond exactly to test_suite_title present on ERP5 (as this test is not supposed to share the effort to run tests

erp5_web_jabber_client: Allow user to send multi-line messages

User can change between single-line and multi-line mode
using one button.

/reviewed-on nexedi/erp5!114

The set of resources correponding to a given (non-strict) use is generally
constant, while the number of documents having relations to these
resources will increase over a site's life.

The original query used 2 joins:
- catalog to category for document/resource relation
- category to category for resource/use relation

Given several tables joined together, MySQL query optimiser will try
to first execute a query on the table which will yield the fewest rows.

As a result of all the above, query optimiser would end up choosing to
first find which resources have a use relation to given uid, and only after
find which documents have a resource relation to these. Which means it
cannot use any index on the documents themselves, and only an index
on resource's use... Leading to extremely poor performance on large data
set when, for example, trying to list the few documents in a given state
which also have a resource of selected use.

Instead, lookup the list of resources per (non-strict) use when building
the domain tree, and put that pre-computed uid list as membership
criterion: catalog query is then only a single-join, whose execution is
trivial to plan.

User can change between single-line and multi-line mode
using one button.

The line added in commit e42b2816
is not valid XML.

1.8.3 is now required to use profiling.
It provides two important features:
- SQL query tracing (which queries were executed, how many times,
how long did they take to run)
- ZODB __setstate__ per-oid statistics

- contentValues(filter) is really slow
- portal should be explicitly retrieved before using one of its methods

* for bulk substitution, re.sub is much faster than join of dict
  lookup result per byte.

Check that if only the code of a PythonScript (_body) is different,
it will be identified as modified.

now it is like "<title>public - Revions 12345: /path</title>".

For scheduled workflow transition. Use in your workflow transition as:
%(content_url)s/Base_viewScheduleWorkflowActionDialog?workflow_action=%(transition_id)s&next_workflow_action=SOME_ACTION
(replacing SOME_ACTION with some appropriate value).

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