only change ids of gadget (reference and content already changed)

make all graph gadget names like gadget_field_graph_plotly.html/js . We should not have any more "officejs" or "erp5" in name, since theses gadgets could be used for any kind of application.

A Form is rendered by assuming the REQUEST is clean and first set 'here' as
the context. Then there may be listboxes with rely on 'here' and set 'cell'
temporarily. At last, for easier configuration of listbox fields, 'cell' has
precedence over 'here' when rendering (in particular since
commit 4fa84233).

Based on this, the only sane solution is to
- clean up the REQUEST (remove 'here' and 'cell')
- render the FormBox in the new context (which sets 'here'): inside a ListBox,
  the context is the cell
- restore 'here' and 'cell' as they were

Which allows FormBox/ListBox inside FormBox/ListBox, recursively
(but obviously no ListBox inside ListBox).

The previous code didn't work in the following case:
- a Order Line and Packing List Line having an identical tab
- the left pane for Order Line information
- the other for Packing List Line information
  (-> empty when there's no related PL)
- a listbox (with subobjects of the PL line)
Which is implemented as follows:
- a Form for the left pane
- a Form for the Packing List Line, with a FormBox
  (to display Order information) and a ListBox
- the Form for the Order Line only has a FormBox, that uses 1 of the 2 other
  Forms depending on the presence of a PL (if there's one, it's rendered in the
  context of the PL)
-> FormBox(FormBox, ListBox)

As you can see, FormBox is used here to factorize forms. Without this patch:
- the outter FormBox crashed on `del REQUEST.other['cell']`
- the inner FormBox was rendered with a wrong 'cell'

Another change is to pass the field & REQUEST to the context method.

/reviewed-on nexedi/erp5!346

This way it would be even more easier to use graphs, and we avoid inventing additional API.
Method updateConfiguration has been removed, it is possible to call render several times if needed.

Following up !308 , these are a batch of changes to fix coding style in `erp5_accounting` as reported by pylint and `Products.ERP5Type.CodingStyle`.

Also, calls to `portal_catalog.getObject` are replaced by simple `portal_catalog` calls.


/reviewed-on nexedi/erp5!309

In `sheet_per_report_section` mode if the report do not have any fields,
we use to display an empty sheet. It was confusing and not useful.

This export action produce a spreadsheet containing information needed to physically prepare sales packing lists, prepare a mailing to prepare address stickers or whatever specific processing "outside of ERP5" can be needed when sending sales packing lists.

It is an action on sales packing lists module:

![Screenshot_2017-07-10_at_14.30.10](/uploads/554a0d7b656aaa88d250136dd39309f3/Screenshot_2017-07-10_at_14.30.10.png)

Offering two level of details:
 * One line per sales packing list line
 * One line per delivery, with the resource / quantities "packed" in a column

Both versions will display a list of sales packing lists, but only the one where resource is a product. The idea is to only care only about physically delivered goods.

When requesting boths (which is the default), user will get a spreadsheet with two tabs, like this example: [Shipment_Report.xlsx](/uploads/c39906f36cbddd5c20cdd4ce39a90381/Shipment_Report.xlsx) (this is using data from `testTradeReports.TestTradeReports.testShipmentReport` added in this MR)

The intended use case of this action is to select packing lists to prepare (usually with worklist), export this spreadsheet and change state of the selection.

/reviewed-on nexedi/erp5!320

/reviewed-on nexedi/erp5!345

/reviewed-on nexedi/erp5!343

/reviewed-on nexedi/erp5!344

/reviewed-on nexedi/erp5!340

/reviewed-on nexedi/erp5!341

- fix `NoneType` as no attribute `getTitle` (service_obj.getTitle()) ;
- use existing variable as most as possible (portal, result) ;
- avoid call `getTitle` on the same object in a loop (project.getTitle()) ;
- avoid compare projects by title as many projects may have the same ;
- avoid using `set` as service id cannot be present twice (set(service_pairs)) ;
- optimise catalog request to get project (limit) ;
- optimise catalog request to get sale supply (destination_project_uid) ;
- rename plurals in variable (service_pairs) ;
- rename abbreviations in variable (*_obj) ;
- remove trailing spaces.

[renderjs_ui] testSortItemAutoBuild counts with strict sort editor and does not fail on fast computer

As it seems addToDate do not just add 1 unit of time, but is sensitive
to the number of days in a month too

even if there is only one workflow action

/reviewed-on !335

According to Payzen API, boolean should be translated into 0 or 1 in order to be part of the signature.
The only value which contains a boolean is "litige" which can cause signature miss-match without
this change.

  Reimplement for follow up the migration of PropertySheets from Products to ERP5

  Normally it should work as annonymous.

the selection name is duplicated with Computer_view/listbox

It can be used with an external method by providing the URL to proxy as a query parameter:
ERP5Site_getHTTPResource?url=URL

The query is synchronous (no portal_activities), so, the Zope thread will be blocked until the external request is other.
In order to prevent consuming all threads, there is a really aggressive timeout of 1 second only.
This is enough for a RSS reader.
If the timeout is to short, do not increase it, but change the proxy design to use portal_activities instead.

For now, only authenticated user can use it (to prevent becoming an open proxy).
Only GET query are allowed (until a use case required any other HTTP method).

Instead of using obsolete processing_node parameter, use invalid_onlym
with True, in order to check if there are activities with error.

As INVOKE_ERROR_STATE is needed only in SQLBase, move it there and so drop it
from ActiveObject and ActiveProcess.