SimulationTool_zGetInterpolationMethod is called in restricted context
of Resource_zGetMovementHistoryList so it needs to be usable by
anonymous.

ZSQL Method does not read parameters from REQUEST, so it looks safe.

erp5_calendar: Update stop_date, otherwise it can stay in the past and generate wrong duration (stop_date - start_date)

With this, we accept users with permission to Modify portal content or Associate role

With this, change we accept users with permission to Modify portal content or Associate role

jerome/erp5!6 rebased and in a big
commit so that we can start using that
SimulationTool: implement "linear" flow API

Conflicts:
	product/ERP5/bootstrap/erp5_core/SkinTemplateItem/portal_skins/erp5_core/Resource_zGetInventoryList.xml

testInventoryAPI: silent pyflakes warnings

more interpolation implementation

inventory_list interpolation flow: support at_date & to_date

more and more interpolation API

interpolation

interpolation

group_by_time_sequence_list

testInventoryAPI: move inventory valuation methods in a dedicated test class

This should not be in test inventory list.

test: move Tracking API to a dedicated test module

inventory api: dirty way of disabling cache if keys such as node_category are used.

interpolation: security on SimulationTool_zGetInterpolationMethod

We should be able to configure a group calendar saying that the pattern
is "from 9:00 to 12:00, repeat every monday morning" with a group
calendar assignment saying "use this pattern from 01/01/2016 until
31/12/2016" and then create another group calendar assignment for 2017
without having to change the periodicity stop date on all presence
periods of the group calendar.

I think it should repeat from group calendar assignment's start date
until min(group calendar assignment's stop date, presence period's
periodicity stop date).

(cherry picked from commit b42a9c112d59454a42c0b5a0fd62d71a7fcd4202)

 - update PresencePeriod.getNextPeriodicalDate with fixes from 6155f7ff
 - do not use addToDate, but simply DateTime arithmetics that unlike addToDate, works correctly

(cherry picked from commit 30e2c1f6cb55ae3dfc4d8c83911b53f38a6cc36d)

because Domain.getRelativeUrl (and Category.getRelativeUrl) cannot be
restrictedTraverse'd

Workaround for bug #20160120-1805D22

The real motivation was to make sure that search match is displayed when searching with Ctrl+F / Ctrl+G

Conflicts:
	bt5/erp5_code_mirror/SkinTemplateItem/portal_skins/erp5_code_mirror/code_mirror_support.xml

codemirror: display an animation in window title so that the window flash when component has been saved.

Use case: save component on one tab, go to "run live test" tab and wait for component to be saved to make sure code runs with latest version

Conflicts:
	bt5/erp5_code_mirror/SkinTemplateItem/portal_skins/erp5_code_mirror/code_mirror_support.xml

This is probably incorrect. I believe ERP5ShortMessage's message_type
handling has to be refactored. I guess this should not be part of the
send API but be a property set on the gateway instance in portal_sms

Only mobyt support this parameter, so this break the compatibility with
essendex

erp5_travel_expense: Add transactions view on Expense Validation, Fix/Update  transaction generation

erp5_travel_expense: avoid undefined value

erp5_travel_expense: link related to Travel Request instead of record

erp5_travel_expense: can use listbox to search related mission in expense record

This was only used by listbox.
As most fields now render themself as 'p' tag in non editable mode, they are compatible with non editable listboxes to be rendered inside an 'a' tag.

Flush activities before we remove the permission to view document

In preference fields, do not fallback to displaying the globally preferred value when it's not defined on that preference

Some preferences fields have a TALES for `default` that displays the preferred value if the value if not defined locally, something like `python: context.getPreferredX() or preferences.getPreferredX()` .

I believe it is a bad idea, we should just display the value defined on the document like on every other fields.

Git log tells that over their lifetime, these fields have been changed by @tc @jm @kazuhiko @romain @yusei @aurel  so please tell me if there was a valid reason for using this pattern that I misunderstood.


/reviewed-on nexedi/erp5!217