1. 10 Apr, 2019 1 commit
  2. 09 Apr, 2019 1 commit
  3. 07 Apr, 2019 1 commit
  4. 05 Apr, 2019 1 commit
  5. 04 Apr, 2019 2 commits
    • eileen's avatar
    • eileen's avatar
      financial#2 add PaymentProcessor.title field · 63b162c6
      eileen authored
      There was a long discussion a while back about adding a label or title field to the
      civicrm_payment_processor table. It kinda died but since 5.13 adds another field
      (contribution_recur.cancel_reason) which is kinda rare I thought we should probably
      add this field in the same release as we can better keep most releases to no
      schema changes that way.
      At this stage the field is not in use - but I figure getting it added will make the
      next steps of exposing it easier & there is general agreement we need
      something of this nature.
      (the cancel reason field will also take further commits to expose in the UI)
  6. 19 Mar, 2019 1 commit
  7. 16 Mar, 2019 1 commit
  8. 07 Mar, 2019 1 commit
    • eileen's avatar
      [REF] small cleanups on payment.create flow. · 54ec4839
      eileen authored
      In the interests of keeping some momentum I added this small cleanup which does 3 things
      1) uses the preferred function to get 'from_financial_account_id', 2 moves a line of code to get participantID
      & 3 removes the conditionals around is_payment. This probably needs the most double checking but
      I believe recordPartialPaymet used to be called from places other than Payment.create so
      it may not have always been handling a payment - however it I can't see a case for it not be
      is_payment now
  9. 04 Mar, 2019 2 commits
  10. 01 Mar, 2019 1 commit
  11. 28 Feb, 2019 2 commits
    • Edselopez's avatar
    • eileen's avatar
      Decommision getPartialPaymentTrxn function · 74e4c3c2
      eileen authored
      This function is only called from one place in the code & also from a test.
      It is misleading as it implies a 'get' when it actually does an update
      and it groups functionality in a way that doesn't make sense from the calling code pov
      In this commit the function is removed and the lines are directly copied to the calling
      function, as preparation for cleaning up the calling function
  12. 26 Feb, 2019 1 commit
  13. 25 Feb, 2019 3 commits
  14. 21 Feb, 2019 1 commit
  15. 20 Feb, 2019 1 commit
    • eileen's avatar
      Code cleanup - remove extraneous permissions clase · 49f92712
      eileen authored
      As the test demonstrates this permission is applied without this line. It is applied
      even when the skipPermission is TRUE but that has been code-commented for now rather
      than resolved
  16. 19 Feb, 2019 4 commits
  17. 15 Feb, 2019 3 commits
  18. 13 Feb, 2019 1 commit
    • eileen's avatar
      Add new Payment.sendconfirmation api · a79d2ec2
      eileen authored
      This adds a new api Payment.sendconfirmation intended to be an equivalent of
      The key thing this needs to be able to do is to load up all
      related information to assign to the template - this is not all covered in this
      PR & until it is functionally equivalent to AdditionalPayment::sendEmail
      we can't switch over but since it's new functionality we should be able to
      merge & keep working on it.
      Note that there is discussion on the PR this relates to (#13330) about what should
      happen if 'Payment.create' api accepts 'is_email_receipt'. I think the most logical
      outcome is that receipts would go out if it caused the contribution to be completed
      (ie. we pass is_email_receipt into completetransaction api).
      However, I don't feel like that is 'settled' yet - separating into a second api
      (Payment.sendnotification) means we will have 2 generic function which can be called
      from multiple places in the code rather than 2 functions tightly tied to the form layer.
      I think it's OK if it is 2 not one
  19. 28 Jan, 2019 1 commit
    • eileen's avatar
      Add ACL hook call and test to financial ACLs · c77f8667
      eileen authored
      If the hook call changes the where cause we will not implement the
      core pseudo-hook-code for financial type acls.
      This allows us to not conflict with reportfinancialacls extension
      Eventually we will not have any of this in core other than the hook.
  20. 14 Jan, 2019 1 commit
  21. 13 Jan, 2019 1 commit
  22. 13 Dec, 2018 3 commits
  23. 01 Dec, 2018 1 commit
  24. 30 Nov, 2018 1 commit
  25. 22 Nov, 2018 1 commit
  26. 24 Oct, 2018 1 commit
  27. 17 Oct, 2018 1 commit
  28. 20 Sep, 2018 1 commit