CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-10-23T05:03:22Zhttps://lab.civicrm.org/dev/core/-/issues/2965APIv4 Explorer, displays the Field Name as the selectable option. However, th...2023-10-23T05:03:22Zjustinfreeman (Agileware)APIv4 Explorer, displays the Field Name as the selectable option. However, the Field Label only is visible in the Custom Fields UI and may be different to the Field NameAPIv4 Explorer, displays the Field Name as the selectable option. However, the Field Label only is visible in the Custom Fields UI and may be different to the Field Name.
SearchKit on the other hand does use the Field Label to list the ...APIv4 Explorer, displays the Field Name as the selectable option. However, the Field Label only is visible in the Custom Fields UI and may be different to the Field Name.
SearchKit on the other hand does use the Field Label to list the available fields.
This can make it very difficult to use the APIv4 Explorer to select the correct fields if:
1. There are a large number of fields, and
2. The Field Name differs from the Field Label
This is a very common occurrence on older CiviCRM sites which tend to have fields that have been renamed over time and have a lot of old fields still active on the site.
My preference would be to always list the Field Label when displaying fields in the APIv4 Explorer.
![Screenshot_20211123_084139](/uploads/b71225e09f100a8e78d2c321a05704d1/Screenshot_20211123_084139.png)
Agileware Ref: CIVICRM-1890https://lab.civicrm.org/dev/core/-/issues/3203When using the Search Kit and Form Builder to implement a front-end Search Li...2023-12-20T05:03:24Zjustinfreeman (Agileware)When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?
Ideally, this button would be displayed AFTER the Search button.
![Screenshot_20211112_1744...When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?
Ideally, this button would be displayed AFTER the Search button.
![Screenshot_20211112_174423](/uploads/a065207345c884f41eae014ae25e1a8d/Screenshot_20211112_174423.png)https://lab.civicrm.org/dev/core/-/issues/2940Remove requirement to have a bounce email account setup2022-09-30T20:45:40ZseamusleeRemove requirement to have a bounce email account setupWith some more modern SMTP providers bounce email accounts may not be necessary for CiviMail Bounces to work because e.g. with Amazon SES / Sendgrid you can get the bounces processed via webhooks instead.
However within the code base we...With some more modern SMTP providers bounce email accounts may not be necessary for CiviMail Bounces to work because e.g. with Amazon SES / Sendgrid you can get the bounces processed via webhooks instead.
However within the code base we assume we need a bounce account to generate stuff like [no-reply email address](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Domain.php#L364) or when we are getting [message ids](https://github.com/civicrm/civicrm-core/blob/513f6a469927c5dc5a41905feb7c3cff2cf15f0b/CRM/Campaign/BAO/Petition.php#L548)
It would be nice to get rid of this reliance on it being the default mail account which is the bounce processing one https://github.com/civicrm/civicrm-core/blob/513f6a469927c5dc5a41905feb7c3cff2cf15f0b/CRM/Core/BAO/MailSettings.php#L59
cc @JoeMurrayMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2938Proposal - add created_date, modified_date to civicrm_relationship2022-11-25T02:00:54ZeileenProposal - add created_date, modified_date to civicrm_relationshipIt can be useful to know when a relationship was created in CiviCRM (as opposed to when it started)It can be useful to know when a relationship was created in CiviCRM (as opposed to when it started)https://lab.civicrm.org/dev/core/-/issues/2934Searchkit feedback2023-10-10T05:03:21ZeileenSearchkit feedbackRequest for COUNTIF() in the transforms - ie count if field value > xRequest for COUNTIF() in the transforms - ie count if field value > xhttps://lab.civicrm.org/dev/core/-/issues/2931Deadlocks on acl_contact_cache table2022-07-16T20:22:41ZandyburnsDeadlocks on acl_contact_cache tableWe are seeing the acl_contact_cache table locking up our entire system. The query has been seen running for over 6000 seconds on multiple occasions. Slowly, queries stack up behind this and other requests by other users to use acl_contac...We are seeing the acl_contact_cache table locking up our entire system. The query has been seen running for over 6000 seconds on multiple occasions. Slowly, queries stack up behind this and other requests by other users to use acl_contact_cache stack up as well.
We had not previously set the max_execution_time on the database and that has now been set to 450 on the database, which prevents the long-running query from tangling up the entire system. However, the conflict appears to happen when two users are doing an operation that tries to populate the acl_contact_cache table at the same time.
Our database has almost 900,000 contacts, and almost 500,000 activities logged. So a user goes to search > find activities and leaves conditions blank, and this query occurs:
```
SELECT count(DISTINCT contact_a.id) as rowCount FROM civicrm_contact contact_a LEFT JOIN civicrm_activity_contact
ON ( civicrm_activity_contact.contact_id = contact_a.id ) LEFT JOIN civicrm_activity
ON ( civicrm_activity.id = civicrm_activity_contact.activity_id
AND civicrm_activity.is_deleted = 0 AND civicrm_activity.is_current_revision = 1 ) INNER JOIN civicrm_contact
ON ( civicrm_activity_contact.contact_id = civicrm_contact.id and civicrm_contact.is_deleted != 1 ) INNER JOIN civicrm_acl_contact_cache aclContactCache ON contact_a.id = aclContactCache.contact_id WHERE ( ( civicrm_activity.activity_type_id = 101 AND civicrm_activity.status_id = 9 ) OR ( civicrm_activity.activity_type_id IN (2,3,1,104,109,78,76,85,93,4,5,6,7,8,12,17,19,22,34,40,35,36,37,38,39,44,45,46,47,48,51,58,54,52,80,81,84,94,96,97,99,100,101,103,105,106) ) ) AND aclContactCache.user_id = 26114 AND contact_a.is_deleted = 0 AND (civicrm_activity.activity_type_id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 12, 17, 19, 22, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 54, 58, 76, 77, 78, 80, 81, 82, 84, 85, 86, 87, 93, 94, 96, 97, 99, 100, 101, 102, 103, 104, 105, 106, 107, 109) AND civicrm_activity.`id` IN (SELECT `id` FROM `civicrm_activity` WHERE id IN (SELECT activity_id FROM civicrm_activity_contact WHERE contact_id IN (SELECT contact_id FROM civicrm_acl_contact_cache WHERE user_id = 26114) AND contact_id IN (SELECT `id` FROM `civicrm_contact` WHERE is_deleted != 1))));
```
6000 seconds later, the database is hung, with about 100 queries stuck behind it. Manually killing all processes that are trying to use the acl_contact_cache table will clear out the backlog of other queries.
The table is transitory, as after getting the results there is a truncate almost immediately after.
One proposed solution could be to individualize the acl_contact_cache table to create for each user, eg. acl_contact_cache_{contact_id} … This would allow the acl_contact_cache_XXX table to get locked and not adversely affect every other user on the system.
The system should do a check upon my first search and see if my acl_contact_cache_XXX table is built, if it is not, build it upon all the contacts I have access to (regardless of the particular search).
Additionally the acl_contact_cache_XXX table could persist for a pre-defined period of time (e.g. 1 hour) so it doesn't have to search everyone in the db each time. Same concept for civicrm_group_contact_cache. Could have major performance benefits.
Also finding a way to keep this table from being locked would likely require a reimagination of how the table is actually used. Another consideration would be the use of the MEMORY engine for this table, to permit faster population since its contents are transitory anyway
Thoughts?
@eileen @kcristiano
Similar issue on acl_cache table: https://lab.civicrm.org/dev/core/-/issues/1486.https://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/3245Include random as an option when sorting displays2022-04-22T15:52:35Zjoshjosh@civicrm.orgInclude random as an option when sorting displaysCurrently on SearchKit displays, users can sort by a designated field using either "ascending" or "descending". I propose that we include an option to sort data in a "random" format.
![Screenshot_2021-__1_](/uploads/02ac6ff8f5609eddc51d...Currently on SearchKit displays, users can sort by a designated field using either "ascending" or "descending". I propose that we include an option to sort data in a "random" format.
![Screenshot_2021-__1_](/uploads/02ac6ff8f5609eddc51d64629d9e1ca1/Screenshot_2021-__1_.png)https://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.0