1. 14 Aug, 2018 1 commit
    • Jérome Perrin's avatar
      Constraints on currencies instead of required fields · b7cc8ef9
      Jérome Perrin authored
      We have this [Do Not Test Required In Field View Form](https://www.erp5.com/documentation/developer/guideline/module/erp5-Guideline.Module.Creation#do-not-test-required-in-field-view-form rule) rule:
      > This kind of constraint should be defined in Constraints documents and should to be checked in workflow transitions.
      >
      > Checking a field as "required" can cause problems like not saving the data when the user clicks on the save button. The same applies to the use of External Validators scripts in fields.
      
      Currency view was not respecting this, there was both required fields and external validator. 
      Also, the external validator was using an incorrect way of getting the "context document", so it was not working on RenderJS UI.
      
      We are removing required fields and validator here, because this should be implemented using constraints instead.  To somehow preserve the same behavior, a new constraint is added in `erp5_base` and enabled in `erp5_configurator_standard`. Custom projects probably want to enable this constraint, but (as far as I know) we don't enable constraint by default. 
      
      This  `Base_uniqueReferenceInFolderValidator` was apparently not used anywhere else and not working anymore, so we are just removing it.
      
      
      /reviewed-on !710
      b7cc8ef9
  2. 13 Aug, 2018 1 commit
  3. 10 Aug, 2018 5 commits
  4. 09 Aug, 2018 3 commits
  5. 08 Aug, 2018 5 commits
  6. 07 Aug, 2018 2 commits
  7. 06 Aug, 2018 1 commit
  8. 03 Aug, 2018 6 commits
  9. 02 Aug, 2018 1 commit
  10. 01 Aug, 2018 2 commits
  11. 31 Jul, 2018 9 commits
  12. 27 Jul, 2018 2 commits
    • Sebastien Robin's avatar
      c9c876cf
    • Sebastien Robin's avatar
      simulation: solve random solving issues in a cluster environment · 924f20fa
      Sebastien Robin authored
      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.
      924f20fa
  13. 26 Jul, 2018 1 commit
  14. 25 Jul, 2018 1 commit