https://www.erp5.com/documentation/developer/guideline/coding/erp5-Guideline.Coding.Best.Practice#use-methods-to-access-properties-in-erp5

This reapplies parts of 9a84ef83 , but a
different server side approach:
 * use portal_workflow API to count worklists
 * introspect workflow to build queries
 * use translated state in the query, trying to be a bit more user
   friendly. We could do for portal_type as well.

This workarounds #20180907-24A654C a problem with queries generated by
gadget worklist does not seem to support complex queries with multiple
values ( local_roles: ['Assignor', 'Assignee'] ). This code generates
queries:

```
( ( local_roles:  "Assignee" OR local_roles:  "Assignor" ) AND portal_type:  "Support Request" AND translated_simulation_state_title:  "Opened" )
```

where the previous version generated queries like:

```
( portal_type:  "Support Request" AND simulation_state:  "validated" AND local_roles: (  "Assignee" OR  "Assignor" ) )
```

which did not match anything. Maybe because local_roles is handled
differently in catalog

This reverts commit 9a84ef83.

Eventhough there's a delay due to cache, the default worklist
implementation is efficient and worklist is translated.

Also:
 * don't immediate reindex, this is a coding crime
 * don't search catalog by ID, use direct module access

To make it easier to test worklists and dashboard.

SR-15 Crashed! is Opened
SR-16 Boom!  is Suspended
SR-17 Done is Closed

Because worklists tests expect to run with ERP5TypeTestCase user, and this test uses another user.

The timeout of 10 seconds was too short for some machines

Drop failed activities instead of retrying execution and expecting it to
both fail and do something (execute alarm, then index result).

This also reverts commit f3519857.

/reviewed-on nexedi/erp5!756

/reviewed-on nexedi/erp5!753

After clicking on "Documents", we need to wait for the listbox to be loaded before doing anything else. In particular, if we do a search after clicking on "Documents" the listbox is loaded twice (once after clicking on Documents and once after clicking on search). If we don't wait for the listbox to be loaded before doing the search, the search macro might end too early.

Add manifests to make the app a progressive webapp. There are 2 manifests : one
during the installation process (while the app is loading) and one for the app
itself.  Note that the "start_url" parameter is made for the officejs app URL
([your_app].app.officejs.com/[release_number]). It doesn't work on an ERP5
instance ([instance_url]/erp5/web_site_module/[your_app]). If you want to make
it work on the ERP5 instance for testing purposes, remove one "../".

Update the Javascript Editor logo according to Vincent's wishes.

The app will be labelled "Javascript Editor" for now but the domain name will be codemirror.app.officejs.com.
Update dropbox_app_key (generated by Vincent).
Reorder totally the apps on officejs appstore (as suggested by Vincent).

/reviewed-on nexedi/erp5!754

Don't change anything, just make it pass the linter.

/reviewed-on nexedi/erp5!750

In web_site_module/predecessor_test_web_site/section_with_content_page.

This publication_section was already sel on the web section (but seemed not active ??), but not on the web page. Then this commit just adds the missing category and update the web page

Those classes were used by JQuery Mobile.

The tests are exactly the same as for text editor (except there is no
"migration test" which was not really to test TextEditor)

Codemirror app is now using the same mechanism as text_editor. For now, it has
exactly the same features as text editor but it will create "Web Script"
instead of "Web Page" documents. The codemirror mode is forced to "javascript"
and the content type of the document if forced to "application/javascript".

DiffTool: removePropertyList function should be working same for both ERP5 object and dictionaries of ERP5 object properties

Before we use to neglect removing some properties from ERP5 object properties' dict, which led to error in case of use
of DiffTool for Historical Revisions dict. Thus, its important for removeProperties function to act similar in both
cases.

Also, add `base_data` in attribute_set to be removed because `data`, `base_data` and `text_content` are same

This is essential to have better aesthetic of Deepdiff diff for tuples.
In general, we treat iterables as long string so as to bypass the complicated
diff for iterables provided by DeepDiff, but for tuples this was creating a
problem as it was not possible to understand the diff properly.

Hence, by soting them, we get more understandable diff for tuples.

Also, there is no need to override `__diff_tuple` function as it is itself
dependent on `__diff_iterable` which we already override.

Following convention, it makes more sense to use view mode for DiffTool view.
Also, we don't need selection as of now.

Also, update the tests

View wise, the date and path for new version/obvject should be on right side which
in our case is `your_second_date`. Thus, the case where we run diff action on single
object, the right side should show the current version and the left side shoule show
the last version.

/reviewed-on nexedi/erp5!741

/reviewed-on nexedi/erp5!748