1. 14 May, 2019 1 commit
  2. 11 May, 2019 3 commits
  3. 06 May, 2019 1 commit
  4. 05 May, 2019 1 commit
  5. 30 Apr, 2019 3 commits
  6. 09 Apr, 2019 1 commit
  7. 08 Apr, 2019 1 commit
  8. 06 Apr, 2019 1 commit
  9. 05 Apr, 2019 2 commits
  10. 04 Apr, 2019 2 commits
  11. 02 Apr, 2019 1 commit
  12. 29 Mar, 2019 1 commit
  13. 28 Mar, 2019 1 commit
  14. 20 Mar, 2019 1 commit
    • eileen's avatar
      Fix Contact.create calls to respect passed in variables & variables set via... · 1bdbd4ec
      eileen authored
      Fix Contact.create calls to respect passed in variables & variables set via hook for sort_name & display_name
      This has been applied to Organizations & Households, not Individuals at this stage as that is more complex.
      Use case is saving organizations with The so that The is at the end of their sort_name, making it easier to
      deal with data entry variations
  15. 14 Mar, 2019 2 commits
    • eileen's avatar
      Add unit test on validate · a1a01300
      eileen authored
    • eileen's avatar
      Support calling ContributionPage.validate in POST context. · dbc654ec
      eileen authored
      Because the validation data is buried deep within the form we need to load the form
      in order to validate - but currently the validKey check borks in post requests.
      Note the validity of credit card details is not checked when submitting this form,
      other than possibly the luhn validation.
       A likely use case for the validation is when the is being submitted and some handling is
       to be done before processing but the validity of input needs to be checked first.
       For example Paypal Checkout will replace the confirm button with it's own but we are able to validate
      before paypal launches it's modal. In this case the  is post but we need validation to succeed.
  16. 13 Mar, 2019 2 commits
  17. 22 Feb, 2019 2 commits
    • eileen's avatar
      Rationalise Activity api ACLs · cdacd6ab
      eileen authored
      We have a lot of inconsistency about how (and if) activity ACLs are applied. Note that permissions only apply
      when the api is being called with check_permissions = TRUE - e.g from the js layer.
      This PR changes the logic used for the activity.get api to be consistent with the report logic
      a) is the most performant variant
      b) is the one with the least code complexity
      c) is more consistent with CiviCase
      d) allows hooks to modify the permissions applies
      e) creates consistency between api v3 & v4
      f) is consistent with some site user expectations but not others - the presence of all this inconsistency
      is an indicator not everyone wants the same thing but given that choosing a performant &
      maintainable option for core seems like a good criteria.
      After this patch
      1) the 'view all activities' permission will no longer by-pass all other ACLs. One could argue that's exactly
      what it means - but it doesn't do that in the UI which seems like the standard elsewhere.
      2) a user will be able to view an activity via the api if they have permission to view  ANY contact linked to it (before it was ALL contacts via the api)
      3) a user will not see the names of any contacts they do not have permission over when requesting activity contact details in return parameters
      4) getcount will no longer by-pass the api
      5) performance is improved
      Places where permissioning applies to activities
      - activities listing on contact - shows actitivies & related contact names regardless of permission to view the contacts
      - activity search results -- shows actitivies & related contact names regardless of permission to view the contacts
      - activity view page - links to view the activity exist on the above 2 screens but will give access denied unless they
      can see ALL related contacts
      - activity reports - shows activities if ANY related contacts are permitted, suppresses names of unpermitted contacts
      Potential follow on steps
      1) make the activity tab listing consistent by switching from the unperformant deprecatedGetActivities fn
      to the performance getActivities fn - there are no remaining blockers to that.
      2) align the activity view screen & add in hook call there too
      3) align activity search results screen, address performance issues there too....
    • Seamus Lee's avatar
      security/core#26 Add in a generated Hash to download files so that URLs can't... · ff9aeadb
      Seamus Lee authored
      security/core#26 Add in a generated Hash to download files so that URLs can't just be tested by annon users
  18. 20 Feb, 2019 1 commit
  19. 16 Feb, 2019 2 commits
  20. 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
  21. 05 Feb, 2019 1 commit
  22. 04 Feb, 2019 2 commits
  23. 22 Jan, 2019 2 commits
  24. 16 Jan, 2019 1 commit
  25. 14 Jan, 2019 2 commits
  26. 13 Jan, 2019 1 commit
  27. 09 Jan, 2019 1 commit