Until now, only bt5 Extension/Test/Document could be migrated from
filesystem.

Determine which Products Documents are to be migrated by looking at the mro()
of the bt5 Portal Types classes. For now, this only considers
Products.ERP5.Document.* but this may be extended later on.

XXX-BEFORE-MERGE: Add Unit Test.

* Use *Component temp_object instead of ad-hoc dicts (cleanup).
* Select 'version' for all the modules at once instead of per modules (not
  practical when migrating many modules, eg for migrating Products Documents).
* Fix naming of Form Fields (s/my_/your_/).

Only the current ListBox page was submitted because this simply doesn't work
with temp_objects. Instead, display all of the modules to be migrated on a
single page.

This reverts commit 6687e7e0.

Test for bugfix /#/bug_module/20171208-5E8D43

/reviewed-on nexedi/erp5!529

[erp5_base] Add following movement groups to Order Builder. Order Builder should be able to use the same movement groups as Delivery Builder.

First Causality Movement Group
Invoice Movement Group
Previous Causality Movement Group
Property Grouping Movement Group

[erp5_base] Fix Delivery_getLedgerItemList to make it work with non-Delivery Type portal type documents.

Internal Order
Internal Packing List
Internal Trade Condition
Purchase Invoice
Purchase Order
Purchase Packing List
Purchase Trade Condition
Returned Purchase Order
Returned Purchase Packing List
Returned Sale Order
Returned Sale Packing List
Sale Invoice
Sale Order
Sale Packing List
Sale Trade Condition

[erp5_pdm] Fix proxy fields of order_quantity_unit and time_quantity_unit. Since they are derivations from quantity_unit, "quantity_unit" is needed in the path in the path.

This reverts commit 82c5ae6f.

Add a test to check that hidden rows action update the listbox head

/reviewed-on !536

[erp5_core] Allow developers to choose a larger value for the preference of number of lines displayed in listboxes.

[erp5_pdm] Display validation state title of Quantity Unit Conversion Group and Quantity Unit Conversion Definition.

A lot was found with pylint.

Follow a simple / non-simple approach, like for Task and its lines.

In default case, user would need only one Leave Request Period, which
can be edited directly on LeaveRequest_view. So, in this case, hide the Listbox
containing the Leave Request Periods and have default_leave_request_period
being created / edited on background, which will acquire quantity, resource, start_date and stop_date
from what is set at the view of the Parent.

In case one or more Leave Request Period are added manually, user would get
listbox with sub-objects, and editing should be done directly on them, i.e. fields like
my_default_leave_request_period_start_date will be disabled from LeaveRequest_view.

Additionally, now Leave Request has it's own:
- start_date: equal to the minimum start_date of all Leave Request Periods
- stop_date: equal to the maximum stop_date of all Leave Request Periods

These values are set by interaction on Leave Request Period, triggered on
_setStartDate, _setStopDate. This helps so that leave_request_module listbox
can have sortable dates.

Commit contains also <a href="https://lab.nexedi.com/georgios.dagkakis/erp5/blob/leave_request/product/ERP5/tests/testCalendar.py#L1626">test</a> that should make it easier to understand.

Test results <a href="https://nexedi.erp5.net/test_result_module/20171113-20E90B8F">here</a>

@seb we have talked on this and @cedric.leninivin I know you dealt with Leave Requests. Who else should be notified?





/reviewed-on nexedi/erp5!493

ERP5 doesn't provide any information about the timezone used internally.
As test doesn't know the selenium browser locale, full text can't be checked.

[erp5_core, erp5_property_sheets, erp5_pdm] Add time_quantity_unit and order_quantity_unit categories and add max/min order quantity to supply. Also cleaning up proxy fields for supply view forms.

After migration of catalog to ERP5-ified document, its better to migrate all the catalog methods (`ZSQL Method, Python Script`) to new format. This will save the 
time during migration for developers and will reduce the chance for error during *import_in_old_format >> export_in_new_format* process.


Some important changes during re-export:
- Classes for new catalog methods are now defined via `portal_type`
- Filter is now defined via properties, so no need to save their properties in `.catalog_keys.xml` file.

/reviewed-on nexedi/erp5!518