This sends too many emails.

Some parts were outdated

The main purpose of these changes is to activate call to portal_sms.send; 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.

There are other cleanups, see individuals commits.

/cc @seb @kazuhiko @gabriel 

/reviewed-on nexedi/erp5!49

Since sending email will not work without destination email, we can globally set this constaint

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.

It allows to not cancel the loading of the iframe and to prepare the appcache.
The former behavior removed the iframe thus interrupting the preparation of
the appcache.

Putting field in center increases the string field size for ERP5JS

re-apply 25cd1201 that was mistakenly reverted by b847b45e

Hey @Nicolas can you please take a look at all this ?

All this started when I realised we probably do not want to allow grouping reference to be set when we have transactions from different ledgers ( edda8b58 ) and then realized it would be required to allow choosing ledger in grouping fast input instead of just showing all ledgers together ( d1ecbe29 ).

The rest are small changes to move out complex logic from TALES to a script and small fixups.

Thanks

/reviewed-on nexedi/erp5!170

This reverts commit b847b45e, reversing
changes made to 9075a38f.
The reverted commmit has been done automatically, investigation is needed

Putting field in center increases the string field size for ERP5JS

We were just testing that grouping references are automatically set. It
is better to also check they are set to the same thing.

Over the years, we included almost all possible default group by criterions for getMovementHistoryList, so that in essence, we do not group ... for example, we did 7814c521 . It would be better for performance and more logical to just not group by at all, getMovementHistoryList should just return the list of movements.

This is still possible to use explicit group by parameters in getMovementHistoryList, for example grouping by [explanation_uid](https://lab.nexedi.com/nexedi/erp5/blob/c413d34b9d5db0beda2b9540d563529082855d91/product/ERP5/tests/testInventoryAPI.py#L2416) like we can do in [some accounting reports](https://lab.nexedi.com/nexedi/erp5/blob/c413d34b9d5db0beda2b9540d563529082855d91/bt5/erp5_accounting/SkinTemplateItem/portal_skins/erp5_accounting/AccountModule_getGeneralLedgerReportSectionList.py#L111).

I don't have a proper benchmark, but on the instance where we discover the issue, a simple getMovementHistoryList yieliding 112301 results went from several minutes spent in state *Removing duplicates*  (I killed the query after some time) to about 3 seconds.

cc @vpelletier @jm @gabriel 

/reviewed-on nexedi/erp5!171

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

and rely on Base_getPreferredCategoryChildItemList to have results
sorted and displayed according to user preferences.