An error occurred fetching the project authors.
- 29 Dec, 2014 1 commit
-
-
Julien Muchembled authored
They were useless since 'delivery' is indexed in ZODB, and this also fixes a bug causing local build to fail in the following conditions: - root document moved to a state that triggers a builder, whereas there's no simulation tree yet - the builder select method has a condition on the root simulation movement An example is building of task reports, when the ERP is overloaded. The reason was that in some cases, ERP5 tried to set 2 tags on the same reindexing activity (built: in updateMovementCollection & expand: in _updateSimulation), but there's actually no support for multi-valued tags and for CMFActivity, default activate parameters (here expand:) have lower precedence (see ActivateObject.activate). So another possible fix is to add built: to _localBuild after_tag. This commit also renames expand: into build:
-
- 26 Jan, 2013 1 commit
-
-
Julien Muchembled authored
Use of catalog to get related simulation movements from delivery lines/cells is unreliable. Until now, for any new code written for simulation, we often had to be careful not to call getDeliveryRelatedValueList too early, usually by deferring code to activities with complicated dependencies. Race conditions are difficult to avoid by developping this way, because for a given delivery, there are potentially so many events that happen at the same time, involving: - simulation, amongst causality, expand, building, solving (including split) - alarms, user actions, external interfaces, chains of activities - several related deliveries and simulation trees This commit enables ZODB-indexing of related documents for 'delivery' base category, making getDeliveryRelatedValueList safe and fixing unlink of deleted delivery lines/cells. Existing activity dependencies are left unchanged because builders only uses catalog and local building needs to find all simulation movements.
-
- 18 Dec, 2012 1 commit
-
-
Julien Muchembled authored
-
- 04 Aug, 2011 1 commit
-
-
Julien Muchembled authored
This reverts partially commit 2b92f990 ("expand: optimize creation of new movements by not using propertyMap+_edit").
-
- 27 Jul, 2011 1 commit
-
-
Julien Muchembled authored
-
- 15 Jun, 2011 1 commit
-
-
Kazuhiko Shiozaki authored
* more values come outside testers, i.e. rule itself and Business Process procedure.
-
- 08 Jun, 2011 1 commit
-
-
Sebastien Robin authored
This improve commit c64d4287 and it allows to keep current configuration of rules. Now we use tester method getUpdatablePropertyDict in order to know which properties we propagate in expand
-
- 07 Jun, 2011 1 commit
-
-
Sebastien Robin authored
Until now, we had in movement collections all possible properties found by _propertyMap for every movement. Now movement collections use list of properties defined in rules. This change was breaking some tests because not enough properties were expanded, so in the same time it is required to add more properties to progagate on several rules
-
- 11 Mar, 2011 2 commits
-
-
Jérome Perrin authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@44190 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Jérome Perrin authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@44189 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 17 Sep, 2010 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@38465 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 27 Jul, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
same as r37158 (clear recorded properties when updating, because update means incoming movements have changed and recorded properties have no meaning for updated properties). git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@37302 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 05 May, 2010 1 commit
-
-
Jean-Paul Smets authored
Do not provide context to movement generator. Current mixin is questionable since it is not self contained. Added comment for this. Either make it inherit from dependent mixin, or design better. git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@34999 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 04 May, 2010 1 commit
-
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@34978 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 29 Mar, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
aggregation is not required here, because we want to have one simulation movement per one order line just same as before. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34189 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 04 Mar, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33401 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 28 Dec, 2009 2 commits
-
-
Kazuhiko Shiozaki authored
* rename variables to make more sense. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31483 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31479 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 23 Dec, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
initial attempt to aggregate passed prevision movement list (temporary simulation movements), i.e. if we have two same sale order lines (from matching tester point of view), only one simulation movement will be created for them. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31448 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 16 Dec, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31336 20353a03-c40f-0410-a6d1-a30d3c3de9de
-