This was broken since the use of user_id on Person.
Also, add a test.

Without this change, "source/a/b" in non-strict mode indexes:
  (document.uid, source.uid, b.uid, 1)
  (document.uid, source.uid, a.uid, 0)
  (document.uid, source.uid, source.uid, 0)
This last line does not contain anything which cannot be found by looking
at the base category uid column, so it is wasting disk (and index) space,
costing performance.
But keep indexing a Base Category document if is it not the base category
for considered relation. It is not clear whether stopping indexation at the
first encountered Base Category document is intentional, or if recursion
should only stop when reaching the base category of considered relation.
With this change, "source/a/b" in non-strict mode indexes:
  (document.uid, source.uid, b.uid, 1)
  (document.uid, source.uid, a.uid, 0)
removing the redundancy.

It is overkill, and is likely slower than just passing the needed
values straight to catalog.
Also, rely on duck-typing instad of portal-type-testing.
Also, drop unused "spec" and "filter" arguments.
Also, expose strict{,_membership} used arguments, simplifying code.
Keep catchall **kw for compatibility.

erp5_travel_expense: Add transactions view on Expense Validation, Fix/Update  transaction generation

erp5_travel_expense: avoid undefined value

erp5_travel_expense: link related to Travel Request instead of record

erp5_travel_expense: can use listbox to search related mission in expense record

This was only used by listbox.
As most fields now render themself as 'p' tag in non editable mode, they are compatible with non editable listboxes to be rendered inside an 'a' tag.

Flush activities before we remove the permission to view document

In preference fields, do not fallback to displaying the globally preferred value when it's not defined on that preference

Some preferences fields have a TALES for `default` that displays the preferred value if the value if not defined locally, something like `python: context.getPreferredX() or preferences.getPreferredX()` .

I believe it is a bad idea, we should just display the value defined on the document like on every other fields.

Git log tells that over their lifetime, these fields have been changed by @tc @jm @kazuhiko @romain @yusei @aurel  so please tell me if there was a valid reason for using this pattern that I misunderstood.


/reviewed-on !217

Only display the value defined on the current preference, not need to
display the preferred value if not thing is defined on the current
preference.