- change the generate_rss_link action in Support Request Module, to directly call SupportRequestModule_generateRSSLinkUrl.py instead of the form.
- change SupportRequestModule_generateRSSLinkUrl to display the form at the end.
- Use Base_renderForm like for erp5_crm
- Put the RSS url in the REQUEST
- change the gadget field configuration to use the value from the REQUEST (if not found, put None)

In Support request test we trigger clipboard API to copy RSS Link

erp5_officejs_support_request_ui_test: Add test to make sure we have all expected actions to access support request web site

erp5_officejs_support_request_ui: Search action dynamically according to the action category defined on web site

If we always get links from action_object_view, Support Request will always break if we change View Action Category on web site.

erp5_officejs_support_request_ui: 'Customer Support Dashboard' in 'Support Requests Dashboard' (in header)

Also, remove RSS link from dashboard

Also, remove the usage of document.getElementById because we should search only inside the current gadget

If we have more than two options to project and resource

See merge request nexedi/erp5!1177

See merge request nexedi/erp5!1182

    The separation aims to reduce the dependency required to use the macros, where:

       * erp5_web_renderjs_ui_test contains the tests and the dependencies to run the tests
       * erp5_web_renderjs_ui_test_core contains the reusable macros, that can be used on other projects to write their own tests.

This is a first prototype showing how a site rendering can be modified
on the style with a renderJS gadget (to remove, add, modify current page
elements).

The navigation is automatically handle by the javascript (with the
pushState API), which really speed up the navigation on powerless
machine (like Pinebook Pro).

Until now, a reset was performed even though ZODB Components were not created or
replaced. Introduce a new installation hook to avoid those useless resets.

When installing bootstrap bt5s, erp5_base, erp5_simulation: 33 => 12 resets.

Improve consistency with document view

The changes from nexedi/erp5!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 nexedi/erp5!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 nexedi/erp5!1181

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

Add support for google login in ERP5JS.


See merge request nexedi/erp5!1166

See merge request nexedi/erp5!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