We use to have consulting_configurator_sample_categories.ods and
standard_category.ods . standard_category.ods was more complete, it contained
standard_category.ods that was missing in
consulting_configurator_sample_categories.ods .

Now standard_category.ods no longer contain "standard" categories, these
categories are now installed by business template, so update
consulting_configurator_sample_categories.ods to the content of
standard_category.ods with all categories (ie. before remove them all in
5e0091a6 )

Use same spreadsheet for all consulting configurator tests

When there's only one quantity unit in the group a conversion group, one
definition is needed (this might be a bug).

Instead of using a spreadsheet for categories, use
erp5_configurator_standard_categories business template.

This business template also configures quantity unit definition in the
new way and no longer use obsolete way of setting quantity property on
quantity unit categories.

The included spreadsheet is still used, but all categories except group and
site have been removed, it now only contain group/my_group and site/main.

Some configurator profiles uses a spreadsheet to define categories
(consulting configurator), some use a business templates.

For the ones using business template, because the categories are not available
yet we have the values directly in the script.

from erp5_configurator_standard/standard_category.ods

from erp5_configurator_standard/standard_category.ods

trade/order trade/discount and trade/tax were only in
erp5_configurator_standard/standard_category.ods

This was not enabled, but it's should be OK already

See merge request !1170

product/ERP5SyncML/{Transport,Engine}/*.py were not considered.

this is supposed to work

pylint: Fix false positive error `No name 'ElementMaker' in module 'lxml.builder' (no-name-in-module)`.

W: Dangerous default value _MARKER (__builtin__.list) as argument (dangerous-default-value)

Since BusinessProcess.py was moved to portal_components, the cache in mixin/composition.py,
which was kept at the level of the zope process, was causing issue when portal_components
was reset : the classes kept in __class_cache would not get resetted, and later calls
to asComposedDocument would reuse them. In consequence, these classes would kept pointers
to objects in the old class BusinessProcess, causing bugs as these objects would have
been cleaned by the reset.

The first intuition was to remove this cache, unfortunately the reason of this introduction
(fixing a memory leak) is still valid nowadays, so I've decided to move this cache within
BusinessProcess, as it has the advantage of emptying it whenever portal_components is resetted.

For more information of the bug mentionned above, and the trials about removing the cache can
be found in the discussion of this MR :
!1032

ZODB Components: Migration dialog: Make sure that paths given in Working Copy (Preference) are valid.

Besides migrating Tools .py, this also moves the Tools themselves (portal_*):
 * Some of them were created before erp5_core being installed and this
   would not work anymore as their .py is now in erp5_core.
 * Some others were created after (via setupLastTool()) and this would not
   work neither as sub-objects may be installed by erp5_core.

Add them to template_keep_path_list to prevent them from being re-created like
ERP5Site.addERP5Tool() used to do (depend on 3180424b, 91393be2).

Not migrated:
  * AlarmTool: Needed for upgrader.
  * CategoryTool, IdTool: Bootstrap.
  * TemplateTool, TrashTool: Business Template installation.
  * SolverTool: TypeProvider.
  * ContributionTool: Imported by Products.ERP5.Document.Document used in many places, will be done later.
  * NotificationTool: Imported by ERP5.Document.EmailDocument, will be done later.

On re-create, all the sub-objects will be copied back and this should not happen
for Tools (example: portal_simulation currently created by addERP5Tool() but
later going to be migrated to ZODB Components and moved to bt5).

When force is selected, it should be updated regardless of user choice (for
example when `force_install` is set). But usually when installing a bt5, user
selects what should be updated (`object_to_update dict` later filtered to
`update_dict` (to not contain unselected objects)).

pylint: Fix false positive error `No name 'OOBTree' in module 'BTrees.OOBTree' (no-name-in-module)`.

We were using many different terms every for "username", this is an attempt to use a consistent term every where for login and a few other terms used for logging in and resetting password

See merge request nexedi/erp5!1164

As a follow up of nexedi/erp5!1158 , now that stock browser supports inventory conversion, the old converted inventory report is not longer needed.

The reason for removing instead of fixing is that this report was using approaches that have no equivalent in ERP5JS interface (select in the module and run a report based on selection, listbox domain tree), so we could repair it for old ui only, but we thought it would be better to remove it and improve stock browser further.

One reason this was broken is that it was using `SimulationTool.getAllInventory` which does not support brain attributes from `SimulationTool.getInventoryList`, so dynamic attributes like `node_title` were not displayed correctly. This adds a warning on `getAllInventory` docstring. This method has another user so we don't remove it.

See merge request nexedi/erp5!1162

Make stock browser a dialog where user can select the node category, for compatibility with ERP5JS

Introduce a preference to select the node category by default.

Allow to select quantity unit / metric type in the dialog to get converted inventories.

See merge request nexedi/erp5!1158

Uploaded the content of
https://github.com/nicolaskruchten/pivottable/tree/v2.23.0/dist/
using web dav and ran Alarm_checkSkinCache

This version allow sorting and fixes an XSS vulnerability

Browsers (at least chrome) saves the textarea content and restore it
when going back or resurecting a closed tab, which prevents loosing
unsaved work.
This browser feature does not work in "rich" javascript
editors, but this trick of syncronizing the rich editor content to a
hidden textarea seem to makes it work.

This is an emergency commit to repair failing tests

use "Slideshow" for now. "Slide Show" would also be OK, the discussion
about what's the best term is still ongoing, this is an emergency commit
to repair tests.

We fixed login forms to use consistently "Username", some translation
did not have message for "Username", but only for "user name".
Add missing "Username" messages, with same translation as existing one
for "User name"

with erp5_credential it's a bit more than password reset, because
there's also a feature to recover the username for a given email, but
all this can be named "Recover your Account". That was the term already
used in ERP5JS

Use consistent term as in PreferenceTool_viewChangePasswordDialog. In
dialogs the field label show "what information is in the field" not
"what the user is supposed to do with this field"

Other login related dialogs ( PasswordTool_viewEmailPassword ,
ERP5Site_viewCredentialRecoveryLoginDialog ,
PasswordTool_viewResetPassword ) all use Username.

Login_view/my_reference uses "User Login", but that's maybe OK, because
the context is different and there's also "User Password" on the same
form.