Documentation says this step is done in one transaction, so implement
this as documented.

Detecting developer mistake and automagically running this step in smaller
transactions if more than 100 documents seems unnecessary. At least, it
contredicts documentation.

now that we use alarm sense method, another `notify` call is activated

This should fix some race conditions which made post-upgrade steps not
executed sometimes.

* each steps use an defaultActivateParameterDict so that activity they
  may create inherits the same tag, so that next step also runs after
  this). This makes it possible for example to use post-upgrade step on
  documents newly installed in upgrade step.
* use tag / after tag between upgrader steps instead of checking if
  previous alarm had errors. We also now allow force running only one
  step regardless of the previous step completion state, there was no
  strong reason to prevernt this.
* do not use two different active sense and fix method for alarms, just
  use an active sense method understanding `fixit` parameter

Otherwise this is interpreted as text/html after sending html emails

(cherry picked from commit b919e0b5)

* Worklist must include (%(count)s) to include the number of document in that worklist
* The role of users who have to take care of the documents must be defined on the worklist

cf 2c54e0f5

jerome/erp5!6
(cherry picked from commit 7a4b9c454c0f87ac19adb7f1d455af44aeaef6f8)

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)

http://dhtmlx.com/docs/products/dhtmlxScheduler/ integration for ERP5

(cherry picked from commit 136ca784)

* do not repeat columns in more columns
* let listbox decide which columns are searchable / sortable
* add owner_title in more column
* add group more columns for all group calendar assignments columns ( I had to use the infamous isDelivery hack to make them searchable / sortable )

(cherry picked from commit 9b0ad6a2)

When running this alarm by hand, we do not want to wait.

(cherry picked from commit a5a2d3a7)

Conflicts:
	bt5/erp5_administration/SkinTemplateItem/portal_skins/erp5_administration/Alarm_getConsistencyCheckReportLineList.py

the .selected is too general and was applied to selected action tab in erp5_xhtml_style ui

(cherry picked from commit b4321199)

Conflicts:
	bt5/erp5_graph_editor/SkinTemplateItem/portal_skins/erp5_graph_editor/dream_graph_editor/jsplumb/jsplumb.css.css

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

This only apply for running live tests of a test component that defines
multiple classes

You can use for example,
testStandardConfigurationWorkflow.TestStandardConfiguratorWorkflow in
"Tests" field of "Live Tests" dialog to run only
TestStandardConfiguratorWorkflow test class

(cherry picked from commit ced90df1)

/reviewed-on nexedi/erp5!69
(cherry picked from commit 630bdfbf)

(cherry picked from commit 1f11442dd1d47f0eb1ab2d134efccc9ce6b42de5)

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

Workaround for bug #20160120-1805D22

I used this procedure :

git clone https://github.com/codemirror/CodeMirror.git --branch 5.13.4
cd CodeMirror

find . -not -path "./.git*" -type f -exec sed -i 's/addon\/edit\//addon\/cm_edit\//g' {} +
git mv addon/edit addon/cm_edit
git commit -a -m "ERP5: rename addon/edit -> addon/cm_edit"

lftp http://login:password@172.17.0.2:2200/erp5/portal_skins/erp5_code_mirror/ -e 'rm -rf codemirror ; mkdir codemirror ; quit' &&\
lftp http://login:password@172.17.0.2:2200/erp5/portal_skins/erp5_code_mirror/codemirror/ -e 'mkdir addon ; mput -d * */* */*/* */*/*/* ; quit '

(cherry picked from commit 639c0d5a)

(cherry picked from commit f84beaab)

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

renderjs: "touch" rjs_gadget_erp5_pt_actionpage_js so that it is reinstalled next time we upgrade our instance.

We should not have to do this and you should not have to see this, but our version of this page got archived when we customized it and we no longer want to use customized version.

To me, it seems a bit strange from user experience point of view to have suggestions for what login / password to use.

/reviewed-on nexedi/erp5!67
(cherry picked from commit 8fa68aa9)

Conflicts:
	bt5/erp5_web_renderjs_ui/SkinTemplateItem/portal_skins/erp5_web_renderjs_ui/WebSite_viewRecoverAccount.zpt
	bt5/erp5_web_renderjs_ui/SkinTemplateItem/portal_skins/erp5_web_renderjs_ui/WebSite_viewResetPassword.zpt
	bt5/erp5_web_renderjs_ui/SkinTemplateItem/portal_skins/erp5_web_renderjs_ui/login_form.zpt

fixup! Movement: Add isMovingItem method to be possible check if the object is moving physically or not

Delivery Cell follow the same logic as Deliver Line to decide if a
movement is moving item. There is no "Delivery Movement" class yet, so I
duplicate the method for now.

Without this fix, item tracking no longer work when using variations.

(cherry picked from commit d561dd5b)
nexedi/erp5!70

This reverts commit 0168bf60
(cherry picked from commit a1cf5e48)

ref nexedi/erp5!70

refs !73  72db2000

See !49

This way it is isolated it in a transaction that is less likely to fail. Activate with max_retry=0 and conflict_retry=False not to send activity twice in case of error.
As with email, if there was an error in activity processing, it is advised to investigate the transport logs to see if message was send or not.

event_simulation_workflow already call `send` type based method upon start transitions.
This workflow was not chained to portal_type, but if it would have been then message would be sent twice.