Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-29T15:47:01Zhttps://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.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/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/3501Featrure Request: tracking engagement on contact records2022-09-27T23:23:59ZhescoFeatrure Request: tracking engagement on contact recordsOverview
----------------------------------------
_Please describe your improvement in detail._
I have been watching a seminar program entitled "The Web 3.0 Future", offered by the ASK Method.
They have been reviewing the implication...Overview
----------------------------------------
_Please describe your improvement in detail._
I have been watching a seminar program entitled "The Web 3.0 Future", offered by the ASK Method.
They have been reviewing the implications of changes to iOS 14 and 15. iPhones account for better than 50% of ne cell phone purchases. Their recent upgrades position privacy as a unique selling proposition for Apple. This has the effect of disrupting the business model of meta/facebook/instagram/etc and google/youtube/etc (responsible for roughly 85% of available ad inventory between them). The ripple effects impact all the businesses and organizations whose strategies depend on those platforms for lead generation.
In addition, the iOS 15 upgrade, along with corporate strategies within Apple, have rendered email open-rates as bogus and undependable. The only reliable data we have on email list subscription engagement levels it seems are click-throughs.
For a number of reasons discussed in today's segment if this seminar, it is becoming extremely important, in terms of email deliverability to be able to track by contact and to segment our lists by engagement history.
CiviMail does an excellent job of reporting on performance metrics for a mailing. What it fails to do it seems is to expose that data on individual contact records so we can meaningfully measure engagement by contact and use those measurements to segment our lists in appropriate ways for purposes both of list hygiene, and also for protecting sender reputation with the large email providers by managing email frequency by engagement history.
Example use-case
----------------------------------------
1. Click on **Contacts -> New Individual**.
1. Enter **First Name** and **Last Name** and click **Save**.
Send a CiviMail.
Current behaviour
----------------------------------------
_What is currently possible? What limit ?_
CiviMail does an excellent job of reporting on performance metrics for a mailing. What it fails to do it seems is to expose that data on individual contact records so we can meaningfully measure engagement by contact and use those measurements to segment our lists in appropriate ways for purposes of relationship building, list hygiene and protecting sender reputation with the large email providers by managing email frequency based on engagement history.
Proposed behaviour
----------------------------------------
_What should happen? How is this better? If appropriate/available, include any wireframes or mockups._
CiviMail needs a means for exposing its engagement data on a contact record. In the activity view, I want to see not just that an email was sent, but also whether it was delivered, opened and clicked on. If opened, how often, when and from what IPs? If clicked on, the activity view should allow me to drill down to examine which links were clicked and how often, and perhaps also provide a link back to the mailing itself and its performance report.
CiviMail would benefit from shipping with a default rule, but also having hooks allowing CiviRules to be used to define an installation-specific two-deminsional engagement score for a contact, based on frequency and recency of engagement. The contact search tools need to a means for searching based on this engagement score. Smart groups would benefit being dynamically built based on this engagement score.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/financial/-/issues/196Proposal: Account for new Mastercard regulations for recurring contributions2022-09-20T17:19:38ZJonGoldProposal: Account for new Mastercard regulations for recurring contributionsThere's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of en...There's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of enrollment that includes the terms of the subscription and instructions on how to cancel the subscription
* Send a receipt after every successful billing attempt that includes instructions for how to cancel this subscription (this can be instructions to call customer service)
* Provide an online cancellation method (similar to unsubscribing from emails) – that can be instructions to call customer service
* For any subscription/recurring payment plan that bills a cardholder less frequently than every six months, the merchant must send a notification at least seven days prior to the billing date that includes the terms of the subscription and instructions on how to cancel the subscription
* Merchants have until Sept 21, 2022, to meet this requirement.
It seems like `civicrm_contribution_recur.is_email_receipt` should be ignored if the card type is Mastercard. It also seems like a new Scheduled Job is necessary for folks who have recurring contributions that are less frequent than six months.https://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/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/core/-/issues/3682Feature request - `{domain.logo}`2023-09-25T19:36:31ZeileenFeature request - `{domain.logo}`Tim & I discussed the other day adding the `{domain.logo}` token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored...Tim & I discussed the other day adding the `{domain.logo}` token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored work.
However, I think the thing we CAN do is document it....
**The easy way**
`{domain.logo}`
refers to the image (if any) in the image_url field for the domain contact. That's it.
Probably we would need a version with `<img>` tags & one without.
**But then ... sizing & ^^ is too basic/ limited**
So next most complex is to use a setting. Once we start down this path we wind up having to develop a UI, handling sizing and it seems we might as well skip to....
**Mailing Component tokens**
In this version we would add a new component type to `civicrm_mailing_component` and rows of this type would be available as tokens using `{domain.{civicrm_mailing_component.name}}`. Placeholders ones for '{domain.logo}' and '{domain.header}' would be added. The existing UI could be used.
**And still spiralling**
- from there we got into trying to make it possible to nest the above, to use regions, to do the sort of thing the `entity_messages` token attempted to whereby we could store entity-related snippets (the idea was both to be able to insert a contribution specific block and to store entity-specific text to re-use - e.g to re-send an invoice with the original form-base message text)https://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/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/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/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/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/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/3730Search Kit: data exported to spreadsheet as strings where numbers expected2023-08-25T14:47:13ZAndreasandreas.howiller@civiservice.deSearch Kit: data exported to spreadsheet as strings where numbers expectedOverview
----------------------------------------
When exporting spreadsheets from Search Kit in some cases data types seem to be exported incorrectly as strings where they should be numbers.
Reproduction steps
------------------------...Overview
----------------------------------------
When exporting spreadsheets from Search Kit in some cases data types seem to be exported incorrectly as strings where they should be numbers.
Reproduction steps
----------------------------------------
1. Create Search Kit search for **Contributions** on demo.
2. Add columns for **Total Amount** and **Date Received** and click **Search**.
3. Export results via **Action** → **Download Spreadsheet** and choose **.ods** (or **.xlsx**).
4. Open document with office software.
Current behaviour
----------------------------------------
While the Contribution ID column is correctly formatted as a number, Total Amount and Date Received are formatted as **strings**.
Note: Numbers are also left-aligned in Search Kit exports (column A).
Here is what the file looks like in LibreOffice 6.4.7.2:
![grafik](/uploads/ede5de9d9898448c1e0d2676863cfc17/grafik.png)
…and here the corresponding XML in content.xml:
![grafik](/uploads/9487cc0e42f0980eb08e958bea23e7f4/grafik.png)
Expected behaviour
----------------------------------------
Numbers and Date fields are exported in correct data type.
Additional ideas / Comments
----------------------------------------
- it would probably be very useful to have **more Field Transformations** to have some choice for data types, esp. to be able to output money values with our without money signs
- maybe numbers should not be left-aligned anymore (as it is the standard behaviour in spreadsheets)
Environment information
----------------------------------------
* CiviCRM: 5.52.alpha1 and 5.50.3
* PHP: 7.4
* CMS: WordPress 6.0 and Drupal 9.3.14https://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/3740Set default lock level to READ COMMITTED2023-10-20T07:57:25ZJoeMurraySet default lock level to READ COMMITTEDDrupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with ...Drupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with deadlocks, primarily on rebuilding group contact cache when there are hierarchies of smart groups. Should CiviCRM be more explicit about what isolation level we expect in order to get more repeatable results, and should we follow Drupal in its move to READ COMMITTED? I tend to think so.
See responses in MM chat from @demeritcowboy
https://chat.civicrm.org/civicrm/pl/gnmhfdxes7rgb8k7ppoaezo45ahttps://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/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/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.