/reviewed-on nexedi/erp5!403

caused by no search criterions

graph_editor was using `rsvp.Monitor` in order to dynamically add new promises to the chain of promise in its `declareService` promise. New DOM elements were added during gadget's lifetime and and event handler on these new elements was added to the chain of promise by using [monitor method](
 https://lab.nexedi.com/nexedi/erp5/blob/76ecef89d0b4f6aa6bc5/bt5/erp5_graph_editor/SkinTemplateItem/portal_skins/erp5_graph_editor/dream_graph_editor/jsplumb/jsplumb.js.js#L607) of a monitor instance which was [returned](https://lab.nexedi.com/nexedi/erp5/blob/76ecef89d0b4f6aa6bc5/bt5/erp5_graph_editor/SkinTemplateItem/portal_skins/erp5_graph_editor/dream_graph_editor/jsplumb/jsplumb.js.js#L835) in `declareService`.

`rsvp.js` included in `erp5_xhml_style` exported `Monitor`, but this was removed in  af9c57db . If I understand correctly, this is now included in renderjs, but it's only internal.

So this old way of doing is not longer possible. We realized that instead of dynamically setting `dblclick` event handlers to each graph node elements, we could  simply rely on event bubbling and use a event handler on the parent DOM element. Also, we used renderjs builtin `onEvent` that makes event callback function executed in the promise chain . 

At this stage we did not try to switch all event handling to this approach of using a "global" event handler on the parent DOM, because the goal here was just repairing the graph editor and making sure we have tests running. Also jsplumb uses its own event system.

To enable tests for this:
 - Running the existing qunit test through Zelenium. As far as I know we cannot run qunit test as part of ERP5 test suite.
 - Install the business template in testXHTML so that it is tested by `jsl`, which by the way produce different messages that the jshint integrated in ERP5's code mirror and jslint from `WebScript_checkSyntax`. For now, this passes jshint and jsl, but jslint complains about some indentation and space problems.

/cc  @romain @vincentB @xiaowu.zhang  @seb @gabriel 

/reviewed-on nexedi/erp5!321

/reviewed-on nexedi/erp5!398

Changes:
 * indentation and whitespaces between function and (. ( tips: use ignore whitespace for review)
 * usage of `new`. Some RSVP.Promise where not using `new`, some RSVP.all had an extra `new`
 * fix a "weird condition", javascript does not evaluate (a <= b <= c) same as python
 * change `var` declarations one per line, to be compatible with
   upcoming jslint version. Use a vars: true  directive so that jslint 2014-04-21 is also happy  (
   see https://stackoverflow.com/questions/34862541/expected-and-instead-saw-jslint-multivar-setting )
 * in function definitions: rename unused arguments as `ignore` or remove them when possible ( when they were last )
 * use named functions ( for exemple fillDialog ), otherwise jslint complain they are not in scope.

Otherwise, the event handler is set multiple times on the same #qunit-fixture element

It causes {msg: "jsPlumb: unknown connector type 'StateMachine'"} problem when jquery was already loaded

because it adds an action to edit business processes

This is to comply with
[jsl](https://lab.nexedi.com/nexedi/slapos/blob/ce15c54/component/jsl/buildout.cfg)
used in testXHTML

Also, fix a logging context name.

erp5_officejs_support_request_ui: Let the search bar only search the items which type are 'Support Request'

Add some support requests to let the listbox have enough items to paging.

When the homepage refreshed with "field_listbox_begin_from", the
listbox always on loading state.

We should not call child gadget's "changeState" directly. Instead,
we need to call child(listbox) render in parent render.

Which can let the child listbox aware of the parameter change in the parent gadget.

This fixes an issue :
When we work on two web apps in two different domains
but using the same erp5 as storage backend,
the allow origin response header was equal to one sole
domain for the two web apps.

This way it is easier to further extend it without risking key conflicts
in catalog parameters, which in turn would either lead to simple TypeErrors
("multiple values for parameter ...") or to criterion being accidentally
ignored.
Update callers.
These methods are young enough that no other callers should exist yet.

* This kind of query: 'foo:("bar", "couscous")' is currently not supported by query storage

follow_up | Related Object
creation_date | Creation Date
translated_validation_state_title | State

This action should only be possible if user have View History
permission.

erp5_data_protection relies on removing the "View History" permission to
make sure users cannot see the properties before protection in the
history tab. This was supported by Base_viewHistory, but not by ZODB
History

If we call Base_translateString before storing the message in the
history, the message will be translated when this action is used and
stored as translated using the language of the user executing this action.

The proper way is to store a message in history, so that it is rendered
when displayed.