1. 14 May, 2019 1 commit
  2. 11 May, 2019 2 commits
  3. 10 May, 2019 4 commits
  4. 06 May, 2019 1 commit
  5. 02 May, 2019 4 commits
  6. 30 Apr, 2019 4 commits
    • totten's avatar
      (flexmailer#29) civicrm/mailing/view - Generate content via Mailing.preview API · 640d3ea6
      totten authored
      A root cause of flexmailer#29 is that the flexmailer has to override
      multiple parts of CiviMail.  Case in point: it overrides the
      `civicrm/mailing/view` and forces it to generate content via
      `Mailing.preview` API.  This is unfortunate because flexmailer's variant is
      missing other features (regarding permissioning and contact IDs).
      
      This revision makes it unnecessary for flexmailer to override
      `civicrm/mailing/view`.
      640d3ea6
    • eileen's avatar
      Fix deprecation handling · c3d06508
      eileen authored
      Turns out we were one of the sites naughtily using the BAO directly who needed this handling
      to work - but because we passed a number in quote it didn't - this fixes
      c3d06508
    • totten's avatar
      CiviMail - Restore support for previewing mailing-tokens via TokenProcessor/Flexmailer · fa373cad
      totten authored
      See preceding commit for general description - this simply applies the same
      concept for another set of tokens.
      fa373cad
    • totten's avatar
      CiviMail - Restore support for previewing action-tokens via TokenProcessor/Flexmailer · e026b9e4
      totten authored
      Overview
      --------
      
      When using `TokenProcessor` to generate a mailing (e.g.  as with Flexmailer/Mosaico), the action-tokens (e.g.
      `{action.optOutUrl}`) are generated via `CRM_Mailing_ActionTokens`.  To properly generate them,
      `CRM_Mailing_ActionTokens` relies on certain information (e.g.  mailing/job ID).  However, that information is no
      longer available when performing a "Preview" -- leading to misbehavior in previews.  This patch allows Flexmailer to
      restore parity for previewing those tokens.
      
      Before (Pre-5.6)
      ----------------
      
      * When a user begins composing a mailing, CiviMail creates a draft mailing with a concrete ID (e.g.  `mailing #123`).
      * To preview the mailing, the UI calls `Mailing.preview` API with the ID of the mailing.
      * Flexmailer/Mosaico generates the preview by calling `TokenProcessor` and therefore `CRM_Mailing_ActionTokens`.
      * `CRM_Mailing_ActionTokens` has strictness checks. These pass because the ID is available.
      
      Before (5.6-5.12)
      ----------------
      
      As a performance enhancement, CiviCRM 5.6 (PR #12509; [mail#20](mail#20)) revised
      the signature for `Mailing.preview` API to allow previews *without* having a specific mailing record/job/ID. Consequently:
      
      * When a user begins composing a mailing, CiviMail creates a draft mailing with a concrete ID (e.g.  `mailing #123`).
      * To preview the mailing, the UI calls `Mailing.preview` API ~~with~~ **without** the ID of the mailing.
      * Flexmailer/Mosaico generates the preview by calling `TokenProcessor` and therefore `CRM_Mailing_ActionTokens`.
      * `CRM_Mailing_ActionTokens` has strictness checks. These ~~pass~~ **fail** because the ID is ~~available~~ **unavailable**.
      
      After
      ----------------
      
      * When a user begins composing a mailing, CiviMail creates a draft mailing with a concrete ID (e.g.  `mailing #123`).
      * To preview the mailing, the UI calls `Mailing.preview` API ~~with~~ **without** the ID of the mailing.
      * Flexmailer/Mosaico generates the preview by calling `TokenProcessor` and therefore `CRM_Mailing_ActionTokens`.
      * `CRM_Mailing_ActionTokens` has ~~strictness~~ **less strict** checks. These **pass** because the `context[schema]` hints that
        a mailing ID *will be available* when needed.
      e026b9e4
  7. 27 Apr, 2019 1 commit
  8. 23 Apr, 2019 1 commit
  9. 20 Apr, 2019 1 commit
  10. 18 Apr, 2019 1 commit
  11. 17 Apr, 2019 1 commit
  12. 16 Apr, 2019 1 commit
    • colemanw's avatar
      Remove unnecessary d7 script · de8d1a87
      colemanw authored
      This is now obsolete due to the new SmartMenus, the drupal tool-drawer
      is no longer in the way of dialogs.
      de8d1a87
  13. 15 Apr, 2019 1 commit
    • eileen's avatar
      #534 Re-instate pay-now button · 10f949e6
      eileen authored
      This is regression - likely for a few months? Fix adds a unit test & does some additional tidy up
      
      We should consider for 5.12
      10f949e6
  14. 13 Apr, 2019 1 commit
    • totten's avatar
      (NFC) SchemaStructure.php - Fix up mismatch between stored+generated code · 3eb2aab1
      totten authored
      Overview
      --------
      
      The class `CRM_Core_I18n_SchemaStructure` is autogenerated via GenCode, and it is also commited to git.
      The two forms don't match because of the recent code-style cleanup.
      
      Before
      ------
      
      After running GenCode, there appears to be uncommitted changes in `CRM_Core_I18n_SchemaStructure`.
      The changes indicate a reversion in code-style (e.g. `null` vs `NULL`; some whitespace).
      
      After
      -----
      
      GenCode produces output which matches the recent cleanup.
      
      Comments
      --------
      
      Fixing `null` / `NULL` was easy. However, the whitespace mismatch was more subtle -- because the
      `PHP_Beautifier` was messing it up. To resolve, I disabled `PHP_Beautifier` for this file, and fixed
      the underlying templates to generate well-formed code.
      
      The output of the process matches the existing code; therefore, the change
      have no functional impact (NFC).  You can see this by running `setup.sh` and
      checking the `git status`.
      3eb2aab1
  15. 11 Apr, 2019 5 commits
  16. 10 Apr, 2019 6 commits
  17. 09 Apr, 2019 4 commits
    • gitsync's avatar
      Set version to 5.13.beta1 · fb1a4c6f
      gitsync authored
      fb1a4c6f
    • eileen's avatar
      Load hooks during upgrade mode · 62f662b0
      eileen authored
      For unknown, svn, reasons extension hooks are not loaded during upgrade
      (this doesn't apply to drupal modules) - this causes some fairly serious problems
      1) settings are re-loaded & cached with settings from extensions being lost
      2) trigger alter hooks are lost this means
       - the summary fields triggers are frequently lost on upgrade
       - hooks that unset various tables to prevent them from being logged can fail, resulting in those log tables being created
       - hooks that specify the table should be innodb can fail to run, resulting in archive format.
      
      I can't think WHY we do this? Presumably there was some problem that would have been better solved another
      way but which was solved this way?
      
      Fix "Load hooks during upgrade mode" (45312e1e64dd6af0281fe5fb7f96dbd8be39e524)
      
      In my testing, the commit doesn't do what it says because the symbols are wrong.
      62f662b0
    • eileen's avatar
      Update new payment_processor.title field to be localisable · 4c257e17
      eileen authored
      Re-order upgrade to fix upgrade process and ensure there is the runSql step
      4c257e17
    • 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
      page-view).
      
      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:
      
      ```php
      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.
      f22fb451
  18. 08 Apr, 2019 1 commit
    • totten's avatar
      Pass menubar preference as a param. Simplify cache mechanics. (#8) · 08a3a519
      totten authored
      Ex: If an admin uses an API call (CLI/REST) to change the menubar color,
      then they don't need to follow-up with a cache-clear.  The new setting just
      goes live.
      
      Ex: If a customization (via `civicrm.settings.php` or via extension) decides
      on the color scheme programmatically (e.g.  per-domain or per-role or
      per-user-preference), then they don't need to clear cache.  Multiple color
      schemes can coexist.
      08a3a519