Fixes [#20161227-D1FA4](https://nexedi.erp5.net/bug_module/20161227-D1FA4)

Also modernize code by using set() and not using
ERP5Site_getAuthenticatedMemberPersonValue

it should be displayed if user can add a credential update

fix NameError introduced in a97402d3

Tests should not depend on the state left by the previous test run.

This was achieved by:

* use a different preference in each method to reset the state of preferences configuration.
* clear cache after setting preferences, so that the new preference setting is used
* change password after setting the max preferred password lifetime duration, otherwise password event are not created and password is not detected as expired.
* rename test methods not to include number, we should not force test ordering, since we want tests to be independant.
* Also add one case of password actually expired

Before this change, password event were only recorded when
preferred_number_of_last_password_to_check was set.

We also need to record password events to check for password lifetime,
so also record password events when preferred_max_lifetime_duration is
is set (also when set to 0h, but this only makes sense in tests).

testAuthenticationPolicy was not showing this problem, because tests were not properly
isolated and test_02_PasswordHistory was enabling
preferred_number_of_last_password_to_check for all other tests.

https://www.erp5.com/bt5-Module.Creation.Guidelines

> Rule: In view mode, simulation_state or validation_state fields should be in the bottom of “right” group

according to https://www.erp5.com/bt5-Module.Creation.Guidelines *3.3 Listbox rules*

> If a listbox is configured so that only objects from one portal type can be displayed, then the title of the listbox should be set to the plural of the given portal type title (ex : Sale Orders should be the title of a listbox displaying "Sale Order" objects).

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