CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-11-14T16:34:11Zhttps://lab.civicrm.org/dev/core/-/issues/4762SearchUI: Manage Extensions with SK/FB2023-11-14T16:34:11Zaydunsaidan.saunders@squiffle.ukSearchUI: Manage Extensions with SK/FBIssues relating to replacing the 'Manage Extensions' page with SK/FB
Enable SearchUI extension then go to Administer > Experimental > Extensions
## Required to match current functionality:
- [ ] Way to determine whether extension ne...Issues relating to replacing the 'Manage Extensions' page with SK/FB
Enable SearchUI extension then go to Administer > Experimental > Extensions
## Required to match current functionality:
- [ ] Way to determine whether extension needs updating
- [ ] API enhancement (?) to get info.xml data
- [ ] Expandable sections - or show in pop-up?
- [ ] Metadata update to add 'Install', 'Upgrade' and 'Disable' actions
- [ ] Functionality to show not-installed extensions (ie 'Add New' tab)
## Improvements:
- [ ] Separate core/required from community extensions (could be filters or tabs)
- [ ] Better handling of extensions with local githttps://lab.civicrm.org/dev/core/-/issues/4715The Search-UI extension gives a menu item Experimental2023-10-26T11:36:52ZjaapjansmaThe Search-UI extension gives a menu item Experimental**Steps to reproduce**
1. Install a fresh CiviCRM (version 5.66)
2. Enable Search UI extension
**Results**
A new menu item called Experimental appears. See attached screenshot
![Untitled](/uploads/219b7c83f1303681f6afbbc15497eacf/Unt...**Steps to reproduce**
1. Install a fresh CiviCRM (version 5.66)
2. Enable Search UI extension
**Results**
A new menu item called Experimental appears. See attached screenshot
![Untitled](/uploads/219b7c83f1303681f6afbbc15497eacf/Untitled.png)
**Why is this an issue?**
This is an issue because the extension ships with a stable version of CiviCRM Core. And installing this on a production site gives some unexpected menu item.
When I download a stable version of CiviCRM I am not sure whether I would expect a menu item Experimental.
**Possible solution**
1. Move the extension out of core. This also has the benefit it can be installed on other versions of CiviCRM as well.
2. Do not use the menu item experimental but place the items provided in this extension in a more suitable place.
My opinion would be as long as this extension is experimental to not ship it with core.https://lab.civicrm.org/dev/core/-/issues/4713Move the Elavon Payment Processor extension out of core2023-11-28T23:54:24ZjaapjansmaMove the Elavon Payment Processor extension out of coreI have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They...I have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They use CiviSepa for direct debits and Mollie for online payments both are not shipped with core).
I also believe that an extension which lives outside of core is also easier to install on CiviCRM installations which does not have this extension shipped by default (when needed).https://lab.civicrm.org/dev/core/-/issues/4712Move the PHP Storm extension out of core2023-10-26T11:37:31ZjaapjansmaMove the PHP Storm extension out of coreI have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this exte...I have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this extension moved out of core? That also gives other flexibility to install this extensions on older CiviCRM sites on which I am doing development on.https://lab.civicrm.org/dev/core/-/issues/3490Upgrader - Apply extension updates after core updates2023-02-08T19:08:30ZtottenUpgrader - Apply extension updates after core updatesOverview
----------------------------------------
Functionality in `civicrm-core` is increasingly organized with internal extensions (`civicrm-core:ext/*`). The main upgrade workflow should incorporate the upgrade-steps for extensions.
...Overview
----------------------------------------
Functionality in `civicrm-core` is increasingly organized with internal extensions (`civicrm-core:ext/*`). The main upgrade workflow should incorporate the upgrade-steps for extensions.
Example use-case
----------------------------------------
1. Extract tarball with a new version of `civicrm-core`, including updated `ext/*`
1. Run the main upgrader (`civicrm/upgrade?reset=1`, `cv core:upgrade`, `drush civicrm-upgrade-db`, or `wp civicrm upgrade-db`)
Current behaviour
----------------------------------------
It updates the schema for things like `civicrm_contact` (eg `CRM/Upgrade/*`) but not things like `civicrm_search_segment` (eg `ext/search_kit/CRM/Search/Upgrader.php`).
As a sysadmin, you must run the upgrades separately.
Most are not habituated to running these together. This leads to confusing user-stories like https://civicrm.stackexchange.com/questions/42094/civimail-issue-db-error-no-such-table-when-sending-mailing (where the first upgrade seemed to work - but you get random errors because the second upgrade hasn't run).
Proposed behaviour
----------------------------------------
Run both.
The core-upgrade should delegate/incorporate the ext-upgrade, and it should preserve essential elements of the ext-upgrade contract. Specifically: ext-upgrades can use features/services/APIs from core. This implies that (1) ext-upgrades run after core-upgrades and (2) when it gets to ext-upgrades, it should follow a normal/open dispatch-policy.
Comments
----------------------------------------
Filing issue after some Mattermost discussion with rudanpal, @colemanw, @bgm, @totten: https://chat.civicrm.org/civicrm/pl/b76y4gy517yxdet331ueqrxgrw
I posted a draft at https://github.com/civicrm/civicrm-core/compare/5.50...totten:run-ext-upgrades?expand=1
As mentioned in PHP comments+Mattermost, there's an issue with the current draft -- when it gets to ext-upgrade tasks, it would (unexpectedly) continue to apply the limited dispatch-policy used for core-upgrades (`upgrade.main` vs `upgrade.finish`). Some ways to address that:
* __Runner state__: While the upgrader goes through phases (*ex: 1-core upgrade, 2-ext upgrade, 3-new exts*), keep a stored value naming the phase. this stored value determines the active dispatch-policy
* ex: `Civi::settings()->set('upgrade_phase', '...')`
* __Task wrapping/task tagging__: When taking ext-upgrade tasks and putting them into the core-upgrade queue, put some wrapper or tag on each one to indicate the phase/policy that it relies on
* wrapper example: `CRM_Upgrade_Form::wrappedTask(string $dispatchPolicy, array $realCallback)
* tag example: `$queue->createItem($task, ['dispatchPolicy' => string])`https://lab.civicrm.org/dev/core/-/issues/2646Enable/Disable Extension Receives API Error2022-09-16T00:12:46ZpbarmakEnable/Disable Extension Receives API ErrorOverview
----------------------------------------
Anytime we enable or disable an extension, we get an API error with the error message of: API error: Value already exists in the database on ReportTemplate.create. This is true with eithe...Overview
----------------------------------------
Anytime we enable or disable an extension, we get an API error with the error message of: API error: Value already exists in the database on ReportTemplate.create. This is true with either the Admin extension UI screen or using cv.
Reproduction steps
----------------------------------------
1. Run cv ext:disable uk.co.vedaconsulting.mosaico
2. Get the error message
3. The extension still gets disabled (or enabled, depending on what we run)
Current behaviour
----------------------------------------
Here is the full error message from cv:
```
Disabling extension "uk.co.vedaconsulting.mosaico"
Error: API Call Failed: Array
(
[entity] => Extension
[action] => disable
[params] => Array
(
[keys] => Array
(
[0] => uk.co.vedaconsulting.mosaico
)
[debug] => 1
[version] => 3
)
[result] => Array
(
[trace] => #0 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(241): CRM_Core_ManagedEntities->onApiError('ReportTemplate', 'create', Array, Array)
#1 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(184): CRM_Core_ManagedEntities->insertNewEntity(Array)
#2 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(146): CRM_Core_ManagedEntities->reconcileEnabledModule(Object(CRM_Core_Module), Array)
#3 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(127): CRM_Core_ManagedEntities->reconcileEnabledModules()
#4 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/Invoke.php(400): CRM_Core_ManagedEntities->reconcile()
#5 /var/www/civicrm/sites/all/modules/civicrm/CRM/Extension/Manager.php(420): CRM_Core_Invoke::rebuildMenuAndCaches(true)
#6 /var/www/civicrm/sites/all/modules/civicrm/api/v3/Extension.php(150): CRM_Extension_Manager->disable(Array)
#7 /var/www/civicrm/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_disable(Array)
#8 /var/www/civicrm/sites/all/modules/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
#9 /var/www/civicrm/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
#10 /var/www/civicrm/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe('Extension', 'disable', Array)
#11 phar:///usr/local/bin/cv/src/Command/BaseCommand.php(49): civicrm_api('Extension', 'disable', Array)
#12 phar:///usr/local/bin/cv/src/Command/ExtensionDisableCommand.php(56): Civi\Cv\Command\BaseCommand->callApiSuccess(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), 'Extension', 'disable', Array)
#13 phar:///usr/local/bin/cv/vendor/symfony/console/Command/Command.php(257): Civi\Cv\Command\ExtensionDisableCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 phar:///usr/local/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))
#15 phar:///usr/local/bin/cv/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRunCommand(Object(Civi\Cv\Command\ExtensionDisableCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 phar:///usr/local/bin/cv/src/Application.php(46): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 phar:///usr/local/bin/cv/vendor/symfony/console/Application.php(124): Civi\Cv\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 phar:///usr/local/bin/cv/src/Application.php(15): Symfony\Component\Console\Application->run()
#19 phar:///usr/local/bin/cv/bin/cv(27): Civi\Cv\Application::main('phar:///usr/loc...')
#20 /usr/local/bin/cv(14): require('phar:///usr/loc...')
#21 {main}
[is_error] => 1
[error_message] => API error: Value already exists in the database on ReportTemplate.create
)
)
```
Expected behaviour
----------------------------------------
No error message
Environment information
----------------------------------------
* __CiviCRM:5.38.0
* __PHP:7.3.28
* __CMS:Drupal 7
* __Web Server: Apache 2.4https://lab.civicrm.org/dev/core/-/issues/2571Move reCAPTCHA to core extension2022-12-02T09:28:56Zmattwiremjw@mjwconsult.co.ukMove reCAPTCHA to core extensionThis is a tracking issue to track progress.
* https://github.com/civicrm/civicrm-core/pull/19967 - initial extension merged.
* https://github.com/civicrm/civicrm-core/pull/19999 - add recaptcha to distmaker - merged.
* https://github.co...This is a tracking issue to track progress.
* https://github.com/civicrm/civicrm-core/pull/19967 - initial extension merged.
* https://github.com/civicrm/civicrm-core/pull/19999 - add recaptcha to distmaker - merged.
* https://github.com/civicrm/civicrm-core/pull/20011 - move recaptcha library to extension - merged.
* https://github.com/civicrm/civicrm-core/pull/20019 - Use standard function to add reCAPTCHA to PCPAccount form - merged.
Need to cleanup and move all calls to add reCAPTCHA to forms to the extension.https://lab.civicrm.org/dev/core/-/issues/1403Change "Contribution Received Date" to be "Contribution date" where is exists...2024-01-28T01:17:26ZJamie Novick - CompucoChange "Contribution Received Date" to be "Contribution date" where is exists and basically sort this Contribution dates mess out once and for allOk... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion ...Ok... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion to allow us to sort this out once and for all.
**Overview:**
----------------------------------------
CiviCRM has a core field on the contribution called "receive_date". This shows up on various screens and has led to significant debate about whether it should be a required field or not, and what it's real use case is. For example discussions below where debate has raged on how it should work:
https://lab.civicrm.org/dev/core/issues/1057
https://lab.civicrm.org/dev/core/issues/680
https://lab.civicrm.org/dev/core/issues/1140 - slightly different but related re: accruals accounting
https://lab.civicrm.org/dev/core/issues/1402
**The issue:**
----------------------------------------
So... there are a few problems with this field:
a) The idea of a "received date" is a bit meaningless (and confusing to users) when you have a pending contribution. You haven't quite received anything yet.
b) The idea of a "received date" conflicts with the payments dates if you have multiple payments (or could even be made to be different from the payment date) again which is nonsensical.
I assume contribution received date was a field that pre-dated the CiviCRM accounting implementation and hence perhaps hasn't kept up with the reality of the situation. In any case I believe this is causing some real issues now and should be sorted out.
Note the field is used:
1) As the date when initial accounting transactions are made. i.e. create a new pending contribution it will be the date of the Debit and Credits / transaction recorded in CiviCRM and hence by default it is the "revenue recognition date" for account purposes for the income.
This then leads to a multitude of other issues:
a) If I "complete" a pending membership contribution for a new membership by recording a payment, what should the start date of the membership be? (see: https://lab.civicrm.org/dev/core/issues/1402)
b) We've then introduced another field called "revenue_recognition_date", which should actually be field 1 above - as that is when we are recognising the transactions. We shouldn't have another field for this.
c) For some reason we now have a field on the invoice called "invoice date" which prints todays date which again is incorrect as it should be the same as item 1 above. The invoice should reflect the revenue recognition date. https://civicrm.stackexchange.com/questions/21128/how-do-i-print-the-received-date-on-an-invoice
**Proposed solution:**
----------------------------------------
The solution is relatively simple. We should change the "received_date" field to simply be the "Contribution date".
| Invoicing? | Contribution status | What the field means | Changes required to CiviCRM |
| ------ | ------ | ------ | ------ |
| Not using invoices | Pending | Represents the date the contribution was recorded on the system. | When later marking the contribution as completed give users the option to update the date or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.
| Not using invoices | Completed | Represents the date the contribution was recorded on the system but also record a payment on the same date.
| Using invoices | Pending | Represents the date the invoice was recorded on the system and hence the invoice date and the revenue recognition date. | We should update the invoices to use this date as the invoice date. This field should not be updated when marking the invoice as complete (or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.)
| Using invoices | Completed | Represents the date the invoice was recorded on the system but also the date the payment for that invoice was received. Ideally we would split the invoice and payment sections from each other on the "create new" form.
**Future:**
----------------------------------------
At some date in the future it would then be good to properly decouple payments from contributions and get rid of the terrible contribution status field once and for all.
Basically the contribution would reflect an order or invoice object, i.e. the obligation to pay for something. The payment transaction then would be separate and would represent the actual payment of that obligation. Accounting software has done this correctly for years so it's about time CiviCRM did too!
@mattwire @eileen @KarinG @dylan-circle @jaapjansma @JoeMurray @ErikHommel @fabian_SYSTOPIA and a few Compucorp names also - @omar_compucorp @Miya27
I'm sure you will all have opinions on this...