Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-15T02:23:37Zhttps://lab.civicrm.org/dev/core/-/issues/3752Membership terms present in price set not get used in the offline form signup.2024-03-15T02:23:37ZsunilMembership terms present in price set not get used in the offline form signup.Overview
----------------------------------------
Number of Terms present in priceset not get used while signing up using offline form.
Reproduction steps
----------------------------------------
1. Crete Price and field of Select opti...Overview
----------------------------------------
Number of Terms present in priceset not get used while signing up using offline form.
Reproduction steps
----------------------------------------
1. Crete Price and field of Select option.
1. Use Membership type `Student` which is 1 year duration.
1. Use the same membership type with different terms.
1. Now, go to the contact and sign up for membership using priceset.
1. Use Membership with 2 or 3 year terms.
1. Result : it extends by only 1 year.
Current behaviour
----------------------------------------
Irrespective of different terms of membership, membership only extends by only one year.
Expected behaviour
----------------------------------------
Membership should extend as per terms set in the price set field option.https://lab.civicrm.org/dev/financial/-/issues/200Contribution status’s are ambiguous (WIP)2022-09-10T05:42:18ZJamie Novick - CompucoContribution status’s are ambiguous (WIP)**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of prob...**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of problems about what the intention of the user really is in a number of scenarios when they change the contribution status.
Examples:
| Example | Narrative | Video |
| ------ | ------ | ------ |
| Example 1a: Overpayment / pending refund | A contribution which is created for $100 donation, but pending. We then record an overpayment of $120. Hypothetically the contribution is overpaid by $20 and should be pending refund. This is not shown in CiviCRM. There is nothing showing the user that there is an overpayment of $20.| ![1-Overpayment](/uploads/74eca492a8d044aa17033dd681922c4a/1-Overpayment.webm)
| Example 1b: Change contribution status to refunded | We can further demonstrate this by taking the same contribution and then changing the status of the contribution to refunded. This raises the question of what this means? Does this reflect the users intention to: Cancel the original debt of $100 (i.e. to credit note the original amounts owed and clear the balance Or reflect the fact a refund was made for the payment of $120, but that they are still owed the original $100 Or both? CiviCRM has refunded the original value of the invoice, i.e. $100, even though the payment of $120 was received. As such we still owe $20 but this is not shown in CiviCRM.|![2-Change_status_to_refunded](/uploads/bf9eae010687771d440b4baa0d528d1e/2-Change_status_to_refunded.webm)
| Example 2: A typo entered in the wrong contribution amount | Add a contribution for $100 and set as completed. Realised that actually the contribution was $120. System will automatically add the additional $20 payment. Note: If this was a change in the line items of an invoice, it would not be safe to assume we received the additional payment. The aim of the user might be to state the obligation to pay was $120. Also it probably wasn’t 2 separate payments and hence we should reverse out the first payment (-100) and then make a second payment for the full amount (+120) | ![Updating_a_contribution_amount_error](/uploads/bda0cc37c9c5911b54bb429367bdffbf/Updating_a_contribution_amount_error.webm)
Much of this stems from the contribution status field being both be the driver of changes to the contribution (i.e. by changing the status to completed or refunded) or changed itself (i.e. the result of changes to the position of the contribution) by recording payments or refunds.
As such this is a proposal to simplify this workflow so that the the contribution status is only the result of the status of the contribution, and can no longer be used to change the status of the contribution.
We would retain the ability to make changes to the contribution status via the API for backwards compatibility until extensions can adopt the new model.
**Further ramblings (feel free to skip this part if you are not too interested in accounting principles)**
Accounting has simple and sounds principles for dealing with all of this.
“Obligations” are managed by 2 documents: Invoices and Credit notes. An invoice would stipulate what is obligated. This can be reduced by creating a credit note, which would then reduce the obligated amount.
It’s worth noting that for sales tax (for example VAT) purposes invoices should be sequentially numbered and should not be edited once they are generated. Hence usually you would not just simply delete an invoice to reduce the obligated amount, you would create a credit note for some or all of the amount, apply it to the invoice and send that to the customer to show the reduce in their balance owed to you.
As such I think in CiviCRM we need to fully enforce the split of concepts of the “obligation” and the actual payments (or refunded) amounts. Currently we have started on the journey towards that where Contributions (and line items on them) represent the obligations in most cases, and payments (or financial transactions of type payment) are the payments.
The contribution status should be a reflection of the net of that position. Does the customer owe us money (= pending or partially paid*) or is the balance settled (= completed) or do we owe them money (= pending refund)?
</details>
**Proposed changes:**
1. Recalculate the contribution status whenever a contribution is created or updated
We should recalculate the contribution status whenever a contribution is created or updated based on the following rules:
| Ref | Calculation | Status |
| ------ | ------ | ------ |
| 1 | If there are no payments or refunds | Pending (arguably there would be a better label for this but in order to avoid making actual changes to the contribution status options this would seem to be the best fit) |
| 2 | If the sum of the line items (including any tax line items) > (sum of payments received - sum of refunds paid out) | Partially paid |
| 3 | If the sum of the line items (including any tax line items) < (sum of payments received - sum of refunds paid out) | Pending refund |
| 4 | If the sum of the line items (including any tax line items) = (sum of payments received - sum of refunds paid out) | Completed |
2. Changes to the User interface:
| Screen | How it looks currently | How it will work | Changes required |
| ------ | ------ | ------ |------ |
| New contribution screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![Create_new_contribution](/uploads/cb028a89f3c3cc2c3798128efaa4e0d6/Create_new_contribution.png) | We split the "obligation" with the "payment". As such we remove the contribution status field from this screen and instead allow people to decide whether they want to record the "payment" at the same time as recording the "obligation" by checking the "Record payment" checkbox. The contribution status would then be calculated using the logic above. i. |
| View contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.26.55](/uploads/02854f20d41d8ffec5159fa1977627e0/Screenshot_2022-08-29_at_11.26.55.png) | | No Changes |
| View contribution screen (multiple line items) || | |
| Edit contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.30.42](/uploads/6faaed62b313698c1a4346956f48e719/Screenshot_2022-08-29_at_11.30.42.png)| ![Screenshot_2022-08-29_at_11.37.56](/uploads/68293bdc8d48c548606793c6a64d159d/Screenshot_2022-08-29_at_11.37.56.png)| Status field becomes read only and we introduce a button to cancel the contribution. See below for new screen for cancelling a contribution|
| Edit contribution screen (multiple line items) || | |
| New membership screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | cell | ------ |
| View membership screen (one line item) | | ||
| View membership screen (multiple line items) | | ||
| Edit membership screen (one line item) | | ||
| Edit membership screen (multiple line items) | | ||
| New event participant screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![New_participant](/uploads/7837cf2271b10bb5824d11483221037a/New_participant.png) | Change the checkbox "Record Payment" to "Record Contribution" OR have a toggle to allow the admin to decide whether they are recording a "Paid" or "Free ticket". We only need the financial type and contribution date if we are only recording the contribution (note in https://lab.civicrm.org/dev/core/-/issues/1403 we have agreed to change label of contribution received date to contribution date). The amounts / lines should come from above. |
| View event participant screen (one line item) | | ||
| View event participant screen (multiple line items) | | ||
| Edit event participant screen (one line item) | | ||
| Edit event participant screen (multiple line items) | | ||
- Removehttps://lab.civicrm.org/dev/user-interface/-/issues/48Swap out CiviCRM logos2023-10-07T10:15:12Zjoshjosh@civicrm.orgSwap out CiviCRM logosRequest to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0...Request to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0/civi99.svg)
![civi99](/uploads/d629d77f01db2750813f08178c264cbb/civi99.png)
![logo_words_small](/uploads/8c5a775cba670ed1854bcf86468e282c/logo_words_small.png)https://lab.civicrm.org/dev/core/-/issues/3738Feature request - APIv4 Get action, provide ability to define aliases for the...2024-03-15T14:56:37Zjustinfreeman (Agileware)Feature request - APIv4 Get action, provide ability to define aliases for the select fields so that external integrations with CiviCRM do not break when the field name changes OR a different field is selectedThis is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enab...This is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enable external CiviCRM integrations to be more robust, by allowing the fields selected in the Get action to be **changed** and but continue to use the **same alias**, thus not changing the structure of the results, the external integration would continue to work.
The other benefit would be that very long CiviCRM field names could be reduced to something shorter or more logical. eg. Instead of "email.email" the alias could just be set to "email". Or instead of "email_greeting_id:label" the alias could just be "email_greeting".
![image](/uploads/2ccae5082e4f50f5fc924d8e6998ffaa/image.png)https://lab.civicrm.org/dev/core/-/issues/3714CiviCRM Contribution Page, total amount calculation is sometimes off by one o...2023-07-18T05:40:43Zjustinfreeman (Agileware)CiviCRM Contribution Page, total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being usedWhen using a **CiviCRM Contribution Page** the total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being used.
In the case of ...When using a **CiviCRM Contribution Page** the total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being used.
In the case of Stripe, the _correct amount_ is _pre-authorised_. When the payment is _confirmed_ the _incorrect amount_ is used and because the two amounts do not match, the **transaction fails**. As a result this bug prevents payments from working with Stripe as a payment processor for certain amounts.
# Steps to reproduce
1. Enable tax and invoicing
2. Add e.g. a 10% GST account to Member Dues
3. Create a membership prices set with one field that has three checkbox options:
4. 318.18182 (350 incl tax)
5. 22.72727 (25 incl tax)
6. 24.54545 (27 after tax - note that this would actually work out to 27.01 with the older premature rounding based off-by one issue)
7. Use this price set on a contribution page
8. Submit a test using this contribution page.
9. Note in the summary that the line totals are 350.00, 25.00, and 27.00
## Expected result
Total should be **$402**
## Actual result
Total is **$401.99** - which is one cent less than the expect value, and two cents less than the value you would get with premature rounding.
## Tested environment
Bug has been confirmed using **CiviCRM 5.52.alpha1** on https://wpmaster.demo.civicrm.org/
## Workaround
Adjust the amount to account for the rounding error. In this case, change the amount: 24.54545 to 24.5363636364 which then changes the total to $401.99. This is then matches the total on the Thank You page.
![image](/uploads/ddf3c7cbeaf3cdc4700079f79b01c7d6/image.png)
![image](/uploads/5eb33f84dfa49cad5697570a019c6936/image.png)
# Contribution page with membership options selected - correct total is shown
![image](/uploads/f35b520763e5e9f3545585f27ff42812/image.png)
# Thank you page - incorrect total is shown
![image](/uploads/d6fa209c43cbf2d721d4cf085882b1f8/image.png)
# Set up - Membership Types
![image](/uploads/01450b1f2a777f3c279e694d5ea7e007/image.png)
# Set up - Priceset
![image](/uploads/672f5c3de5b72e7817dc063388f08c38/image.png)
Agileware Ref: CIVICRM-2007https://lab.civicrm.org/dev/core/-/issues/3711Permissions reset on upgrade or configuration change2022-08-25T21:41:06ZAdam WoodPermissions reset on upgrade or configuration changeApplies to CiviCRM running on Joomla.
The permission "See CiviCRM is installed" keeps resetting by itself. This definitely occurs whenever CiviCRM is upgraded (issue observed up to and including 5.50.4) and/or an extension is installed,...Applies to CiviCRM running on Joomla.
The permission "See CiviCRM is installed" keeps resetting by itself. This definitely occurs whenever CiviCRM is upgraded (issue observed up to and including 5.50.4) and/or an extension is installed, enabled/disabled, updated etc, and may occur at other times. I cannot discern the pattern!
This means that CiviCRM disappears from the 'Components' administrator menu unless you are logged in as Super Administrator.
Since CiviGrant was migrated to an extension, the same issue now applies to "access CiviGrant", "edit grants" and "delete in CiviGrant" - I have to keep re-applying these after each upgrade.https://lab.civicrm.org/dev/core/-/issues/3705CiviReport email sending fails if multiple recipient are specified in 'to' field2024-03-05T05:24:43ZKurund JalmiCiviReport email sending fails if multiple recipient are specified in 'to' field### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCR...### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCRM logs
```bash
[error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => 10006
[message] => Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfigura
tion in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Tra
nsaction failed: Domain contains illegal character)]
[mode] => 16
[debug_info] =>
[type] => PEAR_Error
[user_info] =>
[to_string] => [pear_error: message="Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfiguration in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Transaction failed: Domain contains illegal character)]" code=10006 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info=""]
)
```
This happens because multiple emails gets converted in to invalid emails due to `CRM_Utils_Mail::formatRFC822Email()`https://lab.civicrm.org/dev/core/-/issues/3703Confirmation emails are not sent if it is a recurring payment2022-08-25T17:04:50ZMariaVConfirmation emails are not sent if it is a recurring payment**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well ...**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well for online payment processors like PayPal, where the first payment is made within seconds of submitting the donation form.
With "asynchronous payment processors" such as SEPA, however, this approach works quite poorly, because it can take several weeks before the next payment run happens (usually once a month).
Currently this does not work at all.
Moreover, from a fundraiser's point of view, it is a real disadvantage if these confirmations are sent with every payment: People will be reminded every time that they still haven't cancelled their recurring donations.
**In contrast, the behavior most of us would like to see would be:**
One-time and recurring donations: A confirmation email comes right after you fill out the donation form
Further confirmations for recurring donations will only come if this has been set in a configuration setting.
**My suggestion:**
There could be an additional radio button:
One option that will be choosed by default which explains that the mail is only sent for recurring donations when a payment has actually been received (and for one-time donations directly). And for this purpose, there will be another option that says that a confirmation will be sent once directly after the form has been submitted - regardless of whether it is a one-time or recurring donation.
This will ensure that this function will continue to work for everyone who actually wants to use it that way - even if there are probably not many.https://lab.civicrm.org/dev/core/-/issues/3702DOMDocument::loadHTML(): Tag af-field invalid in Entity when loading dashboard2022-10-20T20:07:11ZDaveDDOMDocument::loadHTML(): Tag af-field invalid in Entity when loading dashboardI'm not sure if this is new or not. This might be something coming up for me now with php8. The error comes up in phpquery which is now provided by vendor/rubaboquery which is new, but I'm not sure it's from any differences there. I thin...I'm not sure if this is new or not. This might be something coming up for me now with php8. The error comes up in phpquery which is now provided by vendor/rubaboquery which is new, but I'm not sure it's from any differences there. I think the error is technically legit.
What's happening is during hook_civicrm_angularModules, afform loads all the blocks, such as this one: https://github.com/civicrm/civicrm-core/blob/6fa8c627a2f406329370f2b03d656dbc565ccb9f/ext/afform/core/ang/afblockContactAddress.aff.html
At https://github.com/civicrm/civicrm-core/blob/6fa8c627a2f406329370f2b03d656dbc565ccb9f/ext/afform/core/Civi/Afform/Symbols.php#L38, it creates a DOMDocumentWrapper around it, which is provided by rubaboquery. Note that it considers the block html (as opposed to e.g. xml), so calls DOMDocument->loadHTML. So I believe what's happening is that loadHTML validates it against the html schema, and `<af-field>` is not a real html tag.
See also https://www.php.net/manual/en/domdocument.loadhtml.php#125526, although I'm not saying that is the best solution. I don't know at the moment.5.56.0https://lab.civicrm.org/dev/core/-/issues/3695Search Kit: Commas in event types break IN operator2024-03-06T22:16:53ZJonGoldSearch Kit: Commas in event types break IN operatorWhen you have an event type with a comma in it, you can't search for it using the `WHERE` clause using the `IN` operator.
### Steps to Replicate
* Create a new event type with a comma in the label (which will propagate to the name).
* C...When you have an event type with a comma in it, you can't search for it using the `WHERE` clause using the `IN` operator.
### Steps to Replicate
* Create a new event type with a comma in the label (which will propagate to the name).
* Create an event with the new event type.
* Create a SK search with a `WHERE` event type `is one of` the new event type.
### Expected Result
The new event will appear.
### Actual Result
Event doesn't appear.
See screenshots comparing `=` and `is one of`.
### Comments
SK assumes that `name` fields can't have commas, so it can explode the string on a comma delimiter. This is the API query for the screenshot above (below).
If event types were their own table, I'd suggest making the `name` field be snake-cased. However, this goes against a long-standing (and probably unwise) design decision around `civicrm_option_value` names, which can be used to match on import with external systems. So this may have to get fixed in SK.
```
{
"version": 4,
"select": [
"id",
"title",
"event_type_id:label"
],
"orderBy": {},
"where": [
[
"event_type_id:name",
"IN",
[
"Development",
"Administration"
]
]
],
"groupBy": [],
"join": [],
"having": []
}
```
![Selection_1550](/uploads/03d0a44e852b431289d54eb9b9951d6e/Selection_1550.png)
![Selection_1551](/uploads/afce4bfb38cd7c3e6cd9e979e0f0c463/Selection_1551.png)https://lab.civicrm.org/dev/core/-/issues/3587Unable to load the recipients group when sending mailing with Civimail2023-10-05T15:41:24ZmarzastUnable to load the recipients group when sending mailing with CivimailI am running CiviCRM 5.17.4 on Wordpress 5.2.3. The problem I am facing is that I am unable to send mailing to mailing lists (defined as groups) via CiviMail.
When I try to enter the group in the Recipients box I get Loading Failed mess...I am running CiviCRM 5.17.4 on Wordpress 5.2.3. The problem I am facing is that I am unable to send mailing to mailing lists (defined as groups) via CiviMail.
When I try to enter the group in the Recipients box I get Loading Failed message and none of the available groups is loaded (see image below). The problem appears for existing and new mailings.
Interestingly when I re-use the existing mailing I can still send it to a previously used group (though I cannot change the recipient lists). The groups load normally in manage group page.
![aE8nz](/uploads/dca6a15c237cbb7612df433a31b769d5/aE8nz.png)
*Issue already reported on CiviCRM Stack Exchange: https://civicrm.stackexchange.com/questions/33070/unable-to-load-the-recipients-group-when-sending-mailing-with-civimail*https://lab.civicrm.org/dev/core/-/issues/3586Denial of service - CiviCRM Fetch Bounces scheduled job will fail to process ...2023-09-12T02:13:33Zjustinfreeman (Agileware)Denial of service - CiviCRM Fetch Bounces scheduled job will fail to process any emails if a single email is sent to the bounce mailbox with an invalid returnPathCiviCRM bounce processing will fail to process any emails if a single email ("Denial of service email") is sent to the bounce mailbox with an invalid returnPath.
CiviCRM will repeatedly try and fail to process the "Denial of service ema...CiviCRM bounce processing will fail to process any emails if a single email ("Denial of service email") is sent to the bounce mailbox with an invalid returnPath.
CiviCRM will repeatedly try and fail to process the "Denial of service email" causing all other emails to remain unprocessed. CiviCRM mail reports are therefore incorrect and ultimately the CiviCRM Fetch Bounces scheduled job fails to perform the job it was designed to do.
Example invalid returnPaths as observed in production:
```
x2108-arfsfufwyfgkvni2x7ww5wvac3eifc2wx3vr1fcwbbysieqppis4ytnyip09xcohck9s1vrm77nbg4xh431tthdsmtmfvfpa@rspf.mxthunderstruck.net
```
```
SRS0=3Ypr33=QM=crm.nothappyjohn.org.au=bounce+b.25211.6039846.eb7e7e8ba282f9d0@airquotes.com.au
```
This problem has been highlighted by the introduction of "Scheduled Job Failures" feature which raises the visibility of this type of problem.
Bounce mailboxes have been observed with 10k to 50k unprocessed emails, depending on the time when the "Denial of service email" was received.
Agileware Ref: CIVICRM-1970https://lab.civicrm.org/dev/core/-/issues/3559CiviCRM bounce processing, processed emails are never deleted from the mailbo...2023-09-08T22:34:57Zjustinfreeman (Agileware)CiviCRM bounce processing, processed emails are never deleted from the mailbox which uses up disk space and provides very little valueCiviCRM bounce processing, processed emails are never deleted from the mailbox which uses up disk space and provides very little value.
Possible solutions:
1. Once a bounce email has been processed it should be deleted from the mailbox,...CiviCRM bounce processing, processed emails are never deleted from the mailbox which uses up disk space and provides very little value.
Possible solutions:
1. Once a bounce email has been processed it should be deleted from the mailbox, or
1. A new Scheduled Job process should be implemented which deletes all processed email which is older than 30 days
Relates to https://lab.civicrm.org/dev/mail/-/issues/108
Agileware Ref: CIVICRM-1977https://lab.civicrm.org/dev/core/-/issues/3556Deleting a sent mailing leaves activities with invalid links to a mailing rep...2023-09-05T10:00:34ZlolcodeDeleting a sent mailing leaves activities with invalid links to a mailing report that doesn't workAssuming: Civicrm uses the default setting "Enable CiviMail to create activities on delivery"
If a mailing is created, sent and then deleted then the recipients of that mailing will have activities that link to a mailing report using an...Assuming: Civicrm uses the default setting "Enable CiviMail to create activities on delivery"
If a mailing is created, sent and then deleted then the recipients of that mailing will have activities that link to a mailing report using an invalid id. If the link is followed the error will be:
> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
> Expected one Mailing but found 0
If clicked from the popup activity view it will just be a network error.
The body of the activity will also be blank after the mailing is deleted.
I am not convinced that allowing sent mailings to be deleted at all is a good design.
Some kind of an archive function might be better.
In the short term however the link should probably be removed from these activities.https://lab.civicrm.org/dev/core/-/issues/3539When communcating with external network services, detect transient failures a...2024-02-12T13:57:20ZmfbWhen communcating with external network services, detect transient failures and queue for retryFor improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bul...For improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bulk mail: Catch transient failures and ensure that they are retried. PRs: https://github.com/civicrm/civicrm-core/pull/11838 https://github.com/civicrm/civicrm-core/pull/11840 (and there are additional failure scenarios possible)
* ...https://lab.civicrm.org/dev/core/-/issues/3514Define interfaces for interacting with newly cleaned up import code2023-04-03T02:29:57ZeileenDefine interfaces for interacting with newly cleaned up import codeThis is a bit of a placeholder but I think it will be necessary for integrations to
- ~~add new user_job_types - currently this is a hard-coded list and the Parser class is hard-coded into it - we probably need to solve this to get the ...This is a bit of a placeholder but I think it will be necessary for integrations to
- ~~add new user_job_types - currently this is a hard-coded list and the Parser class is hard-coded into it - we probably need to solve this to get the csvimporter working~~ these are declared by any class that `implements UserJobInterface`
- alter the metadate - eg inject 'full_name' into the available fields to map to. UPDATE - am wondering if being able to add pseudofields for the api is enough - would work for full_name
- intervene once `getMappedRow` has run
- ideally we would extract out the `lookup` code where matching contacts are found or matching entities and add some interaction there - assuming the hook in `findDuplicates` is not enough. UPDATE - I think intervening at the end of `getMappedRow` will work
- be able to alter the validation of the mapping. I know a form rule could be added by hook but I think a specific hook is cleaner as the hook would also need to alter existing ruleshttps://lab.civicrm.org/dev/financial/-/issues/198Possible improvements to the "Invalid price fields" status check2022-10-11T01:31:47ZDaveDPossible improvements to the "Invalid price fields" status check1. It doesn't tell you WHICH financial type is the problem, and because the manage price sets UI oddly shows blank when looking at the price field definition instead of showing the type, you can't even find it without looking in the db o...1. It doesn't tell you WHICH financial type is the problem, and because the manage price sets UI oddly shows blank when looking at the price field definition instead of showing the type, you can't even find it without looking in the db or api explorer.
* Since one of the error conditions is that the financial type might not even exist anymore, the status check could at least show the id so you could check a backup or something.
* Possibly there could be a "enable all needed financial types" button that just goes and undisables all the needed disabled ones.
2. As far as I know there isn't a way in civi to tell, given just the name of a price set or field, WHERE it's being used, and if that place is CURRENTLY active. This would help the user determine if they even want to spend time on it or simply disable the price set.
* Relatedly maybe the status check should ignore disabled price sets/fields, or at least indicate the status on the check results screen.https://lab.civicrm.org/dev/core/-/issues/3493Afform: Failed to find key by ID or tag (SIGN)2022-12-19T21:18:09ZandyburnsAfform: Failed to find key by ID or tag (SIGN)I created a simple afform submitting a name and it just spins and shows this console error. On Civi 5.50.0, WP 5.8.4 and multisite. I had this issue on 5.46.3 as well. It does submit the contact even though it appears not to.
![image](/...I created a simple afform submitting a name and it just spins and shows this console error. On Civi 5.50.0, WP 5.8.4 and multisite. I had this issue on 5.46.3 as well. It does submit the contact even though it appears not to.
![image](/uploads/98a9537c12d29cda91345959e268d8a0/image.png)
Sometimes only the angular error:
![image](/uploads/4e77c2cbad1b88909dc62e7b4e3d4500/image.png)
No error reported to civi logs.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/3478Afform - email delivery2023-06-29T15:47:01Zaydunsaidan.saunders@squiffle.ukAfform - email deliveryOverview
----------------------------------------
Add an action to enable scheduled Email Delivery of SearchKit results.
Reports provides settings to enable scheduled Email Delivery of reports. The lack of an option to do the same dete...Overview
----------------------------------------
Add an action to enable scheduled Email Delivery of SearchKit results.
Reports provides settings to enable scheduled Email Delivery of reports. The lack of an option to do the same deters some people from using SearchKit - see https://civicrm.stackexchange.com/q/41966/225
Comments
----------------------------------------
Not a high priority item but noting for parity with Reports functionality.