erp5_travel_request: Add missing Preference PropertySheet

erp5_travel_expense: Add mission Administration

erp5_travel_expense: Add missing category

erp5_travel_expense: Make Expense document publication customizable by script

erp5_travel_expense: Add mission jio_view action on Service

erp5_travel_expense: Also remove Title from expense view in app

erp5_travel_expense: Remove all form of titles

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 nexedi/erp5!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.

Instead of only testing the number of related documents and expecting them
to match without checking, do check what the found documents are.
In turn, drop now-redundant comments.
Also, check Category-in-Category case.