CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-10-23T16:08:42Zhttps://lab.civicrm.org/dev/core/-/issues/2929Geocoding failures kill contributions2023-10-23T16:08:42ZandrewcormickdockeryGeocoding failures kill contributionsOverview
----------------------------------------
Last night between about 6pm and midnight AEDT, it appears that Nominatim (the Open Street Map API provider) had an intermittent outage. Some requests were receiving a 502 error. We hav...Overview
----------------------------------------
Last night between about 6pm and midnight AEDT, it appears that Nominatim (the Open Street Map API provider) had an intermittent outage. Some requests were receiving a 502 error. We have configured this as our Geocoding provider in CiviCRM under /civicrm/admin/setting/mapping?reset=1
People who were using CiviCRM in ways which caused the Geomapping provider to be called were receiving fatal errors as a result. This included people who were making donations (i.e. entering their address on the form which in turn was handed to the Geomapping provider for geocoding).
Current behaviour
----------------------------------------
When a request to the Geomapping provider fails (for example with a 502 error), the generating transaction within CiviCRM returns a fatal error and does not complete. This includes financial transactions, and indeed any administrative function that involves adding or updating a contact's address.
Expected behaviour
----------------------------------------
A Geomapping provider failure should never cause financial transactions to fail. I can't think of any reason why adding or updating an address should fail either. Fatal errors should only occur when an issue occurs which genuinely prevent a transaction from succeeding. A payment can still be processed regardless of whether that person's address can be geocoded or not. I expect a 502 Bad Gateway error from Nominatim would be logged, but never cause an address to fail to be added/updated. Obviously that would occur without the latitude/longitude being recorded. I can't even see the utility in informing the user. It's a system admin problem.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_
* __PHP:__ _7.3__
* __CMS:__ _Drupal 7.82_
* __Database:__ _MariaDB 10.4.21_
* __Web Server:__ _Nginx 1.10.3_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/2928Expand Gender options?2024-01-16T16:07:07ZJoeMurrayExpand Gender options?Overview
----------------------------------------
Currently core has a Gender field with options in tarball of: Male, Female, Other. There has been a great deal of social change in this area with widespread use of additional terms. In ad...Overview
----------------------------------------
Currently core has a Gender field with options in tarball of: Male, Female, Other. There has been a great deal of social change in this area with widespread use of additional terms. In addition, it might be useful to have default questions and options for whether a contact is transgendered and what pronouns they would like.
Example use-case
----------------------------------------
1. Click on **Contacts -> New Individual**.
1. Enter **First Name** and **Last Name** and click **Save**.
Current behaviour
----------------------------------------
![2021-10-26_11-46-51](/uploads/f5985494ccec6ce0c0c143cc688014b2/2021-10-26_11-46-51.png)
Proposed behaviour
----------------------------------------
I'm going to break up the proposal into several parts that can be discussed and possibly approved separately.
1. Add to the list of gender options after Other: Prefer not to specify.
2. After Male and before Other, insert new gender options: Non-binary, Genderfluid.
2. Change from Female to Female/woman and from Male to Male/man.
3. Change the Gender field from single select to multiselect.
4. Add a new core field under Gender: Are you transgender? Yes, No, Prefer not to specify.
5. Add a new core field under the above: What pronouns do you use? He/him/his, She/her/hers, They/them/theirs, Zie/hir/hirs, Other.
6. Make the field for Pronouns multiselect.
An alternative that might make sense is to do some of this in an extension. Another alternative would be to assist with best practices by providing questions or options but defaulting to disabled.
Comments
----------------------------------------
Here is a note from an organization that works in this area in response to my query on behalf of a client for a longer list of genders:
> Coming up with a universal list of terminology to describe trans people can be difficult, since the exact terms used to describe the concepts involved varies dramatically from language to language and culture to culture. While trans communities in Canada and the US tend to use the same terminology, it can vary even with other majority Anglophone countries, to say nothing of the rest of the world.
>
> There is a lot of discussion out there in the data world about how best to record sexual orientation and gender identity (or “SOGI”) data, and best practices depend on the field in question. That said, a good starting point is to divide things into four questions framed like so:
>
> 1. What is your gender? (select all that apply)
> a. Female/woman
> b. Male/man
> c. Non-binary
> d. Genderfluid
> e. Other
> f. Prefer not to specify
>
> 2. Are you transgender?
> a. Yes
> b. No
> c. Prefer not to specify
>
> 3. What pronouns do you use? (select all that apply)
> a. He/him/his
> b. She/her/hers
> c. They/them/theirs
> d. Zie/hir/hirs
> e. Other
>
> Breaking things out like this has several advantages. First, it recognizes that “transgender” is not itself a gender identity, but is an umbrella category that includes certain men, women, and non-binary and genderfluid people. It simplifies the first question, keeping a shorter list for people to have to scroll through to find the proper term to describe themselves. It also allows organizations to easily modify the list to fit their specific use cases – an organization working in Samoa or with a significant Samoan population could add “fa’afafine” to the list while one dealing with a significant Native/First Nations population could add “two-spirit.”
>
> It also permits trans individuals to interact with the organization without either lying or outing themselves, by not forcing them to select either (for example) “cisgender woman” or “transgender woman.” (If you’re not familiar with the term, ‘cisgender’ is a word indicating a person who is not ‘transgender’.) In fact, it also allows the organization to sort their data in such a way that they don’t unnecessarily out trans people to staff and volunteers, by allowing them to pull a list of all women or all men that doesn’t automatically flag whether or not they are transgender.
>
> In addition, it reflects the fact that not all non-binary and genderfluid people consider themselves to fit under the “transgender” umbrella – this is a complicated issue that’s largely unknown outside of the larger LGBTQ community, and is often disregarded by organizations working with these communities.
>
> Finally, it flags the most useful information – what pronouns to use when referring to the person – into a separate easy to reference field that can be included on a display screen or other record without being specifically tied to someone’s transgender status.
>
> Of course, this is only scratching the surface of the issues that might be relevant to a specific organization’s needs. For instance, they should also consider having a separate “legal name” and “preferred name” field – the former is something that would only be referenced when writing checks or otherwise transacting business in the person’s legal name, but have the “preferred name” be what actually displays for all other interactions with the person. This would also allow cisgender people who primarily go by a short form, initials, or nickname to have that be displayed instead of their full name.
>
> A medical organization, meanwhile, might need to collect information on whether or not someone is intersex, or what their “gender assigned at birth” is, and there can be a lot of ways to capture this information based on how the organization interacts with its staff and patients.
>
> For additional discussion on collecting SOGI data, with multiple examples, please take a look at these resources:
>
> https://www.thetrevorproject.org/wp-content/uploads/2021/07/Measuring-Youth-Sexual-Orientation-and-Gender-Identity.pdf
>
> https://williamsinstitute.law.ucla.edu/quick-facts/survey-measures/JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/2926Proposal: "Open in new tab" on .crm-summary-link icons should open contact pa...2022-03-19T14:07:30ZBradley TaylorProposal: "Open in new tab" on .crm-summary-link icons should open contact page, not summary content.When searching for contacts (as well as in some other contexts) each contact has a contact-type icon which shows some extra details on hover:
![Screenshot_2021-10-24_at_15.28.16](/uploads/064fefcdbc311b69c021809af11d6534/Screenshot_2021...When searching for contacts (as well as in some other contexts) each contact has a contact-type icon which shows some extra details on hover:
![Screenshot_2021-10-24_at_15.28.16](/uploads/064fefcdbc311b69c021809af11d6534/Screenshot_2021-10-24_at_15.28.16.png)
Often when searching it is ideal to open each result in a new-tab, whilst keeping the original search page in the original tab. However, when right-clicking on the contact-icon and doing "open in new tab" you get a page something like this (i.e. the contents of the summary popup):
![Screenshot_2021-10-24_at_15.30.27](/uploads/44e0a6aa0c3cdf7486d9c2d2f8f4de1c/Screenshot_2021-10-24_at_15.30.27.png)
I think that this should actually open the contact record instead. (note that click is preventDefault'd, but this doesn't stop the ability to open in a new tab).
Currently the JS uses the `a` element's `href` attribute to populate the summary popup. I suggest that a data attribute is used instead, allowing the `href` to point to the contact record. If we do this, I think there may be an argument for removing the preventDefault on click.
The `crm-summary-link` class may be used by third-party extensions. We can retain backwards compatiability for these extensions by keeping the current logic in cases where the new data attribute is not set.https://lab.civicrm.org/dev/core/-/issues/2864Meta - token usage 5.43 standardisation effort2022-09-02T01:38:26ZeileenMeta - token usage 5.43 standardisation effortWe are doing a big token standardisation in 5.43 to solve multiple issues and blockers. By getting all these changes into 1 release we can also encourage people to specifically test that rc and any changes that they may need to make can ...We are doing a big token standardisation in 5.43 to solve multiple issues and blockers. By getting all these changes into 1 release we can also encourage people to specifically test that rc and any changes that they may need to make can be around the one release - documentation is [here](https://lab.civicrm.org/-/ide/project/documentation/docs/sysadmin/tree/case/-/docs/upgrade/version-specific.md/)
The goal is to consolidate such that
1. All token rendering is done through the token processor, token hooks are redundant and deprecated
2. All functions on CRM_Utils_Token are unused in core and deprecated except for those in the legacy BAO mailing classes.
3. We freeze, deprecate and phase out in legacy BAO classes in favour of flexmailer
4. All core classes that render tokens do so using consistent token naming & output conventions (rather than dates being formatted in various ways and fields sometimes outputting labels and other times values or name fields https://lab.civicrm.org/dev/core/-/issues/2650)
5. As much as possible we render via tokens rather than smarty in workflow message templates (that couples them with the entity rather than any form flow)
6. pdf & email & scheduled reminder tasks consistently offer the same entity-specific, contact & domain tokens
7. We can start to define obvious missing tokens such as `{domain.now}` (done), `{contribution.balance}` and formatted addresses
Task list / streams - this gives some idea of where things are progressing or blocked
- [x] standardise contact tokens to support/ advertise label style (e.g `{contact.prefix_id:label}`
- [x] make Contact tokens work with partial contact inputs - currently they only work with no contact array passed in, or an array with all possible values - currently blocked on a caching bug https://github.com/civicrm/civicrm-core/pull/21790
- [x] split contact tokens into own class & extend entity tokens like the other classes(blocked on stdise contact tokens)
- [x] switch contact tokens to use apiv4
- [x] work through standardising location token loading (this could go further - ie I had thought about adding loading for billing
- [x] date formatting standardisation [documentation](https://docs.civicrm.org/user/en/latest/common-workflows/tokens-and-mail-merge/#date) https://lab.civicrm.org/dev/core/-/issues/2746
- [x] locale sensitive standardised money formatting https://lab.civicrm.org/dev/core/-/issues/2638 & [pr](https://github.com/civicrm/civicrm-core/pull/21783)
- [x] switch badge tokens to use token processor
- [x] event tokens cleanup & loading fixes + remove unindexed query, move the `fee_amount` and `balance` tokens to the participant tokens class, fix event class to listen to either 'participantId' or 'eventId'. Participant class should run first & load eventId if required. Events should be cached in a static cache as it would be very rare to message thousands of events in one run.
- [x] Recurring contribution tokens work (currently availble in only the recurring_edit template with a pr to extend to cancelled recurring https://test.civicrm.org/job/CiviCRM-Core-PR/44632/
- [x] pdf letter is sane (https://lab.civicrm.org/dev/core/-/issues/2790) enough to extend to deliver tokens for other entities (participant https://lab.civicrm.org/dev/core/-/issues/780)
- [x] email letter extend to deliver tokens for other entities (membership & participant) (https://lab.civicrm.org/dev/core/-/issues/2862)
- [x] scheduled reminders supports participant tokens https://lab.civicrm.org/dev/core/-/issues/779
- [x] domain tokens are consistently available & render https://lab.civicrm.org/dev/core/-/issues/2838 - done but a gap on case tasks as they prioritise being able to filter tokens by case type
- [x] install flexmailer on new installs https://lab.civicrm.org/dev/core/-/issues/2836
- [ ] fix remaining places that process tokens other than via the payment processor
- [x] eliminate replaceGreeting - currently [blocked on apiv4 caching bug](https://github.com/civicrm/civicrm-core/pull/21790)
- [ ] fix CRM_Contact_BAO_Contact_Utils::updateGreeting to not call `getTokenDetails`
- [ ] confirm civicrm_api3_mailing_preview is replaced by flexmailer
- [x] remove getTokenDetails call from CRM_Contribute_Form_Task_PDFLetter - note this appears to be an expensive way to call the contact api & tokens are unused https://github.com/civicrm/civicrm-core/pull/21805
- [x] remove extra rendering in BAO_Pledge https://github.com/civicrm/civicrm-core/pull/21789
- [x] removed getTokenDetails from updatePledgeStatus https://github.com/civicrm/civicrm-core/pull/21847
- [x] remove getTokenDetails from transitionParticipants
- [ ] remove getTokenDetails from sendCancellation & cancelParticipant in selfsvc flow
- [ ] deliverGroup - replaced by flexmailer?
- [ ] MailingPage::preview - replaced by flexmailer?
- [ ] remove hook:;tokenValues from label task
- [ ] getAnonymousTokenDetails ???
- [ ] confirm BAO_Mailing::compose is only via flexmailer
- [x] communicate rc status via dev list
- [x] communicate changes via blog
- [ ] upgrade message https://lab.civicrm.org/dev/core/-/issues/2871
- [ ] docs update to these instructions / check it can still all be done https://docs.civicrm.org/dev/en/latest/step-by-step/create-custom-case-token/
**Currenly out of scope**
- [ ] Token.getlist api - until we have this we have an issue with audience-filtering and with switching tokens depending on the schema. Also case tasks still have to render tokens weirdly without this because they currently filter by case type with partial success https://lab.civicrm.org/dev/core/-/issues/2788
- [ ] Clarify how extensions should render tokens https://lab.civicrm.org/dev/core/-/issues/2863
- [ ] encourage flexmailer with status checks on existing installs https://lab.civicrm.org/dev/core/-/issues/2836
Analysis of current token rendering it core:
Method | Used in | Status
-- | -- | --
Use the token processor | scheduled reminders, civimail with flexmailer in use, activity pdf task | This is the method we are consolidating all paths to use.
Use the functions in CRM_Utils_Token | PDF tasks other than activity | Migrated (PRs on [membership](https://github.com/civicrm/civicrm-core/pull/21521) and [contribution](https://github.com/civicrm/civicrm-core/pull/21524). Also work on fixing up the [pdf task class](https://lab.civicrm.org/dev/core/-/issues/2790) supporting[add participant tokens](https://lab.civicrm.org/dev/core/-/issues/780) (once we’ve finished [the standardisation of those](https://github.com/civicrm/civicrm-core/pull/21587))
| Email tasks | Migrated to token processor. Added tokens for other entities (participant, membership https://lab.civicrm.org/dev/core/-/issues/1396) [also see](https://lab.civicrm.org/dev/core/-/issues/2862)
| Export tasks (when merging contacts in export) | Migrated to token processor
| Profile link rendering | Migrated to token processor
| Storing contact greetings (eg. email_greeting_display) | In progress. Currently resolving inconsistent token syntax and load issues as this needs to be able to use partial pre-loads
Use random ad hoc code | Event badges | [migrated](https://github.com/civicrm/civicrm-core/pull/21587) - this is the only place outside of scheduled reminders where event or participant tokens were used in core
| Send SMS task (BAO_Activity::sendSMS) | migrated
| Labels task CRM_Contact_Form_Task_Label | argh
| CRM_Event_Form_SelfSvcTransfer | Still pretty argh - but this is a workflow message template so the fix is a bit different
| Transition participants | Also a workflow - possibly redundant as seems to be mostly about contact tokens which are resolved in the send function anyway
| Pledge acknowledgements | Also appear to be redundant
| CiviMail with flexmailer not used (many functions & classes) | Push the switch to flexmailer.
| Various unsubscribe / resubscribe type actions | Probably out of scope for this roundhttps://lab.civicrm.org/dev/core/-/issues/2863Agree / document how tokens should be rendered from outside core2023-09-24T22:52:19ZeileenAgree / document how tokens should be rendered from outside coreIdeally we would have one recommended api way to do this. This would be a way that is usable via api explorer and all the ways we use the api and core code would be converted to do things using that same api method
There is [a documenta...Ideally we would have one recommended api way to do this. This would be a way that is usable via api explorer and all the ways we use the api and core code would be converted to do things using that same api method
There is [a documentation pr here](https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/962) - at the moment I don't think it meets this need.
**Permissions & non-workflow rendering**
There is a question as to whether the api would support non-workflow messaging (in which case the api would likely be more like `Message::render()`. The argument against is that the permissions are more complex. However some notes on that
1) the most common use case is probably when checkPermissions = FALSE in php code.
2) there is an appropriate permission already in core
```
render templates' => [
$prefix . ts('render templates'),
ts('Render open-ended template content. (Additional constraints may apply to autoloaded records and specific notations.)'),
],
```
3) currently the v3 MessageTemplate.send api allows access to the core function - it required a messageTemplateID to be set - but this can probably be faked to allow 'any text'https://lab.civicrm.org/dev/core/-/issues/2858Importing soft credit payments by email address fails with confusing message ...2022-06-11T23:42:51ZjhungerfordImporting soft credit payments by email address fails with confusing message if dedupe rule requires extra fieldsOverview
----------------------------------------
Importing soft credit payments (matched to existing contacts by email address) fails if the relevant Unsupervised dedupe rule requires any extra fields. The error message in this case is:...Overview
----------------------------------------
Importing soft credit payments (matched to existing contacts by email address) fails if the relevant Unsupervised dedupe rule requires any extra fields. The error message in this case is:
`Invalid email address(doesn't exist) email@example.com. Row was skipped`
The proposed change passes any required fields to the dedupe check if they are available in the import, but does not amend the error message if it fails.
Example use-case
----------------------------------------
- Add to the Unsupervised rule so it requires First and Last names as well as email address
- Import soft credit payments where the Fundraiser ID is set by External Identifier (or Contact ID) and the Donor is matched by email, First Name, and Last Name
Current behaviour
----------------------------------------
Currently each row in such an import will fail with this message:
`Invalid email address(doesn't exist) email@example.com. Row was skipped`
Proposed behaviour
----------------------------------------
If the required fields are available in the import data, they could be passed to the dedupe function. This is what I've done here (on version 5.39.2):
https://github.com/AsylumSeekersCentre/civicrm-core/commit/c924fb95a2e311a442656bf65c23523091d351da
If the required fields are not available, it would be better if the error message pointed the user in the right direction. Currently it says that the email address does not exist, but in the case of our import, all of the email addresses did exist for contacts of the appropriate type. I haven't addressed this part of the issue with the code above.
Comments
----------------------------------------
I think the patch above is not the whole solution. That code pathway is used when there is no External Identifier or Contact ID but there is an email address. It then calls the Unsupervised dedupe rule, which may not refer to the email address at all (though the default does). The change I've proposed accommodates extra fields added to the rule, but doesn't consider the possible removal of the email address from the rule.5.51.0https://lab.civicrm.org/dev/core/-/issues/2761Proposal: Change Pay Later Billing Address to look up a profile rather than a...2022-10-04T21:07:14ZBarijohnProposal: Change Pay Later Billing Address to look up a profile rather than a coded block.Overview
----------------------------------------
Currently on the pay later option when you use the option of Billing Address the fields are hard coded. This would be better to use a profile then it could be edited by the end user witho...Overview
----------------------------------------
Currently on the pay later option when you use the option of Billing Address the fields are hard coded. This would be better to use a profile then it could be edited by the end user without having to mess with the code.
Example use-case
----------------------------------------
Click on Pay Later Option and enable Billing Fields. This shows multiple fields that might not be required depending on the part of the world. So in that case there could be a reserved profile just for billing fields. This could have a help field to show where this profile is saved, so it would easily amended.
Current behaviour
----------------------------------------
Currently this is set in Core/Payment.php and /civicrm/templates/CRM/Core/BillingBlock.tpl (based on communications with our devs).
Proposed behaviour
----------------------------------------
Make this block look up a billing address profile instead.
Comments
----------------------------------------
Currently this field asks for information that isn't required in the UK and most of our clients would like to be able to edit this directly.https://lab.civicrm.org/dev/core/-/issues/2760Proposal: Stop storing file ids in two tables2023-04-17T15:39:24ZcolemanwProposal: Stop storing file ids in two tablesFile fields in CiviCRM are strange.
When you upload a file to a custom field, it stores a record in the `civicrm_file` table. Then it stores that id in **two** other tables. Once in the custom value column for that field, as you'd expec...File fields in CiviCRM are strange.
When you upload a file to a custom field, it stores a record in the `civicrm_file` table. Then it stores that id in **two** other tables. Once in the custom value column for that field, as you'd expect, and then it also adds a record in the `civicrm_entity_file` table.
https://github.com/civicrm/civicrm-core/blob/5.40/CRM/Core/BAO/CustomValueTable.php#L161-L171
From a data archetecture POV, there's no upside to storing the same value twice in two places, it just creates problems.https://lab.civicrm.org/dev/core/-/issues/2755Proposal: add `civicrm_contact.image_file_id` column2023-04-20T00:24:59ZcolemanwProposal: add `civicrm_contact.image_file_id` columnProblem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_...Problem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_contact.image_URL` column with a link to an ajax callback for accessing the image.
3. Not create a record in the `civicrm_file` table.
4. Not create a record in the `civicrm_entity_file` table.
**Deleting a contact image in the UI will:**
1. Not delete the file.
2. Set `civicrm_contact.image_URL` to `null`.
Proposed New Behavior
-------------------
*Add a `civicrm_contact.image_file_id` column, FK to `civicrm_file.id`.*
**Uploading a contact image will:**
1. Store the file as before.
2. Update the `civicrm_contact.image_URL` column as before.
3. Create a record in the `civicrm_file` table.
4. Store the file id in the `civicrm_contact.image_file_id` column
5. *Undecided:* should an entry also be created in `civicrm_entity_file`? See #2760
**Deleting a contact image in the UI will:**
1. Delete the file if an id is present in `image_file_id` column.
2. Set `civicrm_contact.image_URL` and `civicrm_contact.image_file_id` to `null`.
See PR https://github.com/civicrm/civicrm-core/pull/21141https://lab.civicrm.org/dev/core/-/issues/2752Financial entity permissions2023-11-08T05:03:19ZeileenFinancial entity permissionsI hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions ...I hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions on all financial entities should be 'view all contributions' because otherwise we will keep hitting issues where part but not all of a contribution can be retrieved
@JoeMurray @monish.deb @seamusleehttps://lab.civicrm.org/dev/core/-/issues/2750Events RSS Feed doesn't include Event Date Field2023-09-14T05:03:24ZBarijohnEvents RSS Feed doesn't include Event Date FieldOverview
----------------------------------------
Add Event Date to Event RSS template to allow easy aggregation into external websites.
Example use-case
----------------------------------------
To display events on an external website ...Overview
----------------------------------------
Add Event Date to Event RSS template to allow easy aggregation into external websites.
Example use-case
----------------------------------------
To display events on an external website using the inbuilt RSS feed and CiviCRM Event functionality to reduce duplication of work.
Current behaviour
----------------------------------------
```
<item>
<title>Fall Fundraiser Dinner</title>
<link>https://dmaster.demo.civicrm.org/civicrm/event/info?reset=1&id=1</link>
<description> Kick up your heels at our Fall Fundraiser Dinner/Dance at Glen Echo Park! Come by yourself or bring a partner, friend or the entire family! This event benefits our teen programs. Admission includes a full 3 course meal and wine or soft drinks. Grab your dancing shoes, bring the kids and come join the party! When: January 26th, 2022 5:00 PM through January 28th, 2022 5:00 PM Where: 14S El Camino Way E Collinsville, CT 6022 United States </description>
<category>Fundraiser</category>
<author>development@example.org</author>
<guid isPermaLink="false">CiviCRM_EventID_1_f90c7968e68e8bc667d6d4c8808f6985@dmaster.demo.civicrm.org</guid>
</item>
```
Proposed behaviour
----------------------------------------
Remove author and add Event Start Date and Time.
Comments
----------------------------------------
Currently the default display of the RSS Feed doesn't include the start date of the event which makes it rather pointless as a RSS feed into external websites. I am sure this used to be there but it was rather a long time ago! It has the field of author which I don't feel is a useful field at the expense of start date at least.https://lab.civicrm.org/dev/core/-/issues/2746Tokens - formatting syntax2021-11-03T09:24:42ZeileenTokens - formatting syntaxOne of the issues with our tokens is around formatting - or the lack of options around it - consider the following requirements (these are a little artificial but are representative of various requests)
1) I want to insert a birth date ...One of the issues with our tokens is around formatting - or the lack of options around it - consider the following requirements (these are a little artificial but are representative of various requests)
1) I want to insert a birth date in the standard formatting (I think that is 'long date'
2) I want to insert a birth date using short format
1) I want to insert Month of birth into an email, in the language in use
1) I want to add text if someone was born before a certain date
2) I want to use conditional that checks whether the month of birth is higher than today's month
We can visualise these as
```
Hey
Your birthday was on {contact.birth_date}, or for short {contact.birth_date|short}.
You were born in the month of {contact.birth_date|F}
{if {now|m} > {contact.birth_date|m}sorry I missed your birthday {/if}
{if {contact.birth_date|raw} < '1960-01-01'}You are pretty old ya know{/if}
```
Note that similar concerns apply to 'amount' fields where the need for 'raw' amounts is quite common.
Options as I see them are
1) never do anything to support format flexibility
2) define a pseudotoken formatting syntax for them - somewhat like above
3) define a pseudofield formatting syntax for them - this is basically 2 but with dots instead of pipes - we could also use double underscores
4) add a process (I thought we might be able to do this in token smarty but I'm not quite sure) that assigns a smarty token for every resolved token. ie if {contact.birth_date} is resolved then ALSO assign {$contact__birth_date}. Always assign in raw format. This would give template users the option of using smarty variables as interchangeable, more flexible versions. Over time we could alter what is advertised & promote smarty as preferred, if we choose.
**Some notes**
1. I haven't dug into how hard 4 would be - my gut says it is doable but is likely to wind up in the too hard basket if we extend that conversation to other templating engines (eg. twig) - which might be a good reason to look at 2 or 3 instead
1. It turns out that where smarty is enabled 'now' can already be printed out - ie `{$smarty.now|date_format:'%d %b %Y %H:%M:%S'}`. this is interesting because there are at least 3 extensions that make it available as a custom token....
2. Formatting thoughts - smarty uses [strftime formatting](https://www.php.net/strftime) eg. '%d %b %Y %H:%M:%S'. I feel like most of us would be more comfortable with strtotime formatting however, my efforts to understand the difference suggest that it is strftime not strtotime that handles formatting by locale so I feel pretty sure we should use strftime formats + our own standins - ie `dateformatDatetime`, `dateformatFull` `dateformatPartial` `dateformatYear` (we have a few more that we are currently storing strtotime style - ie `dateformatFinancialBatch` `dateformatshortdate` and `dateInputFormat` (brain explodes)
.
@totten @colemanw @seamuslee5.43.0https://lab.civicrm.org/dev/core/-/issues/2745Tokens - contributions - could we show them all?2021-09-29T04:58:14ZeileenTokens - contributions - could we show them all?The tokens available in the contribution tokens is a list of tokens people thought would be handy and wrote in - the list differed between the action schedule & the send letter and in some cases advertised tokens didn't work on one of th...The tokens available in the contribution tokens is a list of tokens people thought would be handy and wrote in - the list differed between the action schedule & the send letter and in some cases advertised tokens didn't work on one of those places. That reconcilliation is complete with https://github.com/civicrm/civicrm-core/pull/21046 merged.
However, we wind up with a list of available tokens that is 'all the fields on the contribution record except for 9 - which are in the screen shot below. I could make a weak case for excluding 'is_template_contribution' and a stronger case for excluding 'contact_id' but not for the others.
![image](/uploads/a8f29423e15b6c5e631da08b780fbcb7/image.png)
Options
1) include all tokens
2) include all tokens but hard-code out contact_id since it is likely to be confused with {contact.id} & potentially {membership.id}
3) include all tokens but add some form of metadata to Contribution.xml like <token>FALSE</token> and add that to contact_id & is_template_contribution (defaults to TRUE if not set)
@totten @colemanw @seamuslee5.43.0https://lab.civicrm.org/dev/core/-/issues/2730Consider replacing fopen() call in CRM_Utils_File::isIncludable with stream_r...2021-08-09T12:58:54ZDaveDConsider replacing fopen() call in CRM_Utils_File::isIncludable with stream_resolve_include_path()The problem is depending on how strict your setup is, some code that uses the error suppression operator (e.g. `@unlink('file_which_may_not_exist')`) behaves differently in php 8 and doesn't get supressed, either flooding your logs or ma...The problem is depending on how strict your setup is, some code that uses the error suppression operator (e.g. `@unlink('file_which_may_not_exist')`) behaves differently in php 8 and doesn't get supressed, either flooding your logs or making civi unusable in some cases.
In particular the api magic function provider uses an algorithm for e.g. getfields, where often the first guess is wrong, leading to an error.
isIncludable was added in 2011, and while stream_resolve_include_path was available at that time, it was introduced into php in 2010, so it's possible not a lot of sites had it.5.41.0https://lab.civicrm.org/dev/core/-/issues/2720Consider bringing export permission into core2024-02-26T05:03:21ZeileenConsider bringing export permission into coreI took a look at https://github.com/progressivetech/net.ourpowerbase.exportpermission in the light of https://github.com/civicrm/civicrm-core/pull/20945 and felt like maybe this should be in core. It basically adds and checks 4 permissio...I took a look at https://github.com/progressivetech/net.ourpowerbase.exportpermission in the light of https://github.com/civicrm/civicrm-core/pull/20945 and felt like maybe this should be in core. It basically adds and checks 4 permissions
- 'Access "Export as CSV" drop down menu item from actions menu on after search/report'
- Access "Print" drop down menu item from actions menu on search/report
- Access "Print/Merge document (PDF Letter)" drop down menu item from actions menu on search/report
- Access "Print Mailing Labels" drop down menu item from actions menu on search/report
In terms of reasons why this would be better in an extension than core - here are some questions I think we would consider
1) does it impose a maintenance burden on core (in this case I would say no)
2) does it have/need unit tests. In this case (incredibly) I would be OK without tests - but they would be super-easy to add to https://github.com/civicrm/civicrm-core/pull/20944
3) does it meet a generic needs or a specific need - this feels fairly generic
4) does it over-complicate using core
5) is it just too hard to negotiate with the community on this topic.
My suspicicion is that the reason for not putting this in core in the past falls between 4 & 5 - ie. some people feel that adding more permissions over-complicates the permissions UI as a matter of principle. But I think it's worth asking the question againhttps://lab.civicrm.org/dev/core/-/issues/2669Target contact missing for automatically generated case activities2023-02-23T16:00:45ZAndreasandreas.howiller@civiservice.deTarget contact missing for automatically generated case activitiesOverview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cann...Overview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cannot be edited through the user interface. While this is a minor issue, some users may want to leave notes about the activity (for example, why they changed a case title) and therefore need to edit it.
Reproduction steps
----------------------------------------
1. Open any case in CiviCRM and change the case title.
2. Tap edit for the corresponding activity in the activity timeline.
3. Tap save.
Current behaviour
----------------------------------------
The dialog will freeze while the CiviCRM logo keeps turning. A fatal error "DB Error: constraint violation" will be filed in the logs.
If you add any contact as a target contact in the database or in the edit screen the error won't appear anymore.
What is confusing, too: When editing the activity the client contact already wrongly shows up as target contact in this dialog and if you'd like to change it there you need to search the contact (the link to choose the client contact below the search field won't do the change here).
Expected behaviour
----------------------------------------
The Client contact is filed as target contact by default and connected problems disappear. E.g. editable activities can be saved after edit through UI now.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_ and _5.38.0_
* __CMS:__ _WordPress 5.7.2_https://lab.civicrm.org/dev/core/-/issues/2650Use consistent token syntax for pseudoconstants2022-09-01T07:55:13ZeileenUse consistent token syntax for pseudoconstantsAt some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core...At some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core/pull/20591) I want to constrain this issue to the very narrow question of syntax for pseudoconstants & unique names in tokens.
If we look at [the test](https://github.com/civicrm/civicrm-core/blob/275686a34ca7bf5e9c4d6653cd8cca5cf15e36cf/tests/phpunit/CRM/Contribute/Form/Task/PDFLetterCommonTest.php#L264) we can see the current tokens supported by the existing code. A somewhat different set is supported by the [TokenProcessor class for contributions](https://github.com/civicrm/civicrm-core/blob/c2a33d9c890f81bf2287351f0a830ef58b1dc98c/CRM/Contribute/Tokens.php#L26)
So we can see that in one place you would pass
{contribution.contribution_status_id} to get 'Pending'
and in the other it would be {contribution.status}
We are also 'promoting' (by presenting in the UI selector) {contribution.contribution_source} over {contribution.source} in how we present tokens, even though in this case I think both work.
I would propose that our preferred tokens adhere to apiv4 style conventions as much as possible. Preferring means that we work towards the following (on an ad hoc basis).
1) the tokens that are selectable in the UI on the form return the preferred variants
2) we support the preferred variants in tested code on both token methods
3) we run db update scripts to replace the less preferred with the preferred in the msg_template and action_schedule tables as we feel safe doing so
4) we deprecate less preferred variants by adding deprecation notices to places where they are used, when we feel safe doing so.
Proposed conventions
1) deprecate unique name prefixing - ie prefer {contribution.source} over {contribution.contribution_source}
2) actual field name returns the value of that field - ie {contribution.contribution_status_id} would return a number rather than a string
3) we use apiv4 style tokens for labels - ie {contribution.contribution_status_id:label}
(out of scope for this issue = apiv4 style custom field names or custom fields in general, returning calculated values for eg. contribution.check_number)
If we go with the above the specific action I will add to my (long) todo list is to engage with fixing contribution_status_id to make it consistent between the 2 classes and the selector - ie
1) Replace the 'advertised' token from
``` 'contribution.contribution_status_id:label' => 'Contribution Status'```
'contribution.contribution_status_id:label' => 'Contribution Status'
2) add tested support for ```'contribution.contribution_status_id:label'``` to both classes
3) fix any core message templates to use 'contribution.contribution_status_id:label'
4) fix the upgrade script to str_replace 'contribution.contribution_status_id' in the message template table (only)
The other fields in this space that are currently inconsistent are
- financial_type_id, campaign, payment instrument id, cancel_date, source
@colemanw @totten @seamuslee @mattwire5.43.0https://lab.civicrm.org/dev/core/-/issues/2644Proposal - new core extension for scheduled reminders using criteria from sea...2023-08-28T12:20:35ZeileenProposal - new core extension for scheduled reminders using criteria from search-kitThis replaces https://lab.civicrm.org/dev/core/-/issues/2267 as a way to address the same issue - ie our search criteria for scheduled reminders is way too brittle due to the inflexible schema. For example it is not possible to use contr...This replaces https://lab.civicrm.org/dev/core/-/issues/2267 as a way to address the same issue - ie our search criteria for scheduled reminders is way too brittle due to the inflexible schema. For example it is not possible to use contributions > x amount or contributions from campaign y.
Given that we Apiv4 / search kit is the way we are going with search criteria it makes sense to use these as criteria for the reminder search too to replace (in the distant future) the existing fields.
#2267 proposed adding api params & api entity to the scheduled reminder table but I now think it makes more sense as an extension - which I have been experimenting with.
This extension does not have to go into core - it could be something I just maintain to the degree I see fit.
However, the main reason we would consider it as a core extension is that it could eventually replace the existing scheduled reminder form (which would fit our LEXIM plan to get off quick forms and onto everything being apiv4 based). The hope is not to replace the additional functionality in CiviRules for people who want that but to reduce pain points in the scheduled reminder code that is already in core and as a path away from maintaining the relevant quickforms.
Note that if we proceed with this as a core extension I will PR it in once it hits 'alpha' but we would not enable by default and we can have a discussion at that point as to whether it should be hidden or not depending on how mature it is.
I note @totten's response to the question as to whether it should go into core rather seemed to hinge on whether the UI is any good - and since it's not yet written we can't address that at this stage.https://lab.civicrm.org/dev/core/-/issues/2639Money: Plan to migrate from currency separators from locale2023-08-16T05:03:18ZeileenMoney: Plan to migrate from currency separators from localeThere is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com...There is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com/civicrm/civicrm-core/pull/20296#issuecomment-855377189
"Override currency separators" - "By default CiviCRM will format currency in accordance with the locale for the user that is viewing the information"
I've moved the text below from a comment on the github PR to here ....
In terms of adding a setting I went hunting for where it was discussed before & it is here
https://github.com/civicrm/civicrm-core/pull/19753
![image](https://user-images.githubusercontent.com/336308/120940640-63d47800-c772-11eb-8b46-302f4d311ef3.png)
Further down the same PR is the content that was pasted into the dev-digest
![image](https://user-images.githubusercontent.com/336308/120940681-92eae980-c772-11eb-9ff9-588d1e3ca663.png)
Compared to @mattwire's suggestion this is
1) implicitly opt in at the start - ie let early adopters set it & when we are confident be more aggressive
2) a different setting name / description - I think setting money_locale might be less intuitive short term (since it magically disables the other settings) and more intuitive longer term since the other settings should become meaningless & disappear over time.
Revisiting @jaapjansma's comment
![image](https://user-images.githubusercontent.com/336308/120940808-33410e00-c773-11eb-9bae-9910a3ff7583.png)
It DOES seem like site locale is going to be wanted as a setting - although it could be that this is not the point where we add ithttps://lab.civicrm.org/dev/core/-/issues/2638Money - create new Civi:: facade - now format helper2023-09-24T22:53:25ZeileenMoney - create new Civi:: facade - now format helperOur CRM_Utils_Money class wound up a mess so we talked about creating a new supported/tested/readable class to put our money functions in and this class would be supported for use by core & external code.
@seamuslee did a first cut here...Our CRM_Utils_Money class wound up a mess so we talked about creating a new supported/tested/readable class to put our money functions in and this class would be supported for use by core & external code.
@seamuslee did a first cut here https://github.com/civicrm/civicrm-core/pull/20296 which highlighted some of the issues / complexity
I made comments there but I've moved them to this gitlab
Useful framing by @jaapjansma
CiviCRM has the following ways of displaying data:
- On the screen in back office (this is the language and locale of the logged in user)
- On the screen in front office screens (such as registering for an event, this should be the sites locale and language)
- In communications with the contact, such as letters and pdf. We should use the language and locale of the contact
Ideally we should also have a setting for the locale and not only the language.
Looking at @jaapjansma's list it seems that at the end of the day we want (these don't have to be all working / added now but I think we might want to comment in the intent into the class)
```
Money()->formatMachine($amount, $currency);
Money()->formatSiteLocale($amount, $currency);
Money()->formatUserLocale($amount, $currency, $contactID); // defaults to logged in user
Money()->formatSpecifiedLocale($amount, $currency, $locale);
```
We also have 2 other variables in the mix - precision & noCurrencySymbol
I tend to prefer to use separate functions for noCurrencySymbol - eg
```
Money()->formatNumericOnlyMachine($amount, $currency);
Money()->formatNumericOnlySiteLocale($amount, $currency);
Money()->formatNumericOnlyUserLocale($amount, $currency, $contactID); // defaults to logged in user
Money()->formatNumericOnlySpecifiedLocale($amount, $currency, $locale);
```
but it could be a consistent parameter in the other functions
On the precision question we have
- fixed precision
- no rounding
- currency specific precision
Perhaps this is a parameter on all the above functions ('fixed', NULL or 'by_currency' ) - I personally prefer documenting that in the comment block than using a constant although some people like constants
This is quickly getting us back into the confusion of CRM_Core_Money which this PR was intended to get us away from but hopefully we can figure out the set of signatures we want this time AND remember what they actually mean!
Also - we probably want functions that returns the actual Money object - not just the output
Note that where we want to be is that the CRM_Utils_Money class can be an internal class and the Civi::Money is an external class - so how we deal with the thousand separator in CRM_Utils_Money can change over time