1. 26 May, 2020 3 commits
  2. 25 May, 2020 4 commits
  3. 24 May, 2020 1 commit
  4. 23 May, 2020 1 commit
  5. 22 May, 2020 2 commits
  6. 21 May, 2020 1 commit
    • eileen's avatar
      Fix pricefield pseudoconstant. · 4f238b49
      eileen authored
      The price field turns out not to be returning pseudoconstant fields for 2 reasons
      1) the label field is defined but the name field is not
      2) any price fields with no domain are filtered out. In my single domain db this is
      all of them.
      
      I think we can safely understand NULL domain_id as 'not restricted by domain'. For some tables
      (membershipType) it is a required field but for PriceField it is not.
      
      I would be inclined to say it should be required less often. However, where it is required thenn
      the OR IS NULL should never be true
      4f238b49
  7. 20 May, 2020 1 commit
  8. 19 May, 2020 2 commits
  9. 17 May, 2020 1 commit
  10. 15 May, 2020 5 commits
  11. 14 May, 2020 2 commits
  12. 13 May, 2020 8 commits
  13. 12 May, 2020 1 commit
  14. 10 May, 2020 1 commit
  15. 09 May, 2020 3 commits
  16. 08 May, 2020 1 commit
    • totten's avatar
      SyntaxConformanceTest::testSqlOperators - Fix failure on MySQL 8 · 5d60cab9
      totten authored
      Before
      ------
      
      `SyntaxConformanceTest::testSqlOperators` frequently fails on the `Dedupe` entity when running on MySQL 8 (`bknix-edge`).
      
      After
      ------
      
      `SyntaxConformanceTest::testSqlOperators` repeatedly passes for all entities on my copy of MySQL 8 (`bknix-edge`).
      
      Technical Details
      -----------------
      
      The `testSqlOperators` creates a small pool of example records
      (`$entities`), then it slices/dices that pool with a few SQL operators and
      asserts the number of matches.
      
      In particular:
      
      ```php
      $this->callAPISuccessGetCount($entityName, ['id' => ['>' => $entities[0]]], $totalEntities - 1);
      ```
      
      The problem is that `$entities[0]` does not necessarily have the lowest ID
      -- because `$entities` was not fetched in any particular order.  The default
      ordering is *often* the same as the `id`, but not always.
      
      I suspect that this problem manifests most frequently with the `Dedupe`
      entity because the underlying table (`civicrm_prevnext_cache`) is highly
      volatile (many writes+deletes) -- thus it's more likely to reuse old storage
      slots for new rows.
      5d60cab9
  17. 07 May, 2020 3 commits