The changes from !1158 were not so good in ERP5JS, it was good to have the action here:

![stock browser dialog showing Stock as a view action](/uploads/0e9495858295016926da484b6c5fa68f/image.png)

and not under "Exports", because this is not an export, it's an interactive report.

Also, the "Stock" button is not easy to understand, this is not an action, so we use only an update button now:


![stock browser dialog with only an update action, no action](/uploads/71f40b3e2e951f3c95f7ff885dd91090/image.png)

Also, the action button in movement history was confusing, it's not a button where user have to click. It was like this, with a confusing button (but this button was sometimes useful, because with this button we can go back to stock browser):

![movement history before](/uploads/75450d7fbfe1f208ca17e14b22059b38/image.png)

Now it's like this, the button is not here, but since the action is now listed in Views, it's easy to go back to stock browser:

![movement history after](/uploads/d66d28f1fc66b69b84baba6d88574afc/image.png)

See merge request !1179

Since 5eb06085 (erp5_web_renderjs_ui: do not display submit and cancel if action is empty in form_dialog., 2020-06-10) ERP5JS does not display submit button, this continues in this direction to:

 - Apply the same possibility in xhtml_style to not show a submit button when there's no action. In xhtml_style we show the cancel button using the same rules as everywhere else.
 - Fix error in ERP5JS for dialogs with only an update action but no action.

See merge request !1181

Change login button to comply with Google's branding guidelines.

Add support for google login in ERP5JS.


See merge request !1166

See merge request !1171

There's nothing wrong in having more than one listbox in a dialog

The initial intention was to "disallow invalidated", without forcing users to
validate everything, but it was probably a mistake, if users don't need to
validate then validation workflow would be a bit meaningless.

This is made after an incident where a user mistakenly cloned a validated
currency and the cloned currency was available everywhere in the system.

Change to not return draft currencies by default and also change so that all
items are tuple, for consistency. That should have no impact and is a bit
easier for the test.

Also adjust accounting_ui_test, we need to validate currencies for the tests
and clear cache if we validated some (but we don't need to clear cache if we
validate accounts, because account caches is more clever and does not need to
clear all cache)

also, we don't send passwords by email

Since the workflow is linear, make sure the states and transitions are
sorted in the listboxs in same order as workflow, this makes
re-configuring the workflow a bit easier.

The views for States and Transitions have an `int_index` field, but the
property sheet was missing.

The term is "Region", not "Country"

Unused aq_base imported from Acquisition (unused-import)

See merge request !1176

WebDAVSupport module was migrated to ZODB Components in 21becf4c. This module
contains a monkey patch (5c7d50d5) on webdav.NullResource.PUT which should
really be in Products.ERP5Type.patches and was not applied anymore since the
migration.

This is not a dialog where user can do an action, it's just a dialog where user
can change the parameters and update the to see the stock levels, so this
should be using only an update action (now that this is supported).

This is the view when using drill down on stock browser, there's no action
here, this is not a dialog where user can "Do something" so a button to "Do something" is meaningless.

One reason for this button was to be able to go back to stock browser, but:
 - in ERP5JS, user can go back to stock browser by clicking again on "Stock"
   action from Views actions.
 - In erp5_xhtml_style, user can click the list header or breadcrumb.

In ERP5JS we want the "interactive reports" to be available like other view
actions, directly in the left side panel. Also "Report" are named "Export" in
this interface (which might actually be a mistake, but it's like this now).
Rendering a form_dialog in a view action works perfectly in ERP5JS, so we can
take advantage of this.

In xhtml_style, this can not be a object_view action, because object_view
actions can not use form_dialog, this breaks the navigation.

So split in two actions, to have the best of both worlds

In that case the action button is not displayed.
If there's an update action defined on the form settings, update button is
displayed.
Cancel button is displayed using the same rule as any dialogs (ie. everytime
there's a cancel_url in request)

update should still be usable in this case

testUpgradeInstanceWithOldDataFs: Upgrade erp5_upgrader too (it was in keep
list until now) as old Data.fs contains ERP5UpgraderUtils Extension with import of
Products.ERP5Type.Log. Although, erp5_upgrader should probably be automatically
upgraded before even starting the upgrade...

Remove strange hacks with get_request() and manual monkey-patching in
testDateUtils. Not sure at all why it was needed in the first place but
it does not seem relevant anymore.

To avoid too generic names for Products.ERP5SyncML.{Engine,Transport}, prefix
the ZODB Components references with SyncML{Engine,Transport}.

ERP5Wizard: Archived to erp5-archive repository (acked by @jp): not used anymore and not going to be migrated to ZODB Components.

erp5_tiosafe_core and ERP5TioSafe/{Conduit,Tool,Document} are used by SlapOS.
Everything else has not be used at all for many years (and Unit Tests have been
disabled for 7 years now).

eGov: Archived to erp5-archive repository (acked by @jp): not used anymore and not going to be migrated to ZODB Components.

See merge request nexedi/erp5!1175

Move BusinessProcess Document from erp5_trade to erp5_core as CompositionMixin
depends on it and this Mixin is used by several Documents in erp5_core.