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.

Also, factorise code.

This is fuxip for 1038d441

Quick way to isolate tests

getInstalledBusinessTemplate was returning "replaced" versions of a business
template beeing uninstalled.
Also add some missing tests for getInstalledBusinessTemplate

Likewise for positional REQUEST parameter.

Also, extract unwanted kw entries by just declaring them as separate
parameters.

It is not passed a value, so DTML walks acquisition path (and skins) on
each call (which do not pass from_expression).

This reverts commit 0fc02acc.

selection_report is actually a legal ZSQLCatalog parameter.
selection is not, but there are more instances of its usage, so cleanup
will be in a separate commit.

This way, it becomes pretty easy to add matrix functionnality to any portal
type TTW

The business template does not set ERP5 enough for proper indexation in
email table. Given the low popularity of this business template, mark its
test as expected failure with explanation.

https://git.erp5.org/gitweb/jio.git/blob/refs/tags/v3.3.0:/dist/jio-latest.js

local_roles is handled entirely inside ERP5Catalog, so to not tell
ZSQLCatalog about it - it can do nothing right with it anyway.
Also, get rid of abusive **kw use in this code path.
Also, actually pass sql_catalog_id to getAllowedRolesAndUsers.

This is at least needed for
  external_account_interaction_workflow/scripts/Career_start
as it filters by "email.url_string".

This parameter is handled nowhere in ERP5 and ends up passed to catalog,
which complains about it.