CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-02-20T09:29:00Zhttps://lab.civicrm.org/dev/core/-/issues/4920Support the import of all API4 entities2024-02-20T09:29:00ZMichael McAndrewSupport the import of all API4 entitiesIt would be good to support importing of all APIv4 entities in core.
I found four extensions with a reasonable number of downloads that implement improvements to importing:
* https://civicrm.org/extensions/api-csv-import-gui by @eileen...It would be good to support importing of all APIv4 entities in core.
I found four extensions with a reasonable number of downloads that implement improvements to importing:
* https://civicrm.org/extensions/api-csv-import-gui by @eileen
* https://civicrm.org/node/5879 (csv import helper) by @artfulrobot
* https://civicrm.org/extensions/advanced-import by @bgm
* https://civicrm.org/extensions/option-value-importer by@sluc23
But most (if not all?) of these extensions are built on API3.
It would be great to have something built with API4 since this would allow import of any new 'API4 first' entities that are created in core and in extensions (including new entities that have been created with ECK @jensschuppe).
So I am wondering if there are any other initiatives to improve import in the works? And if anyone has the appetite for creating an import core extension that is powered by APIv4 with the long term aim of replacing and enhancing the core import functionality? Perhaps starting with one of the existing ones as a base.https://lab.civicrm.org/dev/core/-/issues/5000SearchKit: Allow formatting of the totals in the footer2024-02-14T10:06:39Zsimon.hermannSearchKit: Allow formatting of the totals in the footerSearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either ...SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either an option to choose a formatting (decimal separators, thousand separators, currencies if applicable etc) or if the total would reflect the formatting of the column it sums.https://lab.civicrm.org/dev/core/-/issues/4992Standalone - front-end theming2024-02-14T10:01:23ZufundoStandalone - front-end theming@artfulrobot suggests: provide a template for front facing pages. People can edit that file
(manually) to suit. It should not get overwritten on upgrade.@artfulrobot suggests: provide a template for front facing pages. People can edit that file
(manually) to suit. It should not get overwritten on upgrade.RichRichhttps://lab.civicrm.org/dev/core/-/issues/4991Standalone SSO - third-party authentication for single sign on, such as Hybri...2024-02-14T10:01:04ZufundoStandalone SSO - third-party authentication for single sign on, such as HybridAuth or LDAP or SAMLWould be great to build out the standalone users functionality.
Either in Standaloneusers extension or a separate one?Would be great to build out the standalone users functionality.
Either in Standaloneusers extension or a separate one?ufundoufundohttps://lab.civicrm.org/dev/core/-/issues/4982Form builder - Extension provided entity settings2024-02-14T09:53:44ZseamusleeForm builder - Extension provided entity settingsJMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter ...JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter angular hook https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L76 however this means that even on non petition related form builder forms they will show up.
This is about seeing if there is a better way to achieve this and or see if we can get them put onto the specific settings page for say GeotargetedPetition Entity.
@JoeMurray @Edselopez @colemanwhttps://lab.civicrm.org/dev/core/-/issues/4873SearchKit - Add inputMode setting to allow clauses to reference column values...2024-02-12T16:30:40ZsamuelsovSearchKit - Add inputMode setting to allow clauses to reference column values in conditionsRelated to https://github.com/civicrm/civicrm-core/pull/28112
The next step is to allow the feature of field selection for conditions :
![image](/uploads/c400052bf32ca7944a87fdae2d2d3bf6/image.png)
I believe it's already possible from...Related to https://github.com/civicrm/civicrm-core/pull/28112
The next step is to allow the feature of field selection for conditions :
![image](/uploads/c400052bf32ca7944a87fdae2d2d3bf6/image.png)
I believe it's already possible from the managed file so it's likely only a UI limitation.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/2915Proposal: Remove the Group Visibility terminology "Expose Publicly" as it has...2024-02-08T23:31:11Zjustinfreeman (Agileware)Proposal: Remove the Group Visibility terminology "Expose Publicly" as it has unintended connotations and would be good to standardise the terminology to describe "Group Visibility" and its optionsThis is a proposal to:
1. Remove the **Group Visibility** terminology _Expose Publicly_ as it has unintended connotations (as pointed out to me today by a Lawyer) and
2. Would be good to standardise the terminology to describe **Group Vi...This is a proposal to:
1. Remove the **Group Visibility** terminology _Expose Publicly_ as it has unintended connotations (as pointed out to me today by a Lawyer) and
2. Would be good to standardise the terminology to describe **Group Visibility** and its options. Ideally making it more obvious as to the purpose of each option.
As described on https://docs.civicrm.org/user/en/latest/organising-your-data/groups-and-tags/#visibility
* **Group Visibility**: **Public pages / Expose Publicly** - if you want to allow contacts to join and remove themselves from this group via Registration and Account Profile forms
* **Group Visibility**: **User and User Admin Only** - if membership in this group is controlled only by authorised CiviCRM users
As I understand it, this option _only_ applies to **Mailing List, Group Types**.
# Expose Publicly
![expose-publicly](/uploads/8d44c054f82a86d8fe92f8f7cd535663/expose-publicly.png)
# Group Visibility and options
![visbility](/uploads/7c4069b330d413230996fab273d242f4/visbility.png)https://lab.civicrm.org/dev/core/-/issues/2396Translation support for Afforms & Managed Search Displays2024-02-07T17:45:35ZseamusleeTranslation support for Afforms & Managed Search DisplaysAs per https://lab.civicrm.org/extensions/afform/-/issues/22 and https://lab.civicrm.org/extensions/afform/-/issues/8 looks like there needs to be some improvements to support multilingual sites in AfformAs per https://lab.civicrm.org/extensions/afform/-/issues/22 and https://lab.civicrm.org/extensions/afform/-/issues/8 looks like there needs to be some improvements to support multilingual sites in Afformhttps://lab.civicrm.org/dev/core/-/issues/3462Event location search2024-01-31T10:18:23Zaydunsaidan.saunders@squiffle.ukEvent location searchOverview
----------------------------------------
Following on from #2103 - when configuring an event and reusing a location, Civi shows a message like 'This location is used by 2 other events' but does not indicate which events.
It w...Overview
----------------------------------------
Following on from #2103 - when configuring an event and reusing a location, Civi shows a message like 'This location is used by 2 other events' but does not indicate which events.
It would be useful to show a list of those locations, or include a link to search for them.
Note that SearchKit displays now handle LocBlocks (see #2676)https://lab.civicrm.org/dev/core/-/issues/4883[5.68.1] pre-minified source-less file: "bower_components/es-module-shims/dis...2024-01-29T10:13:51ZDmitry Smirnov[5.68.1] pre-minified source-less file: "bower_components/es-module-shims/dist/es-module-shims.js"`bower_components/es-module-shims/dist/es-module-shims.js` is bundled in pre-minified source-less form, which is bad practice.
Please bundle original un-compressed/un-obfuscated source, readable and modifiable by humans.
It looks like ...`bower_components/es-module-shims/dist/es-module-shims.js` is bundled in pre-minified source-less form, which is bad practice.
Please bundle original un-compressed/un-obfuscated source, readable and modifiable by humans.
It looks like bundling the following file should suffice: https://github.com/guybedford/es-module-shims/blob/1.7.2/src/es-module-shims.js
Thanks.5.70.0https://lab.civicrm.org/dev/core/-/issues/4899Modelling many to many relationships with Entity reference, SearchKit, FormBu...2024-01-17T18:18:18ZMichael McAndrewModelling many to many relationships with Entity reference, SearchKit, FormBuilder, ECK, etc.Creating this issue as a way to keep track of different bits of functionality that can be used together to model many to many relationships in CiviCRM as when you put this all together, I think it is quite a game changer for data modelli...Creating this issue as a way to keep track of different bits of functionality that can be used together to model many to many relationships in CiviCRM as when you put this all together, I think it is quite a game changer for data modelling in CiviCRM :grinning:
Might make sense to document this at some point soon, and it would be good to collect feedback on how people are finding this functionality, ideas for improvement, etc.
Also, if you have any budget that you would like to put towards this work: to improve it or build out more features, etc. please get in contact with @colemanw or me :heart:.
* Entity Reference fields - allows you to reference other entities in custom data fields effectively creating **one to many** relationships.
* Multivalue custom data sets - [now available to all entities](https://github.com/civicrm/civicrm-core/pull/27549) allowing you to model **many to many** relationships _with additional meta data_ about the relationship
* Searchkit support for [joining via EntityRef fields in multivalue custom data](https://github.com/civicrm/civicrm-core/pull/28721) - allows you to create searches that span many to many joins
* FormBuilder support - allowing for editing of many to many relationships in entities (could probably do with some improvement)
* [ECK](https://github.com/systopia/de.systopia.eck) which allows people to make arbitrary new entities that can be joined via these relationshipshttps://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/4907Event full inconsistencies2024-01-15T11:35:24ZeileenEvent full inconsistenciesThe way EventFull is calculated in apiv4 is not consistent with elsewhere
apiv4 returns a field `'remaining_participants'` which is
event.max_participants - COUNT(participant rows for the event where contact is not deleted, participant ...The way EventFull is calculated in apiv4 is not consistent with elsewhere
apiv4 returns a field `'remaining_participants'` which is
event.max_participants - COUNT(participant rows for the event where contact is not deleted, participant is not test and participant status is_counted)
By contrast apiv3 returns the contents of `CRM_Event_BAO_Participant::eventFull()` which also takes into account the participant role and other aspects of the status
`eventFull()` has some funky parameters - there are 12 calls to it
| caller | returnEmptySeats |includeWaitingList|returnWaitingCount|considerTestParticipant|onlyPositiveStatuses|
| ------ | ------ |------ |------ |------ |------ |
| apiv3-event | TRUE |TRUE|FALSE|FALSE|FALSE|
| Participant::eventFullMessage | FALSE |FALSE|FALSE|FALSE|FALSE|
| Participant::eventFullMessage(2) | FALSE |TRUE|TRUE|FALSE|FALSE|
|ParticipantStatusType::process|TRUE|FALSE|FALSE|FALSE|
|ParticipantTest|FALSE|TRUE|FALSE|FALSE|FALSE|
|Registration::preProcess|FALSE|if-event-has-waitlist|FALSE|FALSE|FALSE|
|Registration::preProcess(2)|TRUE|if-event-has-waitlist|FALSE|FALSE|FALSE|
|Event_Confirm::formRule|FALSE|if-event-has-waitlist|FALSE|FALSE|FALSE|
|ParticipantConfirm|TRUE|FALSE|TRUE|FALSE|TRUE|
|Register::preProcess|FALSE|if-event-has-waitlist|FALSE|FALSE|FALSE|
|EventInfo::run|FALSE|if-event-has-waitlist|FALSE|FALSE|FALSE|
|event-cart|TRUE|TRUE|FALSE|FALSE|FALSE|
Note that this issue somewhat relates/ explains
https://lab.civicrm.org/dev/event/-/issues/23https://lab.civicrm.org/dev/core/-/issues/3832PHP 8.2 utf8_encode and utf8_decode functions deprecated2024-01-11T18:31:16ZBradley TaylorPHP 8.2 utf8_encode and utf8_decode functions deprecatedIn PHP 8.2 (planned to be released this November) `utf8_encode` and `utf8_decode` functions will be deprecated.
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
I don't see this causing too many problems for CiviCRM, and mos...In PHP 8.2 (planned to be released this November) `utf8_encode` and `utf8_decode` functions will be deprecated.
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
I don't see this causing too many problems for CiviCRM, and most uses are in upstream packages and libraries. However there are some uses in core itself (especially `utf8_decode`) which should be replaced.https://lab.civicrm.org/dev/core/-/issues/4868Add action for copy activity2023-12-20T19:16:21ZyashodhaAdd action for copy activityWe do have copy action on various entities like _Contribution Page_, _Events_.
It might be handy to have the same for _Activity _as well.
Also provide _Save as New_ feature/ when clicked we can have a new activity created with addition...We do have copy action on various entities like _Contribution Page_, _Events_.
It might be handy to have the same for _Activity _as well.
Also provide _Save as New_ feature/ when clicked we can have a new activity created with additional tweaks based on a pre-existing activity. This would come esp handy for activities which have lots of Activity Contacts/Targets/assignees and custom dat awith the original activity acting as a template.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4842Allow bulk-enabling extensions through UI2023-12-08T13:17:56ZnoahAllow bulk-enabling extensions through UICurrent behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to...Current behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to select multiple extensions and perform the same action (Install, Disable, Uninstall) on all of them.https://lab.civicrm.org/dev/core/-/issues/4809Backend register for event via credit card has problematic pre-help text and ...2023-12-06T23:06:43ZDaveDBackend register for event via credit card has problematic pre-help text and should be completely removed and replaced with only a translation-friendly indicator of live vs testCopied from https://github.com/civicrm/civicrm-core/pull/28309
I think the [tpl line](https://github.com/civicrm/civicrm-core/blob/6c6fdea6429f39d552d0cc6bae0254d27daa4919/templates/CRM/Event/Form/Participant.tpl#L31) needs to be comple...Copied from https://github.com/civicrm/civicrm-core/pull/28309
I think the [tpl line](https://github.com/civicrm/civicrm-core/blob/6c6fdea6429f39d552d0cc6bae0254d27daa4919/templates/CRM/Event/Form/Participant.tpl#L31) needs to be completely replaced. I would remove the first sentence since it adds no value since right above it already says the name when it's present, and when it's not present is the cause of this notice, and then the second sentence is not correct in other languages (the "live"/"test" is always in english). Elsewhere the approach for that when there's a known list of values is to just hardcode the full sentences in an `{if}` block.
I do think it's important to identify if it's live or test, but since none of the above has been raised as an issue the help text itself seems very unimportant. Maybe it should just have some kind of icon indicating live or test and that's it.https://lab.civicrm.org/dev/core/-/issues/3070Placeholders in forms2023-12-06T15:27:43ZshaneonabikePlaceholders in formsOverview
----------------------------------------
_Please describe your improvement in detail._
Example use-case
----------------------------------------
1. View a Contribution form
1. Fields such as _First name_ do not have a placehold...Overview
----------------------------------------
_Please describe your improvement in detail._
Example use-case
----------------------------------------
1. View a Contribution form
1. Fields such as _First name_ do not have a placeholder and only a label
Current behaviour
----------------------------------------
I think that in general providing placeholders is a good practice for all fields for the following reasons:
+ More accessible
+ Simplifies design (hidden labels) reduces the size of forms
Proposed behaviour
----------------------------------------
I was thinking there could be two ways to make this happen to start.
+ Provide placeholders that match the labels (Phase 1)
+ Provide ability on all fields with text entry to have a customizable placeholder (Phase 2)
Comments
----------------------------------------
Would there be any problem with me writing a patch that would allow the creation of placeholders for text holders that presently uses the label and copies that into a placeholder field?https://lab.civicrm.org/dev/core/-/issues/3152Data stored in universal time does not handle DST consistently2023-11-30T05:00:20ZtottenData stored in universal time does not handle DST consistently[[_TOC_]]
Overview
----------------------------------------
CiviCRM has a number of `TIMESTAMP` columns -- these are stored in universal time (UTC) and displayed in the user's timezone. However, there is a subtle error in handling Dayl...[[_TOC_]]
Overview
----------------------------------------
CiviCRM has a number of `TIMESTAMP` columns -- these are stored in universal time (UTC) and displayed in the user's timezone. However, there is a subtle error in handling Daylight Savings Time (DST): if the current-date and the target-date sit on different sides of the DST-switch, then the time may present as +/- 1 hour.
This bug was one of the major subissues identified in https://lab.civicrm.org/dev/core/-/issues/2122. Although that particular feature was rolled-back/deferred from 5.47, the DST bug still exists -- it's just less obvious.
Example use-case
----------------------------------------
1. Create a contact record.
2. View the contact record. Note the creation time (`civicrm_contact.created_date`).
3. Change the system clock - set to a date where DST differs (eg if today is March 30, then go to December 5).
4. View the contact record. Note the creation time (`civicrm_contact.created_date`).
Current behavior
----------------------------------------
The displayed value of `civicrm_contact.created_date` _appears_ to change by +/- 1 hour, depending on when you view it.
> (Viewed on Mar 31, 2022)
>
> ![Screen_Shot_2022-03-31_at_12.40.53_AM](/uploads/8a2f5a0e4fb6ec884aede78e30d31b1a/Screen_Shot_2022-03-31_at_12.40.53_AM.png)
> (Viewed on Dec 5, 2022)
>
> ![Screen_Shot_2022-12-05_at_12.44.57_AM](/uploads/2df387488ee029a949010da163bf2ea8/Screen_Shot_2022-12-05_at_12.44.57_AM.png)
Why? CiviCRM sends a note to MySQL about the current user's timezone (`SET time_zone = '...'`). However, it doesn't identify the timezone effectively. It gives [the current numeric offset (at the moment of viewing)](https://github.com/civicrm/civicrm-core/blob/5.47.3/CRM/Utils/System/Base.php#L758-L762) - but (in locales with DST) the offsets fluctuate over time.
(_Ex: On Mar 31, the offset in California is `-0700`. Under current/long-standing law, the offset will be `-0800` on Dec 5. Of course, the US Congress is reconsidering this law... so we don't really know what the offset will be!_)
Proposed behavior 1: Fix MySQL timezones
----------------------------------------
CiviCRM should send the timezone as a symbolic name, such as `Europe/Helsinki`, `America/Los_Angeles`, or `Australia/Sydney`. These symbolic-names have an underlying database which allows them adjust automatically based on DST-rules/target-dates/current-law. On the surface, the fix is extremely simple:
```diff
diff --git a/CRM/Utils/System/Base.php b/CRM/Utils/System/Base.php
index a4660834c5..8e40f6da35 100644
--- a/CRM/Utils/System/Base.php
+++ b/CRM/Utils/System/Base.php
@@ -755,10 +755,9 @@ abstract class CRM_Utils_System_Base {
* Set timezone in mysql so that timestamp fields show the correct time.
*/
public function setMySQLTimeZone() {
- $timeZoneOffset = $this->getTimeZoneOffset();
- if ($timeZoneOffset) {
- $sql = "SET time_zone = '$timeZoneOffset'";
- CRM_Core_DAO::executequery($sql);
+ $timeZone = $this->getTimeZoneString();
+ if ($timeZone) {
+ CRM_Core_DAO::executequery('SET time_zone = %1', [1 => [$timeZone, 'String']]);
}
}
```
There are a couple of catches.
* __Timezone rules change__ (occasionally). Any software that supports timezones ultimately needs a _data feed_ with current rules. The good news: IANA publishes a free/open feed (https://www.iana.org/time-zones; aka `tzdata`; aka `zoneinfo`), most Linux/Unix distros have this feed, and MySQL can read it (`mysql_tzinfo_to_sql`). It usually requires one command (which could run during system-config, system-startup, and/or cron):
```bash
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql mysql
```
The problem: we have no measures for (a) how many CiviCRM deployments actually subscribe to this feed and (b) how many could subscribe, if they chose to.
* __Timezone names may be inconsistent__ (occasionally). For example, in different contexts, it's been fashionable to refer to California's timezone as `America/Los_Angeles`, `US/Pacific`, and `PST8PDT`. (The current+official fashion is `America/Los_Angeles` - the others are deprecated.) However, since Civi integrates with various layers (different CMSs; PHP APIs; MySQL APIs), there are edge-case where the layers may choose different names. (*I'm not super-concerned, but we should raise sensible warnings when names are invalid or mismatched.*)
The central issue is - how to cope when data isn't available? This comes to mind:
* (Status check) If the active TZ (`getTimeZoneString()`) has a deprecated name (eg `PST8PDT`) or an offset (eg `-0700`), show a warning.
* (Status check) If the active TZ (`getTimeZoneString()`) isn't supported by MySQL, show a warning.
* (Runtime) If the active TZ (`getTimeZoneString()`) isn't supported by MySQL, fallback to sending offset.
Proposed behavior 2: Change format. Use only PHP TZs.
----------------------------------------
(_This expands on one of @haystack's suggestions in dev/core#2122._)
If you assume that MySQL time services aren't available - what else would you do? You could use PHP time services.
The astute observer will note the status-quo (using both PHP and MySQL time-services) creates two points-of-failure. If either PHP _or_ MySQL has bad/incomplete/old timezone data, then you'll get mis-calculations _somewhere_. Consolidating on PHP time-services would reduce the #dependencies.
Both Drupal and WordPress take this approach. (I suspect this is extremely useful for maximizing compatibility with heterogeneous web-hosts.) They each do it a bit differently, but some central concepts are the same:
* In Drupal, PHP processes read+write temporal data in universal time -- as an `INT` (Unix-style, seconds-since-epoch).
* In WordPress, PHP processes read+write temporal data in universal time -- as a `DATETIME` with a `_gmt` suffix (eg `post_modified_gmt`).
* Hypothetically, you could hardcode MySQL to `SET time_zone='+0:00'`. PHP processes would read+write temporal data in universal time -- as a `TIMESTAMP`.
In all those cases, the onus is on the PHP devs to convert to/from universal-time when implementing functionality (eg "find records from March 1 - March 15" or "find records from this afternoon" or "extract the hour:minute component").
But there is a catch here: Civi already relies on several MySQL time-services. The schema works a certain way; the reports/searches/UIs/APIs expect the schema to work a certain way; etc.
The central issue is - how do you manage/QA all the changes (in schema+logic) required to change time-service?
Comments
----------------------------------------
* I haven't tested, but I'm fairly certain there will be another manifestation in CiviMail scheduling. Ex:
* You live in a timezone where DST changes on March 16.
* On March 10, you schedule a mail-blast for 2:00pm on March 20. It stores the schedule with the wrong offset.
* When March 20 comes, the mailing actually goes out at 3:00pm (or maybe 1:00pm).https://lab.civicrm.org/dev/core/-/issues/3103Document contract for alterMailParams2023-11-23T17:28:30ZDaveDDocument contract for alterMailParamsThe data in $params for alterMailParams is inconsistent, and with recent token changes has changed in some cases.
Copied from https://github.com/civicrm/civicrm-core/pull/22878, which is specific to message template emails (there are al...The data in $params for alterMailParams is inconsistent, and with recent token changes has changed in some cases.
Copied from https://github.com/civicrm/civicrm-core/pull/22878, which is specific to message template emails (there are also other types of emails that trigger alterMailParams):
> Quote
* Add a class CRM_Event_WorkflowMessage_OfflineReceipt. This would look a lot like CRM_Contribute_WorkflowMessage_ContributionOfflineReceipt which describes contribution_offline_receipt. (Also, there's some draft docs in https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/987.)
* Add a variant of hook_alterMailParams which gives the message as an object. Here's a sketch for firing+consuming hook_alterWorkflowMessage [gist](https://gist.github.com/totten/14178dabea79ea2a5a639a5b928262e2).