1. 04 Apr, 2018 4 commits
    • Jérome Perrin's avatar
      Merge !495 Fix bank reconciliation with internal transaction · f22ec5fb
      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
      f22ec5fb
    • Jérome Perrin's avatar
      Merge !492 Normalize notification message references · 8531caaf
      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 !492
      8531caaf
    • Jérome Perrin's avatar
      Merge !497 Allow Associate to share and release on document_publication_workflow · aaf2fcbe
      Jérome Perrin authored
      The background:
      
      Following up nexedi/erp5!393 , we updated security configuration used in Nexedi ERP5 , we wanted to add a security rule so that users uploading a `Personal/Private` document are allowed to "share" that document (technically, it's sharing with themselves only because it's a private document, but it's useful to distinguish from drafts).
      
      Then we discovered that in the current workflow configuration, only `Assignor` role is allowed to *share*, but `Assignor` is also allowed to *publish*, but we did not want users to publish their personal documents..
      
      ---
      Original commit message:
      
      Previously, only Assignor was able to publish, share and release, this
      make it impossible to have security configuration where some user can
      only share and not publish documents.
      
      To address this issue in the more backward compatible way possible, we
      enable these transitions for Associate and keep them enabled for
      Assignor role.
      
      /reviewed-on nexedi/erp5!497
      aaf2fcbe
    • Jérome Perrin's avatar
      Merge !393 dms: do not grant permissions based on Owner role · eba8d3ae
      Jérome Perrin authored
      My use case is that we have an ERP5 configuration where a PDF document is "implictly" created when user validate an invoice. Later this PDF becomes "secret" and we want to remove permissions on the PDF to all except a small  group of users.
      
      Please also read commit message for more uses cases.
      
      My idea is to change globally document publication workflow to remove permissions for Owner, because usually in workflow we don't have security for Owner, except in draft states.
      For cases where the user who created the document must have certain permissions for the whole lifetime of the document, we can create a security rule where this user would be Associate.
      Also, for the case of documents, maybe we would want to use *Contributors* fields instead of Owner, as it gives more flexibility.
      
      In what I am suggesting, the permissions by state would change from:
      
      ![Screenshot_2017-09-15_at_16.12.53](/uploads/5b3664a2663deb893ea4f8fc9858a52f/Screenshot_2017-09-15_at_16.12.53.png)
      
      to:
      
      ![Screenshot_2017-09-15_at_17.34.34](/uploads/95803dc89e1a2501c29872a6a5131c33/Screenshot_2017-09-15_at_17.34.34.png)
      
      The full updated `document_publication_workflow` specification would be:
      
      [P-ERP5.Workflow.Security.After.Removing.Owner.pdf](/uploads/02eac46ec436385d0d0577695803b3b5/P-ERP5.Workflow.Security.After.Removing.Owner.pdf)
      
      But this is an incompatible change, because some users will loose access to some documents they use to have access.
      
      /reviewed-on nexedi/erp5!393
      eba8d3ae
  2. 03 Apr, 2018 4 commits
  3. 30 Mar, 2018 17 commits
  4. 29 Mar, 2018 5 commits
  5. 27 Mar, 2018 10 commits