- 05 Oct, 2016 17 commits
-
-
Julien Muchembled authored
-
Sven Franck authored
-
Sven Franck authored
-
Sven Franck authored
-
Hardik Juneja authored
/reviewed-on nexedi/erp5!175
-
Cédric Le Ninivin authored
Use of fail is now a coding crime
-
Jérome Perrin authored
-
Jérome Perrin authored
this way after a zelenium tests ERP5Site_setupDummyMailHost this will also reset the mails that could have been sent in previous tests.
-
Jérome Perrin authored
-
Jérome Perrin authored
This sends too many emails.
-
Jérome Perrin authored
Some parts were outdated
-
Jérome Perrin authored
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
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
Since sending email will not work without destination email, we can globally set this constaint
-
- 04 Oct, 2016 4 commits
-
-
Julien Muchembled authored
-
Jérome Perrin authored
-
Jérome Perrin authored
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.
-
Jérome Perrin authored
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.
-
- 03 Oct, 2016 7 commits
-
-
Cédric Le Ninivin authored
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.
-
Romain Courteaud authored
Putting field in center increases the string field size for ERP5JS
-
Romain Courteaud authored
-
Romain Courteaud authored
-
Sebastien Robin authored
-
Jérome Perrin authored
re-apply 25cd1201 that was mistakenly reverted by b847b45e
-
Jérome Perrin authored
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 !170
-
- 30 Sep, 2016 9 commits
-
-
Cédric Le Ninivin authored
This reverts commit b847b45e, reversing changes made to 9075a38f. The reverted commmit has been done automatically, investigation is needed
-
Cédric Le Ninivin authored
-
Cédric Le Ninivin authored
-
Cédric Le Ninivin authored
-
Romain Courteaud authored
Putting field in center increases the string field size for ERP5JS
-
Romain Courteaud authored
-
Romain Courteaud authored
-
Jérome Perrin authored
-
Jérome Perrin authored
We were just testing that grouping references are automatically set. It is better to also check they are set to the same thing.
-
- 29 Sep, 2016 3 commits
-
-
Rafael Monnerat authored
-
Rafael Monnerat authored
-
Jérome Perrin authored
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 !171
-