1. 16 Apr, 2020 2 commits
  2. 02 Mar, 2020 1 commit
  3. 28 Feb, 2020 1 commit
  4. 26 Feb, 2020 3 commits
  5. 25 Feb, 2020 1 commit
    • Tim Otten's avatar
      dev/drupal#107 - Fix user<=>contact sync used by installation workflow · ea4b2268
      Tim Otten authored
      This fixes a bug which primarily manifests for the administration during a new Civi-D8 installation.
      See: https://lab.civicrm.org/dev/drupal/issues/107
      Two ways to look at this:
      (A) Main symptom - After enabling CiviCRM on D8, you navigate to the CiviCRM dashboard and get a weird error like:
      > Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing
      > DB Constraint Violation - contact_id should possibly be marked as mandatory for DashboardContact,create API. If so, please raise a bug report.
      (B) Formal description - If (for whatever reason) a D8 user is not linked to a Civi contact, then any attempt to work with the active user/contact will fail.
      (A) Main symptom - After enabling CiviCRM on D8, you can start using CiviCRM.
      (B) Formal description - If (for whatever reason) a D8 user is not linked to a Civi contact, and if they try to use a `civicrm` page, then a
      contact will be created and linked.
      Technical Details
      This same technique has been active in Civi-D7 for years.
      The code for this technique was present in Civi-D8, but it had some comments indicating that its significance wasn't understood at the
      time of porting, and it was run at the wrong time (i.e. *after* the page-execution).
  6. 31 Jan, 2020 1 commit
  7. 29 Jan, 2020 2 commits
  8. 11 Nov, 2019 2 commits
    • Tim Otten's avatar
      composer.json - Bump up civicrm-core requirements · 754f30aa
      Tim Otten authored
      The proximate aim is to support the previous commit and 15796, though this
      is counter-intuitive.  The previous commit doesn't actually change the requirements.
      But the upstream 15796 would.
      This is the closest (imperfect) approximation we have in the current
      structure to saying, "This version of civicrm-core and civicrm-drupal-8 go
    • Tim Otten's avatar
      (dev/core#183) civicrm_requirements() - Use classloader like civicrm_install() · 6119e3ba
      Tim Otten authored
      This is an off-shoot of https://github.com/civicrm/civicrm-core/pull/15796
      inspired by https://lab.civicrm.org/dev/core/issues/183.  In 15796, the
      `Civi\Install\Requirements` class would be updated to use another helper
      class.  This relies on autoloading, and that currently fails in D8.
      * `civicrm_install()` locates Civi code (`ClassLoader.php`) and sets it up
      * `civicrm_requirements()` locates Civi code (`ClassLoader.php`) and manually
        loads a specific class file.
      * `civicrm_install()` and `civicrm_requirements()` use the same process
        to locate Civi code (`ClassLoader.php`) and initialize the classloader.
      I have one reservation here - the edge-case in which someone has tweaked out
      `civicrm.settings.php` with a non-default value of `$civicrm_root` (i.e.
      wherein `$civicrm_root !== _civicrm_find_civicrm()`).  Such a scenario may
      become more prone to duplicate-class-definition errors if
      `hook_requirements` runs in a pageview where CiviCRM is initialized.
      Some possible resolutions are:
      * Do nothing else. The edge-case may not even be real for any D8 sites.
      * Further refactor so:
          * In pre-install environments, `civicrm_install()` and `civicrm_requirements()`
            use the same process -- calling `_civicrm_find_civicrm()` and loading the classloader
          * In post-install environments, `civicrm_requirements()` and `\Civicrm::initialize()`
            use the same process -- loading `civicrm.settings.php` and `CRM/Core/ClassLoader.php`.
      (NOTE: I personally don't care about 15796 enough to do the second anytime
      soon -- I'd be just as happy letting it wait.  But since I put a bit of time
      into testing 15796, it seemed prudent to share this iteration.)
  9. 07 Nov, 2019 2 commits
  10. 29 Oct, 2019 4 commits
  11. 24 Sep, 2019 1 commit
  12. 18 Sep, 2019 2 commits
  13. 23 Aug, 2019 1 commit
  14. 21 Aug, 2019 3 commits
  15. 02 Jul, 2019 1 commit
    • Tim Otten's avatar
      civicrm.user.inc - Fix crash when creating user via drush CLI · d995cd27
      Tim Otten authored
      For test/triage/demo sites, we must generate a couple user accounts via drush CLI, e.g.
      cv core:install --cms-base-url="$CMS_URL" --plugin-path ~/src/d8plg -f
      drush8 en civicrm
      drush8 -y user-create --password="$DEMO_PASS" --mail="$DEMO_EMAIL" "$DEMO_USER"
      This addresses a crash.
      The `user-create` step crashes while handling `civicrm_user_insert()`.
      Specifically, the call to `\CRM_Core_BAO_UFGroup::getEditHTML()` fails
      because the D8 CLI environment doesn't have an active session.
      `civicrm_user_insert()` only calls `UFGroup::getEditHTML()` if it's
      likely the user-insertion occured on a relevant web-form.
      Technical Details
      The technique is ported from the CiviCRM-D7 module. In particular,
      `civicrm_on_user_page()` is copied verbatim; and in both cases,
      `civicrm_user_insert()` calls `civicrm_on_user_page()` to decide whether
      `getEditHTML()` will run.
      The overall call-path in the D7 module is *slightly* different.
      * D7: `civicrm_user_insert()` => `civicrm_register_data()` => `getEditHTML()`
      * D8: `civicrm_user_insert()` => `getEditHTML()`)
      ... but the substance of the test is similar.
  16. 28 Jun, 2019 1 commit
    • Tim Otten's avatar
      Migrate CivicrmHelper::parseUrl() to CRM_Utils_System_Drupal8::parseUrl() · 5a42eee4
      Tim Otten authored
      This fixes a bug which manifests during CLI installation. It corrects a dependency issue.
      Consider this sequence from `cv core:install` docs. (For simplicity/legibility, the example
      is minimalist.)
      $ cv core:install --cms-base-url=http://example.com/
      $ drush -y en civicrm
      Towards the end of the `core:install` step, it rebuilds the menu and winds
      up calling some `url()` functions.  But that crashes on running
      `CivicrmHelper::parseUrl()` -- because `CivicrmHelper` lives under the
      `civicrm-drupal` module, and Drupal hasn't brought the module online yet.
      That crash does not happen.
      Technical Details
      You might wonder: Will this be a flip-floppy problem?  Perhaps there's some
      dataflow through `drupal/core => civicrm-drupal/src/Routing/Routes.php`
      where the new call to `CRM_Core_Config::singleton()->userSystem->parseUrl()`
      cannot be processed because `civicrm-core` isn't available yet?
      This hypothetical can be dispensed by reading `src/Routing/Routes.php`.  The
      function already begins with `\Drupal::service('civicrm')->initialize();`,
      which boots all the core Civi services (like
      `CRM_Core_Config::singleton()->userSystem`).  The system is already online
      before the relevant code is called.
  17. 22 Mar, 2019 2 commits
  18. 11 Dec, 2018 1 commit
  19. 30 Nov, 2018 1 commit
  20. 29 Nov, 2018 1 commit
  21. 27 Nov, 2018 1 commit
  22. 26 Nov, 2018 1 commit
  23. 31 Oct, 2018 1 commit
    • Wannes De Roy's avatar
      Sync user without logout · e2480221
      Wannes De Roy authored
      Call the synchronizeUFMatch directly instead of the synchronize method. Thus avoiding the session reset of the current user.
  24. 30 Oct, 2018 1 commit
  25. 13 Sep, 2018 1 commit
  26. 03 Sep, 2018 1 commit
  27. 30 Aug, 2018 1 commit