It seems that with ${here/portal_url} returns the ERP5 url , for example http://nohost/erp5 instead of

http://nohost/erp5/web_site_module/renderjs_runner/

Since a89afa43 (Formulator: Support disabled items in all ItemWidget subclasses., 2014-04-02) we can include disabled items in listfields.
This was used for example in erp5_crm to show the services with their hierarchy as disabled items and was useful to display the hierarchy.

In some fields, we don't want user to select "nodes" categories, but only select "leaves" categories (ie. select the most precise category).
This always had a problem when using "Indented title" as display method for categories, because the user can not see the actual hierarchy. This is about making it possible to display hierarchy of categories in this case where we select only leaves, so that it displays like this:

![screenshot of a category with disabled items for hierarchy](/uploads/0f3e8ef68ab6e2ec424e4e8d42fc5e2a/image.png)

This required to:

 - introduce a new category API, `disable_node`, which is semantically very close to `filter_node` except that instead of filtering out node categories that are kept with `None` as related URL. Symmetrically, we also introduce `disable_leave`
 - make `ParallelListField` support disabled items. Even if this was properly supported in underlying fields, some parts in `ParallelListField` did not differentiate between `None` and `''`.
 - modify several forms to use `disable_node` instead of `filter_node`

See merge request nexedi/erp5!1199

For PDM/Trade we use:
 - "Site" for node category
 - "Warehouse" for node
 - "Owner" for section category
 - "Owner" for section

For Invoicing/Accounting this does not change.

Also, since in PDM/Trade context we are sometimes only taking care of physical movements/quantities and not the ownership, make sure that:
 - "Site" is first in report dialogs
 - "Section Category" is not initialised from preference, so that reports show the quantities in a location regardless of the ownership

See merge request nexedi/erp5!1202

- add an empty item to the list, so that user have to choose something. The empty item was missing here:

![image](/uploads/5be3e9d5acf1233270516c7463dbfdd4/image.png)

If there's an empty item and we force user to choose, there will not be the problem that user can forget to select the good value and mistakenly generates for the Fifo because it's the first value.

- translate values

See merge request nexedi/erp5!1204

A few small fixes to form and page templates to allow their translations

Missing messages in french translation

See merge request nexedi/erp5!1201

See merge request nexedi/erp5!1198

See merge request !1197

See merge request nexedi/erp5!1196

Also, as OAuthTool class is only used as a Folder ({Google,Facebook}Connector) remove
{unused,unmaintained,unfinished} code:
  * Properties are statically set on portal_oauth directly with non-persistent classes
    define in OAuthTool.py. This prevents migration to ZODB Components as migrating
    OAuthTool.py to erp5_oauth would break upgrade: chicken & egg issue: we need these
    classes on importFile(portal_oauth.xml) (portal_templates.download()) but they are
    not available until the bt5 is installed....
  * Several properties are supposed to be secret but statically set in OAuthTool.py.
  * This code has never been used since its introduction 9 years ago.

Unlike trade and like accounting, for invoice we are using "Section Category"
term for section category, it's no longer about "who is the owner of this
stock" like in trade, but already "who is the entity" like in accounting

 - add an empty item to the list, so that user have to choose something
 - translate values

for consistency with other stock reports such as
Base_viewStockReportBySiteDialog

most trade and PDM report are about "what quantity of resources do we
have here", in most uses cases, we are not concerned about who is the
owner of these, so it's probably better to not select these by default.

This tab was probably useless, let's remove it.

This also make use consistent for all resource types, the filter_node was only
effective on service, now it won't be possible to select nodes on any resource.

So that user can see the hierarchy (especially when categories are configured
as indented items) but not select nodes

instead of the deprecated Resource_viewFieldLibrary

by using disable_node instead of filter_node, we can keep the hierarchy and
this is much more understandable when using indented titles for categories

It does not seem easily feasible to implement support at this level. If support
is needed, I guess the best would be to make a custom hash script that generate
the full category item list again, then it would know in which subfield list to
"dispatch" the None items.

value of None is diferent from '', '' is the empty value when nothing is
selected, but None is a disabled item

(Multi)ListField renders items with None as value as disabled option, but this
was not really supported in ParallelListField because ParallelListField treated
the same way the empty ('', '') item and a disabled item ("Disabled", None).

Adjust the conditions to differentiate the two cases.

This allow filtering category item lists so that user can only select nodes /
leaves in a way similar to filter_{node,leave} but instead of removing the
items, keep them with None as relative URL. This is something Formulator
understand, categories are displayed with disable attribute set on the select
option, which allows to visualize the category hierarchical structure, while
not allowing user to select {nodes,leaves}

When using SavedTestSuite, the first step is to make testnode run --save for
each instance, by running the test referenced in _saved_test_id class
attributes.

Because log files are defined only by the test name, this was causing the
multiple concurrent runUnitTest executions with --save to all log in the same
file. That file was also reused when actually running this test later.

Override getLogDirectoryPath to use a different folder, one per instance, when
doing the initial --save

These are simple report/exports, they work fine with ERP5JS

Since a long time python unittest provides good assertions and we don't need to
build out own.