Now we have explicit ORDER BY in the outer query so that we no longer need
to disable derived_merge optimizer.
c.f. https://bugs.launchpad.net/maria/+bug/985828

- group_by, group_by_expression -> group_by_list
- select_list, select_expression -> select_dict
- sort_on, sort_on_order, order_by_expression -> order_list

It is useful when use select_expression in inner query and use
group_by_expression or order_by_expression in outer query.

Revert "Add auto_extend_select_list argument in buildSQLQuery() and use alias in group_by_expression and order_by_expression."
Revert "Support group_by_list and order_by_list in WebSection_getDocumentValueList."
Revert "Support order_by_list in Resource_zGetMovementHistoryList."

No need to extend SQLCatalog parameter to support group_by_list and order_by_list in sub-queries.

It should be only for the case where no predicate criterion exists at all.

forge: do not link to Bug portal_type base categories that are already provided by Bug property_sheet

Added in keep path list, for compatibility

configurator: add an empty item in "Select your accounting plan" to make sure the user really selects

Catalog discards empty string, so this code path's only effect is causing
log activity.

Also move 'call_traceback' to 'More Columns'.

Now we have explicit ORDER BY in the outer query so that we no longer need
to disable derived_merge optimizer.
c.f. https://bugs.launchpad.net/maria/+bug/985828

Now you can sort results by full text search score, for example.

Add auto_extend_select_list argument in buildSQLQuery() and use alias in group_by_expression and order_by_expression.

If True, select_list is automatically extended to have columns used in
group_by_list and order_by_list. It is useful when use
select_expression in inner query and use group_by_expression or
order_by_expression in outer query.

Remove broken concept of Mapping Properties that was used on legacy
simulation. We do not want to use this concept any more, any mapping
should be done by rule themself. Removing mapping properties leads
to more generic concepts and much simpler code.

With legacy simulation, in case of returned sale packing list
(in case we want to invoice in same sale invoice usual sale packing
list and returned sale packing list) :
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, having mapped_property mapping
           source to destination and vice versa)
      -> SM (source/A, destination/B) builders and solvers
         where doing sm.getMappedProperty('source') which was equivalent
         to sm.getProperty('destination'), thus the mapping was done
         in live time

Now in such case, we should implement mapping directly at rule level,
and this should give:
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, reversing source and destination)
      -> SM (source/B, destination/A) here we directly have properties
         we wish, no need of hacks on builders and solvers

Remove broken concept of Mapping Properties that was used on legacy
simulation. We do not want to use this concept any more, any mapping
should be done by rule themself. Removing mapping properties leads
to more generic concepts and much simpler code.

With legacy simulation, in case of returned sale packing list
(in case we want to invoice in same sale invoice usual sale packing
list and returned sale packing list) :
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, having mapped_property mapping
           source to destination and vice versa)
      -> SM (source/A, destination/B) builders and solvers
         where doing sm.getMappedProperty('source') which was equivalent
         to sm.getProperty('destination'), thus the mapping was done
         in live time

Now in such case, we should implement mapping directly at rule level,
and this should give:
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, reversing source and destination)
      -> SM (source/B, destination/A) here we directly have properties
         we wish, no need of hacks on builders and solvers

Documents should inherit from XMLObject, which already overloads this
setter. As a result, this method is normally not used.
The problem is that it gets called when calling
  newTempBase(
    description='foo'
  )
which fails with:
  AttributeError: _setDescription
because _setProperty finds setDescription and tries to call it, instead
of setting description as a local property..

doesn't allow for offline use however

For example, this is required for multi-valued fields when an unknown value
is kept selected. Like elsewhere in ERP5, we don't want validation to raise
in this case.