- 19 Apr, 2019 1 commit
-
-
Fully rewrite portal_simulation.mergeDeliveryList to use builders to reconstruct new merged delivery. Add parameter "merge_delivery" to builder. This parameter is used when merge should be done in such a way that movement group at delivery level are ignored
Sebastien Robin committed
-
- 27 Jul, 2018 1 commit
-
-
Before, when solving a solver, parsing sub objects of solver_process was done directly synchronously in solver_workflow. And we had the case where you have parallel transactions solving a solver, each of theses transactions see remaining solver not in solved state, but once all transaction are finished, all solver are solved. This could lead to the case where solver_process is never moved to succeeded. Instead of using serialize (which may lead to conflicts), just use activities in queue with a serialization tag.
Sebastien Robin committed
-
- 04 Apr, 2018 1 commit
-
-
When document has pending activities, we refuse changing ID ( because there might be pending `updateRelatedContent` activities if I remember correctly ), but it's done in a way that breaks the "atomic" aspect of the transaction a bit, because we As a result, this happens sometimes that not all properties user changed are modified. In the example below, the change to *Include Documents in Site Map* is not saved (and also change to *ID*):  ( screencast of editing a document to change ids and several other properties - after clicking save, we can see that changing id is refused because there is pending activities. Other properties that where changes at the same times are not all modified, which breaks the transactionality we can usally expect when editing documents in ERP5 ) The changed here is to use a field validator that refused editing when there are pending activities, so that user gets a:  ( screenshot of the change: now edition is rejected ) and the result is either all changes are applied or no change is applied at all. This is done by: * introducing a new `my_view_mode_id` field in `erp5_core`'s `Base_viewFieldLibrary` * using this field as proxy field of all editable `my_id` fields. Maybe I forgot some business templates, I changed only the most common ones. I intentionally did not change all fields of `erp5_ui_test` because I think they are used to compare speed of proxy fields vs traditional fields. 0352f50fd543fda2712bb8ca93d8a8814f975a26 introduces a Zelenium test exercising this new behavior. /reviewed-on !504 Conflicts: product/ERP5/bootstrap/erp5_core/SkinTemplateItem/portal_skins/erp5_core/Base_viewFieldLibrary.xml
Jérome Perrin committed
-
- 30 Nov, 2017 1 commit
-
-
Sebastien Robin committed
-
- 27 Nov, 2017 1 commit
-
-
Jérome Perrin committed
-
- 19 Oct, 2017 1 commit
-
-
to fit to the new behavior related to these changes : - 2c74e408 - a40266af
Tristan Cavelier committed
-
- 11 May, 2017 2 commits
-
-
1. 'Solve Divergences' action: => Display Delivery_viewSolveDivergenceDialog.listbox: -> Delivery_getSolverDecisionList -> Delivery_getSolverProcess => create Solver Process in 'draft' state and build Solver Decisions. 2. Clicking 'Update' button updates Solver Decisions. 3. Click 'Solve Divergences' button after either 'Adopt Prevision' or 'Accept Decision'. => SolverProcess.solve(): Solver Process transit to 'solving' state and 'solve' Activity is created. Before this Activity is executed, user can still select 'Solve Divergences' action and this will create another 'Solver Process' as the current one is not in 'draft' state anymore. Moreover, another user can still 'Adopt Prevision' (while the first user selected 'Accept Decision') and this will be actually be applied despite the first user choice. Instead, create Solver Process when transiting to 'diverged' state and do not display 'Solve Divergences' button nor allow access to 'Solve Divergences Dialog' (Delivery_viewSolveDivergenceDialog) if there is a Solver Process in 'solving' state.
Arnaud Fontaine committed -
…me as legacy Simulation Dialog). This fixes the following Site Error when there is no Divergence to solve: AttributeError: 'NoneType' object has no attribute 'SolverProcess_getSolverDecisionList' This may happen if user selects 'Solve Divergence' Action and solve Divergences, then immediately goes back and selects again this action whereas there is actually no Divergence to solve.
Arnaud Fontaine committed
-
- 07 Mar, 2016 1 commit
-
-
…b Pages, Web Scripts etc. separate to xml
Georgios Dagkakis committed
-
- 18 Feb, 2016 2 commits
-
-
Followup of: "simulation: improve equivalence testers explanations messages".
Arnaud Fontaine committed -
With latest simulation, the explanation given to user when solving a divergence was not good enough : - Property ids were displayed without possibility to display business word (like displaying 'stop_date' instead of 'Delivery Date' - Some message was displayed in the solve divergence dialog whatever was the equivalence tester behind. Therefore, customizations of messages made a equivalence tester level were not displayed to user Therefore, following was done: - in solve divergence dialog, include the message generated by the equivalence tester - use tested_property_title to allow using business words to describe properties having divergence - most equivalence testers are written in a way to evaluate divergence on a single property. To have better UI configuration of such equivalence testers, change tested_property and tested_property_title properties type from "lines" to "string". This required to add some backward compatible code. - use Variation Divergence Tester to show a case of an equivalence tester using different properties. For this, add a property sheet dedicated to multi properties equivalence testers - update propertysheets to allow translating tested_property_title
Sebastien Robin committed
-
- 01 Feb, 2016 1 commit
-
-
Solve divergence dialog was raising unauthorized error when new solver process was created by this script (when called with someone who was not manager). Therefore use proxy role and protect call with "View" permission. View is used instead of modify portal content since we could imagine cases where user might need to solve divergence even though is has no right to modify delivery.
Sebastien Robin committed
-
- 28 Jan, 2016 1 commit
-
-
1. On Tab1, from PurchaseSupply_view, click on 'Purchase Supply Lines': Base_viewListMode??proxy_form_id=PurchaseSupply_view&proxy_field_id=listbox This Python Script initialise 'list_mode_proxy_selection' with the above 2 GET parameters and then displays PurchaseSupply_view.listbox indirectly but current Form is Base_viewListModeRenderer. 2. On Tab2, from SaleSupply_view, click on 'Sale Supply Lines': Base_viewListMode?proxy_form_id=SaleSupply_view&proxy_field_id=listbox This Python Script initialise 'list_mode_proxy_selection' with the above 2 GET parameters and then displays SaleSupply_view.listbox indirectly but current Form is Base_viewListModeRenderer. 3. On Tab1, filter Purchase Supply Lines. As proxy_form_id and proxy_field_id are not given, then Base_viewListModeRender fallbacks on 'list_mode_proxy_selection' values to find out the Form ID to be called and wrongly display SaleSupply_view.listbox (2.).
Arnaud Fontaine committed
-
- 01 Dec, 2015 1 commit
-
-
Kazuhiko Shiozaki committed
-
- 09 Nov, 2015 1 commit
-
-
Arnaud Fontaine committed
-
- 02 Oct, 2015 1 commit
-
-
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
Sebastien Robin committed
-
- 16 Sep, 2015 1 commit
-
-
Do not handle solving issues in Workflow_statusModify, use directly script attached to the dialog of solving divergence. Also, previous code was no longer working properly with latest simulation
Sebastien Robin committed
-
- 10 Sep, 2015 1 commit
-
-
Sebastien Robin committed
-
- 27 Apr, 2015 1 commit
-
-
For some base categories like specialise, the order of categories is important. list.sort implements a stable sort so we can use it here.
Julien Muchembled committed
-
- 28 Aug, 2013 1 commit
-
-
Julien Muchembled committed
-
- 04 Jun, 2013 1 commit
-
-
Julien Muchembled committed
-
- 15 Mar, 2013 1 commit
-
-
-Titlecase terms, uppercase abbreviations, avoid jargons, add titles to empty title forms....
Mame Coumba Sall committed
-
- 21 Feb, 2013 1 commit
-
-
Jérome Perrin committed
-
- 29 Jan, 2013 1 commit
-
-
Leonardo Rochael Almeida committed
-
- 03 Oct, 2012 1 commit
-
-
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.
Julien Muchembled committed
-
- 28 May, 2012 1 commit
-
-
Julien Muchembled committed
-
- 22 May, 2012 1 commit
-
-
It is required anyway to install it in order to respect BT dependencies.
Julien Muchembled committed
-
- 09 Apr, 2012 1 commit
-
-
Julien Muchembled committed
-
- 26 Jan, 2012 1 commit
-
-
Kazuhiko Shiozaki committed
-
- 24 Jan, 2012 2 commits
-
-
Kazuhiko Shiozaki committed
-
Kazuhiko Shiozaki committed
-
- 19 Jan, 2012 2 commits
-
-
…hey should not be used as they are in real applications.
Kazuhiko Shiozaki committed -
Kazuhiko Shiozaki committed
-
- 11 Jan, 2012 1 commit
-
-
… to update the dialog first.
Kazuhiko Shiozaki committed
-
- 23 Dec, 2011 1 commit
-
-
The report tree is used really often, so just reuse Applied Rule listbox's configuration.
Łukasz Nowak committed
-
- 15 Sep, 2011 1 commit
-
-
Kazuhiko Shiozaki committed
-
- 11 Aug, 2011 1 commit
-
-
Kazuhiko Shiozaki committed
-
- 12 Jul, 2011 2 commits
-
-
Add view and property-sheet for Specialise Divergence Tester so that only specialise links of specific portal types can be divergence tested (or, alternatively excluded from divergence testing). Use the accessors above to restrict which specialise links are selected for testing on the movement by the Specialise Divergence Tester.
Leonardo Rochael Almeida committed -
Kazuhiko Shiozaki committed
-
- 28 Jun, 2011 1 commit
-
-
Kazuhiko Shiozaki committed
-