1. 26 Feb, 2017 2 commits
  2. 25 Feb, 2017 4 commits
  3. 24 Feb, 2017 6 commits
    • colemanw's avatar
      Merge pull request #9894 from JKingsnorth/CRM-20175 · 110647e9
      colemanw authored
      CRM-20175 Increase pager support
    • JKingsnorth's avatar
      CRM-20175 Increase pager support · fe00912d
      JKingsnorth authored
    • colemanw's avatar
      Merge pull request #9892 from totten/master-depr · 2e6498b8
      colemanw authored
      MailingGroup API - Tighten up deprecations
    • totten's avatar
      MailingGroup API - Tighten up deprecations · a8b7230d
      totten authored
      The `MailingGroup.php` includes some very different APIs, e.g.
       * Several 'event'(subscribue/resubscribe) APIs
       * Some CRUD APIs for mailing data
      The deprecation applies to the 'event' (subscribe/resubscribe) APIs --
      because those can be done another way.  However, the CRUD for `MailingGroup`
      records is the only way to do access that data.
    • eileen's avatar
      Merge pull request #9885 from eileenmcnaughton/search · bf3a3162
      eileen authored
      CRM-19815, CRM-19830 make pseudoconstant handling more generic in order to improve performance
    • eileen's avatar
      Towards CRM-19815 make pseudoconstant handling more generic. · 86ab13b7
      eileen authored
      Using metadata pseudoconstants we can remove joins on the option_value table, which hur performance. This patch
      only opens it up within the context of the Contact table. It is intended to open the code up to
      allow us to extend the performance advantage of dropping the bad join to other entities.
      The following fields have metadata links to the
      option_value table:
      The general pattern for the api is to return (eg) communication_style_id = 1, communication_style = 'Formal', where communication_style is the db name of the option group for communication_style_id.
      preferred_communication_method is the exception. For api calls it returns an array of ids like all other api calls.
      However, it returns a string of names for non-api calls on that field, allowing us to avoid handling it in a number of other places.
      I added tests to ensure no change on the api inputs & outputs and searched these fields through search builder & advanced
      search + export. I also checked profile search listings. They are not using the convert routine & have some e-notices that
      pre-existed, but no regression I could see.
  4. 23 Feb, 2017 10 commits
  5. 22 Feb, 2017 9 commits
  6. 21 Feb, 2017 3 commits
  7. 20 Feb, 2017 3 commits
  8. 19 Feb, 2017 2 commits
  9. 18 Feb, 2017 1 commit