1. 01 May, 2018 1 commit
  2. 29 Apr, 2018 2 commits
  3. 28 Apr, 2018 2 commits
  4. 23 Apr, 2018 1 commit
  5. 20 Apr, 2018 1 commit
  6. 19 Apr, 2018 3 commits
  7. 18 Apr, 2018 4 commits
    • Seamus Lee's avatar
      Merge pull request #11963 from JMAConsulting/dev-mail-8 · 2afb0e6b
      Seamus Lee authored
      (dev/mail/8) Using ACL to restrict mailing recipients leads to fatal error
      2afb0e6b
    • Seamus Lee's avatar
      Merge pull request #11984 from eileenmcnaughton/5.1.1 · 848b77eb
      Seamus Lee authored
      Fix trigger generation for modified_date on custom data
      848b77eb
    • totten's avatar
      VersionCheck - Get more nuanced messages from latest.civicrm.org · 88790378
      totten authored
      Overview
      ----------------------------------------
      Get fully-formed upgrade messages from `latest.civicrm.org`. This allows us to convey more nuanced information about available upgrades.
      It also allows us to iterate more quickly on how releases are presented (e.g. adding hyperlinks to the blog/changelog, highlighting
      important changes, introducing the in-between status `deprecated`).
      
      Before
      ----------------------------------------
      The `VersionCheck` helper sends a request to `latest.civicrm.org` with `format=json` to get a list of all available versions.
      
      Then it digests the information and presents any messages in the `CRM_Utils_Check` layer.
      
      After
      ----------------------------------------
      The `VersionCheck` helper sends a request to `latest.civicrm.org` with `format=summary` to get a list of displayable messages.
      
      Then it presents any messages in the `CRM_Utils_Check` layer.
      
      Technical Details
      ----------------------------------------
      
      * Because patch-releases are allowed mid-month, this patch also reduces the TTL from 7 days to 3 days.
      * Test coverage is reduced here (`civicrm-core`), but it's improved a lot elsewhere (`latest.civicrm.org`).
      * In `VersionCheck`, it makes a few contract changes (which have been evaluated by grepping for stale references circa 4.7.31). Specifically:
          * Add `getVersionMessages()`
          * Remove unnecessary members `$localMajorVersion`, `getMajorVersion()`, `isNewerVersionAvailable()`, `checkBranchForNewVersion()`
          * Change the content of `versionInfo`. It's still a cache of the web-service response, but now it's a list of displayable messages (rather than a list of all versions).
      88790378
    • deb.monish's avatar
      use Civi::static in place of static variable · 04adc5f0
      deb.monish authored
      04adc5f0
  8. 17 Apr, 2018 2 commits
    • Monish Deb's avatar
      Merge pull request #11976 from eileenmcnaughton/5.1 · e7a0106f
      Monish Deb authored
      Fix failure to render dedupe page
      e7a0106f
    • eileen's avatar
      Fix trigger generation for modified_date on custom data · 6bbc383d
      eileen authored
      In 4.7.25 https://github.com/civicrm/civicrm-core/pull/10754/commits introduced
      some modifications to the generation of triggers to update the modified date field.
      
      It basically derived the entity being extended by a table and then if that entity had a
      modified_date field then a trigger would be created to update that field.
      
      However, a bug in the CRM_Core_BAO_CustomGroup::getAllCustomGroupsByBaseEntity function
      meant that incorrect additional tables are also being updated for custom fields.
      
      For entities extending contact the contact table AND the mailing table are updated. e.g
      ```
      CREATE TRIGGER {mycustomtable}...
      UPDATE civicrm_contact SET modified_date = CURRENT_TIMESTAMP WHERE id = NEW.entity_id;
      
      UPDATE civicrm_mailing SET modified_date = CURRENT_TIMESTAMP WHERE id = NEW.entity_id;
      ```
      
      For entities that extend tables that should not attract a trigger ONLY
      the mailing table is updated.
      
      The bug in CRM_Core_BAO_CustomGroup::getAllCustomGroupsByBaseEntity is that it adds the
      WHERE clause 'AND extends IN ($entityType)' ONLY if $entityType is in a whitelist.
      
      Invalid entities result in no filtering.
      
      As a fix using a whitelist is no longer valid - we support any entity that might
      be configured now so simply filtering on the entity makes sense.
      
      Other paths to this function seem unlikely to pass in invalid entities & hence trigger this bug.
      6bbc383d
  9. 16 Apr, 2018 2 commits
  10. 05 Apr, 2018 1 commit
  11. 04 Apr, 2018 21 commits