Skip to content
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

Report api - temp internal PR for commentary #2

Closed
wants to merge 2 commits into from

Conversation

eileenmcnaughton
Copy link
Owner

NB - I had to make this edit to report for the api to work on it - not committed to this fn name though

eileenmcnaughton/net.ourpowerbase.reports.advancedfundraising@790b58e

@dlobo
Copy link

dlobo commented Dec 5, 2013

a few comments:

  1. Can u file an issue and submit a PR for 4.4.4
  2. In general, for future PR's like this i'd keep the code changes to as small a diff as possible and do cleanups in the next release. So setter / getters that are not needed, i would have done for 4.5. In this case, since u've already done it, i'd keep as is
  3. At some point, we need to stop adding code which does not fix super-critical bugs. Any code added has the potential for unintentional side effects (in the absence of a large test suite) and hence it is good to draw the line. We are bending the line for CiviHR and for your stuff, but i suspect at 4.4.5 or so, we should all agree to make any more changes in 4.5

@eileenmcnaughton
Copy link
Owner Author

ok - can do on core. Actually the setters & getters are required - because I want to alter protected variables outside of context.

If this is going into 4.4 then I will write a unit test for it

eileenmcnaughton pushed a commit that referenced this pull request Jan 15, 2014
----------------------------------------
* CRM-14052: Tagset fixes
  http://issues.civicrm.org/jira/browse/CRM-14052
eileenmcnaughton pushed a commit that referenced this pull request Jan 15, 2014
----------------------------------------
* CRM-14052: Tagset fixes
  http://issues.civicrm.org/jira/browse/CRM-14052
@eileenmcnaughton eileenmcnaughton deleted the report-api branch May 15, 2014 23:13
eileenmcnaughton pushed a commit that referenced this pull request Oct 13, 2014
VAT-365 Proposed Tax UI changes
eileenmcnaughton pushed a commit that referenced this pull request Dec 17, 2014
eileenmcnaughton pushed a commit that referenced this pull request May 13, 2015
Add default of current timestamp to the create_datek
eileenmcnaughton pushed a commit that referenced this pull request Jul 22, 2015
Fixed spelling of 'memebership' in 625
eileenmcnaughton pushed a commit that referenced this pull request Oct 20, 2015
eileenmcnaughton pushed a commit that referenced this pull request Jun 7, 2016
Merge two patches into single patch.
eileenmcnaughton pushed a commit that referenced this pull request Oct 12, 2016
eileenmcnaughton pushed a commit that referenced this pull request May 23, 2019
eileenmcnaughton pushed a commit that referenced this pull request Feb 20, 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.
eileenmcnaughton 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`.
eileenmcnaughton pushed a commit that referenced this pull request Oct 21, 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...)
eileenmcnaughton pushed a commit that referenced this pull request Apr 22, 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.
eileenmcnaughton pushed a commit that referenced this pull request Dec 1, 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)
 #9 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_uninstall(Array)
 #10 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
 #11 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
 #12 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe('Extension', 'uninstall', Array)
 #13 phar:///home/me/bknix/bin/cv/src/Command/BaseCommand.php(49): civicrm_api('Extension', 'uninstall', Array)
 #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)
 #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))
 #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.
eileenmcnaughton pushed a commit that referenced this pull request Feb 15, 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
eileenmcnaughton pushed a commit that referenced this pull request Feb 16, 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
eileenmcnaughton pushed a commit that referenced this pull request Apr 3, 2024
…f type array, null given a CRM_Core_DAO->copyValues()
eileenmcnaughton pushed a commit that referenced this pull request Apr 3, 2024
Fix for `TypeError: array_key_exists(): Argument #2 ($array) must be …
eileenmcnaughton added a commit that referenced this pull request Sep 3, 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)
#9 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(185): CRM_Utils_Check::checkStatus()
#10 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(93): CRM_Utils_Check::checkAll()
#11 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Page.php(267): CRM_Utils_Check->showPeriodicAlerts()
#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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants