Since distributor is used, tests need adaptation:

 * created default Test Node and Test Suite, required by
   Distributor.createTestResult
 * adapted _createTestResult to reuse created documents
 * adapted some tests in order to reuse created documents

Several changes to `Item_getTrackingList`.

My original goal was to fix a problem happening when users sort the listbox by `source_title` column. Because catalog understands it, it adds a join condition which would filter movements not "directly" having a source (ie. having a source by acquisition from parent). 

Then I realized this script was doing a lots of catalog queries that are done in a most efficient/safe way on the brain, so I switched to this.

Also add a few missing tests.

I did not add test for my original problem, because the real fix is that listbox should not declare `source_title` to be a sortable column, because this method does not support it.


/reviewed-on nexedi/erp5!469

rJS gadget uses text content as value

Keep compatibility.

Modules should have the business_application base category set in order to classify them. Normally, the code helper set this category on module creation (https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/bootstrap/erp5_core/SkinTemplateItem/portal_skins/erp5_core/ERP5Site_createModule.py#L15), but it is often forgotten to commit it (as it should be defined explicitely in template_portal_type_base_category_list's bt5 property.

This commit tries to fix it globally in all bt5s, using a script : https://lab.nexedi.com/snippets/259. I have tried to respect file modes, file encoding, alphabetical ordering, and "\No newline at end of file" issue in order to not generate useless diffs when other people will commit on these files later.

@jerome , @vpelletier , @kazuhiko , @seb : could you have a check to the file formats to tell me if anything is wrong ? 


/reviewed-on !465

All Tickets portal types don't use the same workflow variable (validation_state/simulation_state). By retrieving first the correct workflow variable, we can then deduce the correct getter to access to each object workflow's state

/reviewed-on nexedi/erp5!418

It is a common (CRM principally) use case to search for Organisations using official identifying unique codes, as the registration code or the VAT code.

There is currently no way in ERP5 to look for entities using these unique codes, as they are not-generic enough to be indexed. For the same reason, creating a new table(s) to index Entities' identifiers may give something too blured to reach a consensus on. In my opinion fulltext search is a good solution for this case, and it shouldn't create compability issues for current projects. 

If it is thought necessary, I can also add the Social Security Code (for Organisations/Persons) in the searchable text properties, but it is a more complicated topic as it isn't a public information.

@nexedi 's project managers, what are your thoughts on it ?

/reviewed-on nexedi/erp5!463

/reviewed-on nexedi/erp5!473

/reviewed-on nexedi/erp5!472

And update old header to use it in jabber client

Rename action from "object_*_jio" to "object_jio_*" to be consistent and before it spreads

/reviewed-on !440

We might need to consider this change globally for all fields later.

If we leave sort_column empty, catalog/listbox will incorrectly guess
the sortable columns.

There is a related key for source_title that does not work here (because
this method selects movements, and movements categories are not indexed,
so lines which acquire source from their parent are filtered out)

Some listboxs using it were using default_sort to inject this
automatically, but it's better to do this directly in the script, this
way the script can be reused.

I'm not really convinced the script should honor sort_on parameter
received in kw, because misconfigured listbox can inject some parameters
that would cause more table to be joined.

this is still unfinished work

no need to do catalog here

this way callers does not have to lookup explanation by catalog themselves

This uses caching (which will probably never be hit here), prevent
problems if delivery_uid is null (which should not happen) but it's
consistent with other brain methods.