caused by no search criterions

/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.

Clone of nexedi/erp5!339

/reviewed-on nexedi/erp5!391

Also, document that value order in base_category_dict is meaningless.

@Nicolas uses worklist as one of many gadgets in one page thus stackable empty worklist is necessary (before it was positioned as an fixed element).

/reviewed-on nexedi/erp5!387

fixes #20170911-1AD62FB