1. 25 Apr, 2019 1 commit
  2. 11 Apr, 2019 1 commit
  3. 09 Apr, 2019 2 commits
    • eileen's avatar
    • totten's avatar
      (REF) CRM_Core_Resources - Move hook declaration from addCoreResources() to Container.php · f22fb451
      totten authored
      tldr: It's easier to declare `hook_civicrm_buildAsset` listeners at a high-level.
      Asset building can use two modes -- production mode writes a static file to
      disk when it's being reference.  Debug mode just generates a URL for a
      web-service (which in turn dynamically renders the content in a separate
      If the only mode were production mode, then the code would be on pretty
      solid ground.  We could even simplify things a lot by changing the
      AssetBuilder contract to replace the hooks with callbacks, as in:
      Civi::service('asset_builder')->getUrl('crm-menu.css', function() {
        return '...the css code...';
      Why have a hook?  Because hooks are generally context-free and
      always-available.  If we use debug-mode (or if we add a feature to warm-up
      the caches during deployment), then we'll want to fire that hook from a
      different context (e.g.  web-service or CLI), and the hook-listener needs to
      be available in those other contexts.
      It would be nice if we could declare hooks generally without needing to edit
      the `Container.php` mega-file (e.g.  maybe some kind of annotation).  But,
      for the moment, I think this is the best spot that we have in `civicrm-core`
      for ensuring that hook listeners are fully/consistently registered.
  4. 06 Apr, 2019 1 commit
  5. 05 Apr, 2019 2 commits
  6. 29 Mar, 2019 1 commit
  7. 22 Feb, 2019 1 commit
  8. 17 Feb, 2019 1 commit
  9. 05 Feb, 2019 1 commit
    • Patrick Figel's avatar
      #690 - Civi\API - Add a check on entity_table existing · 2ffa31a8
      Patrick Figel authored
      This adds a check in DynamicFKAuthorization to verify that the
      entity_table in the API request actually exists as a table.
      Additionally, this changes a test case in api_v3_AttachmentTest to
      enable permission checking. This is necessary because the change to
      DynamicFKAuthorization means trusted API calls can now attach files
      to *any* entity unless check_permissions is set, in which case it's
      only possible for allowed delegates.
  10. 04 Feb, 2019 1 commit
  11. 25 Jan, 2019 1 commit
  12. 10 Jan, 2019 2 commits
  13. 07 Jan, 2019 1 commit
  14. 04 Jan, 2019 1 commit
  15. 17 Dec, 2018 1 commit
  16. 14 Dec, 2018 6 commits
  17. 13 Dec, 2018 1 commit
  18. 03 Dec, 2018 2 commits
  19. 30 Nov, 2018 1 commit
  20. 28 Nov, 2018 1 commit
    • totten's avatar
      (#217) PrevNext - More conservative transition (5.7=>5.8=>5.9) · f76de01c
      totten authored
      This revision sets up more conservative transition process for adopting PrevNext drivers.
      * 5.7.x - Hard-coded to SQL driver.
      * 5.8.x - Allow setting to pick driver. If left as `default`, then choose best-available (based on configured services).
      * 5.7.x - Hard-coded to SQL driver.
      * 5.8.x - Allow setting to pick driver. If left as `default`, then use SQL driver.
      * 5.9.x - Allow setting to pick driver. If left as `default`, then choose best-available (based on configured services).
      This essentially mitigates the risk that bugs in the new Redis driver cause regreessions for sites already running Redis.
  21. 27 Nov, 2018 2 commits
  22. 29 Oct, 2018 1 commit
    • Andrew Hunt's avatar
      CRM-14098 Membership reminders: don't exclude people who inherit other memberships (#12510) · bb3ba83e
      Andrew Hunt authored
      * CRM-14098 Membership reminders: don't exclude people who inherit other memberships
      * Membership reminders: test had two reminders with same name, differing params
      * CRM-14098 Membership reminders: test for inherited members
      * CRM-14098: Scheduled reminders silently skipped for contacts with a non-permissioned relationship associated with ANY inherited membership type
      * Membership reminders: comments to document some shaky assumptions
      * CRM-14098 Membership reminders: fix relies on joins, causing DB error on repeat
      * CRM-14098 Membership reminders: missing alias on date field
      * CRM-14098 Reminders test: explicitly make emails primary
  23. 27 Oct, 2018 1 commit
  24. 25 Oct, 2018 1 commit
  25. 18 Oct, 2018 1 commit
  26. 28 Sep, 2018 1 commit
    • totten's avatar
      Register "short" and "long" cache services · 90cdaa0e
      totten authored
      This is an improvement for developer-experience when working with caches.
      It reduces the amount of boilerplate required for core-code or
      extension-code in a typical caching use-case.
      * To use a short-lived/latency-optimized cache (e.g. Redis or PHP array),
        you can work with the default cache instance (`Civi::cache('default')`.
      * To use a long-lived/durability-optimized cache (e.g. Redis or SQL), there is no
        simple way or code. You must [register a custom cache service](https://docs.civicrm.org/dev/en/latest/framework/cache/#example-named-service).
      * All the above remains true. Additionally, you can request the `short` or `long` cache service.
      * To use a short-lived/latency-optimized cache, you can use `Civi::cache('short')`. (`short` and `default` are synonmyms.)
      * To use a long-lived/durability-optimized cache, you can use use `Civi::cache('long')`.
      * After this is approved, we should update the [dev docs for caching](https://docs.civicrm.org/dev/en/latest/framework/cache/).
      * There's a bike-sheddy argument about the naming. I'd be willing to rename if there was a strong reason, but I don't really think
        there is a strong reason. This naming convention provides a simple dichotomy of `short` vs `long`.
  27. 27 Sep, 2018 1 commit
    • totten's avatar
      (DX) Civi::contactSettings - Add a facade for working with the logged-in user's settings · 01d70c56
      totten authored
      To read/write a setting for the logged-in user, you need a snippet like this:
      $cid = CRM_Core_Session::getLoggedInContactID();
      $myFilter = Civi::service('settings_manager')
        ->getBagByContact(NULL, $cid)
      To read/write a setting for the logged-in user, you can use a snippet like this:
      $myFilter = Civi::contactSettings()->get('activity_tab_filter');
      Technical Details
      * A convenience function like this is liable to be used in lazy circumstances where
        the developer is unlikely to check their conditions carefully. Therefore, the
        errors are reported as exceptions so that mistakes are easiliy revealed.
      * This is technically a small contract change to `SettingsManager::getBagByContact()`
        because it now interprets `$contactId===NULL` as meaning "the logged-in user".
        However, I don't think NULL was a sensible value before, and this interface
        isn't widely known/used.
  28. 30 Jul, 2018 1 commit
  29. 26 Jul, 2018 1 commit
  30. 24 Jul, 2018 1 commit