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

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

… HTML or it fails to open such a large PDF. Thus, now PDF reader opens a PDF using URL. It is faster and stable.

/reviewed-on nexedi/erp5!468

[erp5_officejs_ui_test] Add officejs_setting_gadget to Drive App's sub_gadget in gadget_officejs_page_export.js.

It requires to include codemirror python syntax highlighting

[renderjs_ui] Create new public method `updateForm` rather than misusing `displayFormulatorValidationError`.

In commit 89a17f04, disabling password
verification when passing an empty password was a bad idea, since it
wasn't possible to check fully the login form itself. Some tests broke
because of this change.

There was also a stupid mistake: `pw_validate` could call itself
instead of the original function.

--zope option was removed: it was an alias to
--generated-members=REQUEST,acl_users,aq_parent
but we anyway disable E1101.

This is consistent with packing_list_workflow