forked from civicrm/civicrm-core
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test 1 2 3 #2
Merged
Merged
test 1 2 3 #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…_entity_financial_trxn for entity civicrm_financial_item
…nancial trxn ---------------------------------------- * CRM-15848: Civiaccounts inconsistent with spec when adding partial event payment https://issues.civicrm.org/jira/browse/CRM-15848
…rm (useful for buildForm hooks).
---------------------------------------- * CRM-15848: Civiaccounts inconsistent with spec when adding partial event payment https://issues.civicrm.org/jira/browse/CRM-15848
---------------------------------------- * CRM-16198: Financial Type search fails when searching Contributions using Search builder https://issues.civicrm.org/jira/browse/CRM-16198
CRM-16201 Descriptions and translation for permissions
---------------------------------------- * CRM-16201: Permission descriptions and translation https://issues.civicrm.org/jira/browse/CRM-16201
---------------------------------------- * CRM-16198: Financial Type search fails when searching Contributions using Search builder https://issues.civicrm.org/jira/browse/CRM-16198
---------------------------------------- * CRM-13793: Miscellaneous code cleanups https://issues.civicrm.org/jira/browse/CRM-13793
CRM-16201 permissions: fix processing of descriptions for Joomla
-- CRM-15848, removed code to update financial_trxn table and create a n...
Fix bad copy of civicrm_generated.mysql.
---------------------------------------- * CRM-16206: Revised Upgrade Success Message https://issues.civicrm.org/jira/browse/CRM-16206
---------------------------------------- * CRM-16087: Changes in relationship status are not invoking updates to membership status https://issues.civicrm.org/jira/browse/CRM-16087
Webtest for new AB Test Mailing
CRM-16087 - Changes in relationship status are not invoking updates to m...
-- CRM-13793, removed cruft for website type id for profiles
CRM-16280 remove NOT NULL from upgrade sql to reflect schema & resolve u...
CRM-15908 additional fix
Changes needed to CRM_Utils_System_Drupal8
Don't call into Drupal from Civicrm to build navigation menu. See CRM-15132
seamuslee001
pushed a commit
that referenced
this pull request
Jun 11, 2015
Add default of current timestamp to the create_datek
seamuslee001
pushed a commit
that referenced
this pull request
Aug 28, 2015
Fixed spelling of 'memebership' in 625
seamuslee001
pushed a commit
that referenced
this pull request
Oct 15, 2015
CRM-17385 - CRM_Extension_BrowserTest
seamuslee001
pushed a commit
that referenced
this pull request
Jun 8, 2016
Merge two patches into single patch.
seamuslee001
added a commit
that referenced
this pull request
Oct 11, 2016
seamuslee001
pushed a commit
that referenced
this pull request
Oct 29, 2017
CRM-21061 run re-gen and add in Upgrade step
seamuslee001
pushed a commit
that referenced
this pull request
Nov 29, 2017
seamuslee001
pushed a commit
that referenced
this pull request
Oct 29, 2018
…ing filters Suppose you run a search ("Find Contact", "Advanced Search", "Custom Search", etc). The result screen includes several elements (which we'll reference below): 1. Standard pagination (Previous/Next; First/Last; Jump-To) 2. Numerical option for page-size 3. Sortable columns 4. An alphabetical filter 5. Checkboxes As you work with these options, the content of the `civicrm_prevnext_cache` table may change. This patch does not substantively change what's in that cache, but makes the column `cacheKey` simpler and more consistent. Both Before and After (Unchanged) --------------------------------- * The form's qfKey identifies the current screen/filters/cache. * If you navigate to the next/previous page (`#1`) or adjust the page-size (`#2`), the content in `civicrm_prevnext_cache` remains the same (for the given qfKey). * If you change the sort column (`#3`) or alphabetic filter (`#4`), the content in `civicrm_prevnext_cache` is deleted and repopulated (for the given qfKey). * If you toggle a checkbox, the `civicrm_prevnext_cache.is_selected` property updates accordingly. These selections are retained when changing pages (`#1`/`#2`), but they're reset if you use sort or alphabet options (`#3`/`#4`). Before ------ * The content of `civicrm_prevnext_cache.cacheKey` takes one of two forms, depending on whether you're using an alphabetic filter (`#4`). * `civicrm search {qfKey}` (typical, without any alphabetic filter) * `civicrm search {qfKey}_alphabet` (less common, with an alphabetic filter) * The queries which read or delete the query-cache use a prefix+wildcard, i.e. `WHERE cacheKey LIKE 'civicrm search {qfKey}%'`. After ----- * The content of `civicrm_prevnext_cache.cacheKey` takes only one form * `civicrm search {qfKey}` * The queries which read or delete the query-cache use an exact match, i.e. `WHERE cacheKey = 'civicrm search {qfKey}'`.` * The text `_alphabet` does not appear in the PHP source folders (CRM, Civi, bin, api, extern, tests). Comments -------- In theory, one can imagine that it's desireable to keep the cached results for each of the sorted/filtered variants of the query. That might allow the user to quickly switch among different sortings and different alphabetic-filters, or it might allow some kind of clever management of the selections. But this is not so. As we see (both before and after), the substance of the cache is deleted whenever the user changes `#3`/`#4`. In reality, one user browsing a search screen corresponds to exactly one query-cache. As near as I can tell, the old code made the names change for no real reason at all. To observe the behavior empirically, I would twiddle the UI widgets and concurrently inspect the content of the cache tables. For example: ``` mysql> select group_name, path, FROM_BASE64(data), expired_date from civicrm_cache where path like 'civicrm search%'; select 'Total records in' as label, cacheKey, count(*), min(id), max(id) from civicrm_prevnext_cache group by cacheKey union select 'Selected records in ', cacheKey, count(*), min(id), max(id) from civicrm_prevnext_cache where is_selected=1 group by cacheKey; +------------------------------+------------------------------------------------------+--------------------------------------------------------------+--------------+ | group_name | path | FROM_BASE64(data) | expired_date | +------------------------------+------------------------------------------------------+--------------------------------------------------------------+--------------+ | CiviCRM Search PrevNextCache | civicrm search a8ed1e2039241c41457a88f65aa8a8ee_7845 | s:52:"civicrm search a8ed1e2039241c41457a88f65aa8a8ee_7845"; | NULL | +------------------------------+------------------------------------------------------+--------------------------------------------------------------+--------------+ 1 row in set (0.00 sec) +----------------------+------------------------------------------------------+----------+---------+---------+ | label | cacheKey | count(*) | min(id) | max(id) | +----------------------+------------------------------------------------------+----------+---------+---------+ | Total records in | civicrm search a8ed1e2039241c41457a88f65aa8a8ee_7845 | 6 | 787 | 792 | | Selected records in | civicrm search a8ed1e2039241c41457a88f65aa8a8ee_7845 | 1 | 789 | 789 | +----------------------+------------------------------------------------------+----------+---------+---------+ 2 rows in set (0.01 sec) ```
seamuslee001
pushed a commit
that referenced
this pull request
Feb 19, 2020
Overview -------- This fixes a recent regression in which `xml/GenCode.php` fails to execute in certain configurations. Initial report: civicrm/civicrm-buildkit#503 Before ------ * If the folder `l10n` exists in its traditional location, and if you run `./bin/setup.sh -g`, then it correctly executes. * If the folder `l10n` does not exist in its traditional locacation, and if you run `./bin/setup.sh -g`, then it fails with an error like this: ``` + php -d mysql.default_host=127.0.0.1:3306 -d mysql.default_user=dmasterciv_abcde -d mysql.default_password=abcd1234 GenCode.php schema/Schema.xml '' Drupal civicrm_domain.version := 5.23.alpha1 Parsing schema description schema/Schema.xml Extracting database information Extracting table information PHP Fatal error: Uncaught RuntimeException: Invalid configuration: the [cms.root] path must be an absolute URL in /home/me/.../Civi/Core/Paths.php:174 Stack trace: #0 /home/me/.../Civi/Core/Paths.php(151): Civi\Core\Paths->toAbsoluteUrl('/', 'cms.root') #1 /home/me/.../Civi/Core/Paths.php(176): Civi\Core\Paths->getVariable('cms.root', 'url') #2 /home/me/.../Civi/Core/Paths.php(151): Civi\Core\Paths->toAbsoluteUrl('/', 'civicrm.root') #3 /home/me/.../Civi/Core/Paths.php(224): Civi\Core\Paths->getVariable('civicrm.root', 'path') #4 /home/me/.../Civi/Core/Paths.php(84): Civi\Core\Paths->getPath('l10n') #5 [internal function]: Civi\Core\Paths->Civi\Core\{closure}() #6 /home/jo in /home/me/.../Civi/Core/Paths.php on line 174 ``` After ----- You can run `./bin/setup.sh -g` with or without the `l10n` folder. Comments -------- There's an argument to be made that this shouldn't be necessary: when running `GenCode`, it should only create PHP files, and none of the output should depend on the CMS URL - because that's liable to change when you deploy the PHP code. If someone did try to generate URL at such an early stage, it's arguably good to generate an error. In point of fact, `GenCode` is not actually using the CMS URL. The oddity stems from the contract of `CRM_Utils_System_*` (specifically, `getCiviSourceStorage()` and `getDefaultFileStorage()`) which do double-duty providing both path and URL. To avoid duplicate work, `Civi\Core\Paths` uses the same grain of information - it tracks the pairs of path+URL. A more aggressive fix might be to split `getCiviSourceStorage()` and `getDefaultFileStorage()` so that it's possible to get the path and URL separately; then revise `Civi\Core\Paths` to take advantage of the finer-grained contract. However, splitting those things would be a more invasive patch, and we're currently in RC.
seamuslee001
pushed a commit
that referenced
this pull request
Sep 4, 2020
…esources This is a very subtle behavioral change. To understand it, we must consider the traditional ordering in `CRM_Core_Resources::addScriptUrl()` and `CRM_Core_Region::add()`. Compare these two examples: ``` Civi::resources()->addScriptUrl('http://example.com/foo.js', 100, 'page-footer'); Civi::resources()->addScriptUrl('http://example.com/bar.js', 100, 'page-footer'); CRM_Core_Region::instance('page-footer')->add([ 'scriptUrl' => 'http://example.com/foo.js', 'weight' => 100, ]); CRM_Core_Region::instance('page-footer')->add([ 'scriptUrl' => 'http://example.com/bar.js', 'weight' => 100, ]); ``` You might expect this to output `<SCRIPT>`s in the same order. After all, the examples use the same URLs, the same weights, and the same procedural/natural order. Moreover, `Civi::resources()` is just a wrapper for `CRM_Core_Region`. Surely they were the same! They were not. The output order would differ. The reason is that the ordering had two keys (`weight,name`), and the secondary-key (`name`) was hidden from us: * In `CRM_Core_Resources::addScriptUrl()`, the default `name` was the URL. This was handy for de-duping resources. * In `CRM_Core_Region::add()`, the default `name` was a numeric position. This made it behave like procedural/natural-ordering. Of course, the goal in this branch is to make various collections support the same methods and the same behaviors. But they didn't agree before, so something has to give. Either: 1. Standardize on the behavior of `Resources::addScriptUrl()` and change `Region::add(scriptUrl)`. 2. Standardize on the behavior of `Region::add(scriptUrl)` and change `Resources::addScriptUrl()`. 3. Embrace a split. All `CRM_Core_Resources::add*()` behave one way, and all `CRM_Core_Region::add*()` behave another. 4. Embrace a split. All rich adders (`*::addScriptUrl()`) behave one way, and all generic adders (`*::add()`) behave another. This developmental branch has been using `#3`. The patch changes it to `#4`. Both splits achieve backward compatibility wrt `Resources::addScriptUrl()` and `Region::add(scriptUrl)`. The difference is that `#4` allows us to have the same behavior in all collections (regardless of subtype), which means that collections can be more interoperable and share more code. From my POV, it's still quirkier than `#1` or `#2`, but it's not as quirky as `#3`.
seamuslee001
pushed a commit
that referenced
this pull request
Oct 29, 2020
Overview -------- The test appears to have a random failure. Making it more readable may help figure out why. Before ------ `testDeleteByCacheKey()` and the related `testFillArray()` both have some assertions in these two forms: ``` // Form #1, more verbose $all = ...getSelections($cacheKey, $action); $this->assertEquals([...expected...], array_keys($all)...); // Form #2, more pithy $this->assertSelections([...expected...], $action, $cacheKey); ``` After ----- The verbose form is replaced with the pithier form. In the pithier form, some of the default inputs are made explicit. Comment ------- It is confusing that the method `getSelections()` has a parameter `$action` which can be `get` or `getall` -- and that `getall` does not (in fact) return selections. It returns all! (The fact that the contract is weird makes the unit-test helpful imho...)
seamuslee001
pushed a commit
that referenced
this pull request
May 2, 2021
This is an analog/follow-up to civicrm#20091 Why is this necessary? Recall that a typical admin will go through this lifecycle: 1. Enable extension $x 2. Disable extension $x 3. Either: * (a) Re-enable extension $x * (b) Uninstall extension $x Step `#2` disables the classloader for purposes of regular page-loading. However, when you get to step `#3a` or `#3b`, then you need the classloader again.
seamuslee001
pushed a commit
that referenced
this pull request
Dec 7, 2021
…ion-fix) Overview -------- Fixes a recent regression that prevents you from uninstalling extensions via CLI. This specifically affects extensions which use managed entities. Steps to reproduce ------------------ ``` cv en afform cv dis afform cv ext:uninstall afform ``` Before ------- ``` [bknix-max:~/bknix/build/dmaster/web/sites/all/modules/civicrm] cv en afform && cv dis afform && cv ext:uninstall afform Enabling extension "org.civicrm.afform" Disabling extension "org.civicrm.afform" Uninstalling extension "org.civicrm.afform" Error: API Call Failed: Array ( [entity] => Extension [action] => uninstall [params] => Array ( [keys] => Array ( [0] => org.civicrm.afform ) [debug] => 1 [version] => 3 ) [result] => Array ( [error_code] => unauthorized [entity] => Extension [action] => uninstall [trace] => #0 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(147): Civi\API\Kernel->authorize(Object(Civi\Api4\Provider\ActionObjectProvider), Object(Civi\Api4\Generic\DAODeleteAction)) #1 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php(234): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAODeleteAction)) #2 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/api.php(85): Civi\Api4\Generic\AbstractAction->execute() #3 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(467): civicrm_api4('OptionValue', 'delete', Array) #4 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(303): CRM_Core_ManagedEntities->removeStaleEntity(Object(CRM_Core_DAO_Managed)) #5 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(134): CRM_Core_ManagedEntities->reconcileUnknownModules() #6 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(409): CRM_Core_ManagedEntities->reconcile() #7 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Extension/Manager.php(483): CRM_Core_Invoke::rebuildMenuAndCaches(true) #8 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/v3/Extension.php(183): CRM_Extension_Manager->uninstall(Array) civicrm#9 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_uninstall(Array) civicrm#10 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array) civicrm#11 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array) civicrm#12 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe('Extension', 'uninstall', Array) civicrm#13 phar:///home/me/bknix/bin/cv/src/Command/BaseCommand.php(49): civicrm_api('Extension', 'uninstall', Array) civicrm#14 phar:///home/me/bknix/bin/cv/src/Command/ExtensionUninstallCommand.php(63): Civi\Cv\Command\BaseCommand->callApiSuccess(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), 'Extension', 'uninstall', Array) civicrm#15 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Command/Command.php(257): Civi\Cv\Command\ExtensionUninstallCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) civicrm#16 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Application.php(850): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) civicrm#17 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRunCommand(Object(Civi\Cv\Command\ExtensionUninstallCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) civicrm#18 phar:///home/me/bknix/bin/cv/src/Application.php(46): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) civicrm#19 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Application.php(124): Civi\Cv\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) civicrm#20 phar:///home/me/bknix/bin/cv/src/Application.php(15): Symfony\Component\Console\Application->run() civicrm#21 phar:///home/me/bknix/bin/cv/bin/cv(27): Civi\Cv\Application::main('phar:///Users/t...') civicrm#22 /home/me/bknix/bin/cv(14): require('phar:///Users/t...') civicrm#23 {main} [is_error] => 1 [error_message] => Authorization failed ) ) ``` After ----- Works Comment ------- I encountered this while working on E2E test-coverage for other changes. The E2E test coverage had worked on a previous iteration of 5.45.alpha1 but failed when I rebased. Consequently, this means You can see a prior draft of the E2E test [here](https://github.com/totten/shimmy/blob/master-reorg/shimmy/tests/phpunit/E2E/Shimmy/LifecycleTest.php#L56-L77). However, it's being reworked as a core patch. I'd suggest accepting this without a test - because (a) it's a regression and (b) there will be coverage from the pending change.
seamuslee001
pushed a commit
that referenced
this pull request
Feb 21, 2024
[PHP Deprecation] explode(): Passing null to parameter #2 ($string) of type string is deprecated at /var/www/powerbase/sites/all/modules/civicrm/CRM/Utils/Mail/EmailProcessor.php:83
seamuslee001
pushed a commit
that referenced
this pull request
Apr 10, 2024
…f type array, null given a CRM_Core_DAO->copyValues()
seamuslee001
pushed a commit
that referenced
this pull request
Apr 10, 2024
Fix for `TypeError: array_key_exists(): Argument #2 ($array) must be …
totten
pushed a commit
that referenced
this pull request
Sep 19, 2024
CRM_Event_Page_EventInfoTest::testFullMessage Exception: CRM_Extension_Exception_MissingException: "Failed to find extension: civi_mail" #0 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Extension/Container/Basic.php(143): CRM_Extension_Container_Basic->getRelPath("civi_mail") #1 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Extension/Mapper.php(233): CRM_Extension_Container_Basic->getPath("civi_mail") #2 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Resources.php(261): CRM_Extension_Mapper->keyToBasePath("civi_mail") #3 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Resources.php(311): CRM_Core_Resources->getPath("civi_mail") #4 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/Civi/Angular/Manager.php(208): CRM_Core_Resources->glob("civi_mail", (Array:3)) #5 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/Civi/Angular/Manager.php(114): Civi\Angular\Manager->resolvePatterns((Array:59)) #6 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check/Component/Env.php(1178): Civi\Angular\Manager->getModules() #7 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check/Component.php(76): CRM_Utils_Check_Component_Env->checkAngularModuleSettings(FALSE) #8 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(215): CRM_Utils_Check_Component->checkAll((Array:0), FALSE) civicrm#9 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(185): CRM_Utils_Check::checkStatus() civicrm#10 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(93): CRM_Utils_Check::checkAll() civicrm#11 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Page.php(267): CRM_Utils_Check->showPeriodicAlerts() civicrm#12 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Event/Page/EventInfo.php(325): CRM_Core_Page->run()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.