An error occurred fetching the project authors.
- 04 May, 2022 1 commit
-
-
Arnaud Fontaine authored
Done through various 2to3 fixers (zope.fixers, modernize, future) and manual changes. This is a single commit so that we have a clearer picture of how code converted with my2to3 should look like. Except straightforward @implementer decorator 2to3 fixer, only product/ folder was considered as the goal was to be able to create an ERP5Site. * Use @implementer decorator introduced in zope.interface 3.6.0 (2010): The implements syntax used under Python 2.X does not work under 3.X, since it depends on how metaclasses are implemented and this has changed. Instead it now supports a decorator syntax (also under Python 2.X). Applied thanks to 2to3 `zope.fixers` package. * Use `six.moves` rather than `future` install_aliases() feature because the latter use unicode_literals and "wraps" module aliases so that unicode() are returned for text rather than str() (Python2 standard library). This notably breaks BusinessTemplate code which uses urllib quote() for filesystem paths... * No more unbound methods in python3 so use six.get_unbound_function(). * dict.(iteritems,iterkeys,itervalues)() => six.\1(dict) thanks to `dict_six` 2to3 fixer from `modernize`: $ python-modernize -w -f dict_six product/ * Manually make sure that dict.{items,values,keys}() returns a real list when it is latter modified rather than a dict_{items,values,keys} (ensure_list()). By default, 2to3 blindly does list(dict.{items,values,keys}()) which is not acceptable from performances point of view. With my2to3, this will be possible to handle such case automatically. * Replace cStringIO.StringIO() by six.moves.cStringIO() (a module alias for cStringIO.StringIO() on py2 and io.StringIO() on py3). * Use six.text_type which maps to unicode() on py2 and str() on py3. This also makes a clearer difference between text and binary strings. * Replace map()/filter() with lambda function by list comprehension (this has the benefit to avoid casting to list for py3 as it returns iterators).
-
- 03 Apr, 2020 1 commit
-
-
Arnaud Fontaine authored
This moves portal_solver_processes from erp5_base to erp5_simulation as its Portal Type definition is already there and it was initially moved away from erp5_simulation presumably because erp5_simulation was for new Simulation at that time. Also, as delivery_causality_workflow uses portal_solver_processes, move it to erp5_simulation (along with delivery_causality_interaction). This required fixing Unit Tests to install erp5_simulation before erp5_trade (it already depended on it anyway).
-
- 07 Jan, 2016 1 commit
-
-
Nicolas Wavrant authored
-
- 29 Dec, 2015 1 commit
-
-
Nicolas Wavrant authored
-
- 02 Oct, 2015 1 commit
-
-
Sebastien Robin authored
Remove broken concept of Mapping Properties that was used on legacy simulation. We do not want to use this concept any more, any mapping should be done by rule themself. Removing mapping properties leads to more generic concepts and much simpler code. With legacy simulation, in case of returned sale packing list (in case we want to invoice in same sale invoice usual sale packing list and returned sale packing list) : AR (delivering_rule): -> SM (source/A, destination/B) -> AR (invoicing_rule, having mapped_property mapping source to destination and vice versa) -> SM (source/A, destination/B) builders and solvers where doing sm.getMappedProperty('source') which was equivalent to sm.getProperty('destination'), thus the mapping was done in live time Now in such case, we should implement mapping directly at rule level, and this should give: AR (delivering_rule): -> SM (source/A, destination/B) -> AR (invoicing_rule, reversing source and destination) -> SM (source/B, destination/A) here we directly have properties we wish, no need of hacks on builders and solvers
-
- 16 Oct, 2014 1 commit
-
-
Julien Muchembled authored
-
- 03 Oct, 2012 1 commit
-
-
Julien Muchembled authored
All interactions and activity tags are reviewed to fix bugs like duplicated root applied rules, and also reduces the amount of duplicated/useless work, e.g: - Simulation trees are not expanded anymore when simulated objects are modified. - 'expand' activities are merged (i.e. dropped) with any other 'expand' activity for an ancestor. New implementation exposes new API that hides much complexity to the developper about activity dependencies. By default, expand() now automatically defers any work if the current transaction takes too long time. This method also gains a parameter to explicitely choose when to expand, which is often important in unit tests or solvers. In particular, when postponing work, it takes care of setting proper activity dependencies. - If you have any code requiring to expand everything immediately, you'll have to replace 'expand()' by 'expand(expand_policy="immediate")'. - On the contrary, you should replace any 'activate().expand()' by 'expand(expand_policy="deferred")'. expand() still accepts activity parameters for any extra needs. In causality workflow, 'building' state is clarified and now means « delivery may diverge but we can't know now ». A delivery remains in draft as long as it does not contain any movement built from simulation. After init/clone/builder/etc. scripts used to call 'startBuilding' & 'updateCausalityState': this calls must be removed since only SimulatedDeliveryBuilder should take care of move to 'building' state and workflows now triggers 'updateCausalityState'. Disguised interactions have been unhardcoded and either deleted, or moved to appropriate interaction workflows, which have been reorganized. Those that triggers update of portal_workflow can be easily customized or disabled. New API: - updateSimulation() on deliveries and subscription items. It takes care of creating root applied rule, expanding and reindexing parts of simulation trees. It somehow replaces: - Delivery_updateSimulation - Delivery_updateAppliedRule - Delivery.applyToDeliveryRelatedMovement - Delivery.updateAppliedRule - Delivery.expand - Delivery.expandRuleRelatedToMovement - SubscriptionItem.expand - SubscriptionItem.updateAppliedRule - Delivery.localBuild() is the new way to do local building and replaces Delivery_expandAndBuild. Private method Delivery._localBuild replaces Delivery_buildOnComposedDocument. - Simulation Movements that are being built by a builder are reindexed with the following tag: 'built:<delivery_path>'. Any after_path_and_method_id dependency against 'related_simulation_movement_path_list' and reindexing methods should be replaced by this after_tag. After builder scripts used to confirm the delivery in a separate activity, which was useless.
-
- 22 May, 2012 1 commit
-
-
Julien Muchembled authored
This fixes a regression in recent commit 6e758ade The following line: simulation_movement_list = delivery_dict.get(movement) or \ movement.getDeliveryRelatedValueList() didn't work because the loop that fills delivery_dict does not necessarily find all related simulation movements for every key. New code is a little complicated because it tries to not call getDeliveryRelatedValueList() when 'movement' is not related to trade model.
-
- 03 May, 2012 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 06 Dec, 2011 1 commit
-
-
Vincent Pelletier authored
Update all known callers to use the new method.
-
- 27 Jul, 2011 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 22 Jun, 2011 1 commit
-
-
Kazuhiko Shiozaki authored
divergent movement can include trade model related movements, that should not be accepted.
-
- 05 Aug, 2010 1 commit
-
-
Jérome Perrin authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37504 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 15 Jul, 2010 1 commit
-
-
Sebastien Robin authored
Conflicts: bt5/erp5_base/bt/revision bt5/erp5_simulation/DocumentTemplateItem/InvoiceSimulationRule.py bt5/erp5_simulation/bt/revision bt5/erp5_trade/SkinTemplateItem/portal_skins/erp5_trade/Base_viewTradeFieldLibrary.xml bt5/erp5_trade/bt/change_log bt5/erp5_trade/bt/revision products/ERP5/Document/BusinessPath.py products/ERP5/Document/SimulationMovement.py products/ERP5/Document/TradeCondition.py products/ERP5/Document/TradeModelLine.py products/ERP5/bootstrap/erp5_mysql_innodb_catalog/bt/revision products/ERP5Type/ERP5Type.py git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37129 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 06 Jul, 2010 2 commits
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36895 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Kazuhiko Shiozaki authored
call solver_workflow's method only when it is possible, because we don't want to use solver_workflow for automatic solvers. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36886 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 02 Jul, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
simulation_movement.setMappedProperty() does not accept activate_kw (this is why I added simulation_movement.setDefaultActivateParameters() in the previous commit). git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36796 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 01 Jul, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36766 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 25 Jun, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
store a list of simulation movements to be solved instead of delivery movements in a Solver Decision document, that is more efficient and consistent with the way to find appropriate target solvers whose predicate's context is a simulation movement. XXX now using 'delivery' category to store simulation movements does not sound good. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36616 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 10 May, 2010 1 commit
-
-
Jérome Perrin authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@35140 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 23 Mar, 2010 3 commits
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34001 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Kazuhiko Shiozaki authored
* adopt only for trade model related movements. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33997 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Kazuhiko Shiozaki authored
same as r33958 (now tested property list should be taken from Target Solver document or its portal type). git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33990 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 17 Mar, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
initial commit of Trade Model Solver, that will modify simulation movements and trade model related movements accordingly. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33812 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 10 Mar, 2010 1 commit
-
-
Nicolas Dumazet authored
What's the point? Mostly cleaning up pyflakes output: now, running it on those files does not give anymore cluttered output, but raises (almost) only valid human errors. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33558 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 10 Feb, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@32401 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 04 Feb, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@32268 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 21 Jan, 2010 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31872 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 22 Dec, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31420 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 17 Dec, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31378 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 15 Dec, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31309 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 14 Dec, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31289 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 17 Nov, 2009 1 commit
-
-
Sebastien Robin authored
order to make optimisation configuration in unit test - isIndexable is not a property any more, it is a ConstantGetter instance, so it works like a property and like a method - same thing for isPredicate, isTemplate, isDelivery... we can start moving using only methods. - do not define isTemplate, isDelivery... when it is already available thanks to inheritance - new methods generated for all ERP5 objects : provides[InterfaceName]. For instance, "providesIMovement()" will return True or False for any ERP5 object. - new method "is[Group]Type" generated for all ERP5 objects. The group here is group of portal types (like getPortalDeliveryTypeList()). So on any ERP5 object, you can do "isDeliveryType()", and this will returns True or False. - add tests git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30704 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 07 Nov, 2009 2 commits
-
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30398 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30396 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 04 Nov, 2009 1 commit
-
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30280 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 01 Jun, 2009 1 commit
-
-
Kazuhiko Shiozaki authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@27285 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 05 Feb, 2007 1 commit
-
-
Romain Courteaud authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@12549 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 02 Feb, 2007 1 commit
-
-
Romain Courteaud authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@12519 20353a03-c40f-0410-a6d1-a30d3c3de9de
-