1. 06 Dec, 2017 5 commits
    • Jérome Perrin's avatar
      Merge !504 Do not save documents when there are pending activities · d3550bda
      Jérome Perrin authored
      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*):
      
      ![erp5-sorryPendingActivitiesSavePartially](/uploads/ff4bfd6ad0e8a42ba3684cccdc450e21/erp5-sorryPendingActivitiesSavePartially.gif)
      
      The changed here is to use a field validator that refused editing when there are pending activities, so that user gets a:
      
      ![erp5-pending-activiities](/uploads/bfe825560bdee34f0443e8e36884f21c/erp5-pending-activiities.png)
      
      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 nexedi/erp5!504
      d3550bda
    • Jérome Perrin's avatar
      Merge !496 Replace \r\n by \n in ZSQL Methods' arguments · 39ebb00b
      Jérome Perrin authored
      Since 76cc938e we have diffs each time we edit ZSQL Methods. This is a "big commit" to change all remaining ZSQL methods. I checked diffs one by one, but I would appreciate others check this as well and confirm that it's OK to do so.
      
      From the root of repository, I did :
      
      ```
      grep -rl Products.ZSQLMethods.SQL  . | grep '\.xml$' | xargs ~/bin/zsql_backslash_n.py
      ```
      
      With a script containing
      ```python
      #!/usr/bin/env python
      
      from lxml import etree
      import sys
      
      for filename in sys.argv[1:]:
        with open(filename) as f:
          tree = etree.parse(f)
          root = tree.getroot()
          for el in tree.xpath('//item/key/string[text() = "arguments_src"]/../../value/string'):
            if el.text:
              el.text = el.text.replace(r'\r\n', r'\n')
      
          # force <string> element to have a text, so that they export as <string></string> and not <string/>
          for el in tree.xpath('//string[not(text())]'):
            el.text = ''
      
        with open(filename, 'w') as f:
          f.write(
              '<?xml version="1.0"?>\n'
              + etree.tostring(root, pretty_print=True, encoding="utf-8"))
      
        print filename
      ```
      ( script snippet: nexedi/erp5$277 )
      
      /cc @jm @georgios.dagkakis @Nicolas
      
      /reviewed-on nexedi/erp5!496
      39ebb00b
    • Jérome Perrin's avatar
      Merge !495 Fix bank reconciliation with internal transaction · 9f3fa956
      Jérome Perrin authored
      In internal transactions, we can have a payment line where source is using a bank account and destination is using another bank account.
      
      Bank Reconciliation did not support these lines properly, because it simply assumed that *"if there's a bank reconciliation on this line, it means the line is reconciled"*, but this was incorrect, because source and destination needs to be able to reconcile this line independently.
      
      The fixes is to change the rule from *"if there's a bank reconciliation on this line, it means the line is reconciled"* to *"if there's a bank reconciliation with the same bank account as this line's source payment, it means the line is reconciled for source"* and *"if there's a bank reconciliation with the same bank account as this line's destination payment, it means the line is reconciled for destination"*.
      
      The related  key used to select the already reconciled lines or lines to reconcile becomes a bit more complex, it joins with category table to ensure the bank reconciliation's bank account  (which is `source_payment` on the bank reconciliation) is the same as the `section_uid` of the line in stock table that we are considering. This also has a side effect that this related key only work with queries on stock table, but it was never intended to be used elsewhere.
      
      Another problem is that queries made by bank reconciliation module become a bit more slower. For sites where this is a problem, the recommended approach is to replace the related keys by columns on stock table. In cfec8d2b (which is part of this MR) we add indexation methods. In 5afb002090cd965bd17ffcf5c4c54ba73dfcbfc4 (which is not part of this MR and not planned for inclusion in "default" ERP5) we show an example of how to enable these methods to actually add the columns in stock table.
      
      /reviewed-on nexedi/erp5!495
      9f3fa956
    • Jérome Perrin's avatar
      Merge !506 Persist the language cookie when changing language · a1d47205
      Jérome Perrin authored
      The fact that ERP5 does not remember the selected language has been reported as a bug to us.
      
      Instead of using a session cookie, this change make the cookie persists. For one year. This is a bit arbitrary, I copied that behavior from the "remember my username" [cookie](https://lab.nexedi.com/nexedi/erp5/blob/557c20bdf0e/product/ERP5Type/patches/CookieCrumbler.py#L138) that we use to have on the login page.
      
      /reviewed-on nexedi/erp5!506
      a1d47205
    • Jérome Perrin's avatar
      Merge !492 Normalize notification message references · b16313d1
      Jérome Perrin authored
      We realized that the references of notification messages used in credential request management had a typo (`crendential` vs `credential`) and that the message used for a new credential request was not using the same `credential_request` prefix as others.
      
      This MR changes the messages as follow:
      
      | Wrong Reference | Correct Reference |
      | --- | --- |
      | erp5-subscription.notification | credential_request-subscription |
      | crendential_request-confirmation-without-password | credential_request-confirmation-without-password |
      | crendential_request-confirmation-with-password | credential_request-confirmation-with-password |
      | crendential_request-confirmation-without-password | credential_request-confirmation-without-password |
      | crendential_recovery-reset-link | credential_recover-reset-link |
      | crendential_recovery-username | credential_recovery-username |
      
      This is an incompatible change that can affect projects that have defined some custom notification messages without explicitly setting the references on the system preferences (ie. getting the default value from the property definition).
      I found one project using custom notification messages, but preference was defined.
      Other projects I checked did not override these notification messages.
      
      In our projects, we mostly use messages for credential requests, but the reference for the notification message is usually defined as a property of the web section.
      
      So I'm confident this should not affect projects and we can proceed with this clean up without causing too much troubles. To check if you need to adjust notification messages, check if you have customized notification message with reference *Wrong Reference*.
      
      /reviewed-on nexedi/erp5!492
      b16313d1
  2. 05 Dec, 2017 3 commits
  3. 04 Dec, 2017 2 commits
  4. 01 Dec, 2017 6 commits
  5. 30 Nov, 2017 15 commits
  6. 29 Nov, 2017 2 commits
  7. 28 Nov, 2017 1 commit
  8. 27 Nov, 2017 6 commits