1. 10 Apr, 2019 1 commit
  2. 05 Apr, 2019 1 commit
  3. 05 Mar, 2019 1 commit
  4. 04 Mar, 2019 2 commits
  5. 25 Feb, 2019 1 commit
  6. 17 Feb, 2019 1 commit
  7. 23 Jan, 2019 1 commit
  8. 19 Dec, 2018 1 commit
  9. 13 Dec, 2018 1 commit
  10. 12 Dec, 2018 1 commit
  11. 03 Dec, 2018 1 commit
  12. 29 Oct, 2018 1 commit
  13. 26 Oct, 2018 1 commit
    • eileen's avatar
      Prevent hard error when a string is too long for a field. · 809e1a83
      eileen authored
      Over time we have had various requests to extend the length of various
      fields (currently https://github.com/civicrm/civicrm-core/pull/12939 ).
      
      The main issue is not that it matters to capture every single character of
      a crazy long user entered field - but that a hard fail when the data is too long can lose payment or registration or other data & provide a bad
      experience.
      
      This PR makes it still save, with a logged message & the utf friendly
      function in play. As of writing the api validation is stilltight - see
      ```
        // Check our field length
          throw new API_Exception("Value for $fieldName is " . strlen(utf8_decode($value)) . " characters  - This field has a maxlength of {$fieldInfo['maxlength']} characters.",
            2100, array('field' => $fieldName)
          );
        }
      ```
      and changing this is up for discussion.
      
      Note that at the UI level max field lengths can be enforced by using
      addField which uses metadata to determine field length etc
      809e1a83
  14. 30 Jul, 2018 1 commit
  15. 07 Jul, 2018 1 commit
  16. 20 Jun, 2018 1 commit
  17. 15 Jun, 2018 1 commit
  18. 06 Jun, 2018 1 commit
    • eileen's avatar
      CRM-19798 fix memory leak on EntityTag.get · ffcc1d11
      eileen authored
      This is an alternate methodology using __destruct on the DAO object.
      
      Note that I have found some places bypass this - ie.
      
      ```
         $rule = new CRM_ACL_BAO_ACL();
         $rule->query($query);
      ```
      
      But I think that is a pretty clumsy construct & we should swap to
      CRM_Core_DAO::executeQuery();
      ffcc1d11
  19. 10 May, 2018 1 commit
  20. 07 May, 2018 1 commit
  21. 02 May, 2018 1 commit
    • eileen's avatar
      Enable tests on the logging summary report. · 63dc1f23
      eileen authored
      Despite seeming like a lot of change this is mostly just extraction to run via the tests. I can break out into a couple of refactor commits for reviewablility.
      
      I have tested this on mysql 5.6 with full group by mode enabled.
      63dc1f23
  22. 01 May, 2018 1 commit
  23. 29 Apr, 2018 1 commit
  24. 19 Apr, 2018 1 commit
    • totten's avatar
      (NFC) Update version in header · fee14197
      totten authored
      This is a simple administrative update to the headers. It was generated with the command:
      
      ```
      rgrep '| CiviCRM version 4.7' CRM/ Civi ang api bin extern install/ settings/ templates -l \
        | xargs sed -i'' "s/| CiviCRM version 4.7/| CiviCRM version 5  /g"
      ```
      
      Tthe inclusion of `|` aimed to avoid matching any non-header text (e.g. inline docs that
      mentioned the version incidentally). But then I did a looser search and for just
      
      ```
      rgrep 'CiviCRM version 4.7'
      ````
      
      and manually patched the remainder.
      
      Note: I'm not really keen on doing this every month, so I relaxed the header
      statement -- instead of `CiviCRM version 5.0`, it's just `CiviCRM version 5`.
      fee14197
  25. 04 Apr, 2018 1 commit
  26. 23 Feb, 2018 1 commit
  27. 01 Feb, 2018 1 commit
  28. 25 Jan, 2018 1 commit
    • eileen's avatar
      CRM-21707 use serialisation metadata from api basic_create_fallback. · 30208fab
      eileen authored
      In order to add a unit test I enabled the same in-DAO handling on the Group BAO create
      (since core api don't use the fallback). It allowed me to remove cruft and
      to remove comments about removing cruft.
      
      With this in place a custom entity (in an extension) could define
      
          <pseudoconstant>
            <optionGroupName>group_type</optionGroupName>
          </pseudoconstant>
          <serialize>SEPARATOR_BOOKEND</serialize>
      
      and that field would accept an array of valid names that map to group_types
      and the api would handle the serialisation. api v4 supports this so good prep
      30208fab
  29. 31 Dec, 2017 1 commit
  30. 27 Dec, 2017 1 commit
  31. 14 Dec, 2017 2 commits
  32. 07 Nov, 2017 1 commit
  33. 27 Oct, 2017 4 commits
  34. 16 Aug, 2017 1 commit
  35. 17 Jul, 2017 1 commit
    • totten's avatar
      CRM_Utils_SQL_Select - Allow fluent query execution · 77e74ae1
      totten authored
      When I first wrote `CRM_Utils_SQL_Select`, I was a bit dogmatic about
      loose-coupling and wanted the class to be entirely independent of the SQL
      runtime. But this is a bit annoying in usage and training.
      
      Before
      ======
      
      To build and execute query, you had to pass the rendered SQL to the execute
      function, eg
      
      ```php
      $select = CRM_Utils_SQL_Select::from('mytable')
        ->select('...')
      $dao = CRM_Core_DAO::executeQuery($select->toSQL());
      while ($dao->fetch()) { ... }
      ```
      
      After
      =====
      
      You can use more fluent style:
      
      ```php
      $dao = CRM_Utils_SQL_Select::from('mytable')
        ->select('...')
        ->execute();
      while ($dao->fetch()) { ... }
      ```
      
      And you can chain with other DAO functions like `fetchAll()` or
      `fetchValue()`.
      
      ```php
      $records = CRM_Utils_SQL_Select::from('mytable')
        ->select('...')
        ->execute()
        ->fetchAll();
      ```
      77e74ae1