CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-28T05:03:24Zhttps://lab.civicrm.org/dev/core/-/issues/3806Contribution Pages: Spread the Word show on Live Page from start if Enabled.2024-03-28T05:03:24ZBarijohnContribution Pages: Spread the Word show on Live Page from start if Enabled.Overview
----------------------------------------
Currently the Spread the Word Social Media footer on Contribution Pages ONLY appears when you have completed the transaction. This means that it isn't easy to share the page from the dona...Overview
----------------------------------------
Currently the Spread the Word Social Media footer on Contribution Pages ONLY appears when you have completed the transaction. This means that it isn't easy to share the page from the donation page, as you might have missed the opportunity when you complete it.
On Events this is showing as soon as you land on the Event Information Page and I suggest this would be a good improvement on Contribution Pages as well.
Example use-case
----------------------------------------
1. Click on Contribution Link - See Spread the Word. Can share directly from this page to Social Media.
May increase sharing of the page and increase donations. Also it will be shown to users when creating page and they can test it easily.
Current behaviour
----------------------------------------
Currently this ONLY appears when you have completed the full transaction and appears at the confirmation stage. Easy to skip past it as well.
![Contribution_Completed](/uploads/f1a68833823dec4ccd78bb4d12ab4cb8/Contribution_Completed.png)
Proposed behaviour
----------------------------------------
Show the Spread the Word on the main contribution page. As Per the Events Page.
![Screenshot_2022-08-16_at_12.31.16](/uploads/acaa5bedff273314189446561ca8c8be/Screenshot_2022-08-16_at_12.31.16.png)
Comments
----------------------------------------
Thoughts?https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/4954Upgrade to Smarty4....2024-03-15T21:05:34ZeileenUpgrade to Smarty4....Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site...Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site from Smarty2 to Smarty4 are now equivalent to moving to Smarty3.
https://smarty-php.github.io/smarty/5.x/upgrading/#removed-php-constants
One annoying thing we did was name our Smarty mixin & the define in a version specific way. In fact there is nothing v2 specific about our mixin and the methodology of defining ` CIVICRM_SMARTY3_AUTOLOAD_PATH` works for Smarty4 as well as it does for Smarty3. If it wasn't for those naming issues I would recommend we simply replace the contents of packages/smarty3 with the Smarty 4 library.
However, given where we are I recommend we
1) merge Smarty4 into packages here https://github.com/civicrm/civicrm-packages/pull/380
2) add a new define `CIVICRM_SMARTY_AUTOLOAD_PATH` - respect it but fall back to `CIVICRM_SMARTY3_AUTOLOAD_PATH` if present
3) update our demo sites / build sites etc to Smarty4
4) update all our messaging to encourage people to use Smarty4 not 3 (but if they have already switched to 3 don't further message as being off Smarty2 is enough to flush out any extension or issues that would impede our medium term plans to put Smarty4 in vendor & stop shipping Smarty3
Note that Smarty4 hard-fails on `{php}` tags in tpls whereas Smarty3 has a backwards compatibility layer that would have supported it, had we chosen to enable it, which we didn't.5.72.0https://lab.civicrm.org/dev/core/-/issues/3294Make accordion panels accessible2024-03-15T20:39:55ZJoeMurrayMake accordion panels accessibleFrom https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demogr...From https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demographic information, address, etc.) are collapsed by default. It is necessary to use the mouse (JAWS) cursor in order to expand these panels.
A user should be able to expand an collapse an accordion panel by using the keyboard only and not be required to use the mouse. To accomplish this, elements of crm-acordion-header should be made keyboard focusable and be configured to provide feedback to the screen reader on whether they are collapsed or expanded. At the simplest level, these elements could be made buttons instead of divs and be given the aria-expanded attribute which would be dynamically toggled depending on the panel’s state. This will allow a keyboard user to focus the panel header with the tab key and expand or collapse it with ENTER or SPACE. More in-depth examples of accordion accessibility can be found at OAA Accessibility http://www.oaa-accessibility.org/examplep/accordian1/, and Basic Accessible Accordion Panel for jQuery http://www.jqueryscript.net/accordion/Basic-Accessible-Accordion-Plugin-jQuery.html.
Technical spec to come.
Was https://issues.civicrm.org/jira/browse/CRM-208255.73.0https://lab.civicrm.org/dev/core/-/issues/1545Civicrm uses outdated Smarty library2024-03-15T19:29:38ZjptillmanCivicrm uses outdated Smarty libraryThis issue from the old Jira tracker seems to have gotten lost along the way (can't find it in this issue queue):
https://issues.civicrm.org/jira/browse/CRM-16428
It would be great to have the Smarty template library upgraded to v3.This issue from the old Jira tracker seems to have gotten lost along the way (can't find it in this issue queue):
https://issues.civicrm.org/jira/browse/CRM-16428
It would be great to have the Smarty template library upgraded to v3.https://lab.civicrm.org/dev/core/-/issues/1599Deceased Contact via Inline doesn't update the Membership's status to Deceased2024-03-15T14:45:54ZGhost UserDeceased Contact via Inline doesn't update the Membership's status to DeceasedOverview
----------------------------------------
Editing a Contact via Inline to update it to Deceased doesn't update the status of the Membership automatically to Deceased.<br />
Checked in dmaster.
![Inline](/uploads/45fb6021711d8f2e...Overview
----------------------------------------
Editing a Contact via Inline to update it to Deceased doesn't update the status of the Membership automatically to Deceased.<br />
Checked in dmaster.
![Inline](/uploads/45fb6021711d8f2e15535832dbc4e888/Inline.png)
Reproduction steps
----------------------------------------
1. Create a new Contact.
2. Create a Membership in that Contact.
3. Edit the demographics of the contact via Inline and put it deceased.
Current behaviour
----------------------------------------
If you edit the Contact **via Inline**, the Membership **is not updated** to Deceased.
If instead of Inline you edit the Contact, the Membership **is updated** to Deceased.
Expected behaviour
----------------------------------------
The Membership status should be **updated automatically** to Deceased when editing the Contact **via Inline**.https://lab.civicrm.org/dev/core/-/issues/2256create contact: subtype retained after removal2024-02-29T05:03:24Zlcdwebcreate contact: subtype retained after removalTo recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype i...To recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype is created.
Actual result: the student subtype is retained.
I suspect what's happening is that on form submission the subtype field is getting reset via the URL param.
But it poses a question, as I think there are two ways we could approach this:
1. fix the form per the above. on submission, ensure we process the form field value and don't allow the URL param to reset it.
2. freeze the subtype field. one could argue that if I'm choosing to create a New Student I should be locked into that path. we could check to see if a URL param for subtype was passed and then freeze that field. the downside is that it would prevent you from setting multiple subtypes for the contact.
Would like to get some opinions/thoughts from the community before I work on a patch.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/3466On_hold field for phone record2024-02-28T05:03:22Zmagnolia61On_hold field for phone recordOverview
----------------------------------------
I think by design the civicrm_phone table should also have an on_hold field in order to 'block' individual phone numbers from receiving calls and texts.
I think this would help to better...Overview
----------------------------------------
I think by design the civicrm_phone table should also have an on_hold field in order to 'block' individual phone numbers from receiving calls and texts.
I think this would help to better refine the means to comply to privacy regulations.
Current behaviour
----------------------------------------
Only on a contact level do_not_call and do_not_sms are available as options
Proposed behaviour
----------------------------------------
Just like the civicrm_email table individual phone numbers can be 'disabled' from receiving (automatic) texts and calls.
Comments
----------------------------------------
I am not really able to code this but would be able to help think about it and help test.https://lab.civicrm.org/dev/core/-/issues/703Event Registration Confirmation Email missing Custom Location Type Field Data2024-02-27T05:03:25ZjoeglEvent Registration Confirmation Email missing Custom Location Type Field Data**Environment**
CiviCRM 5.9.1 with Drupal 7. Have enabled the following permissions for all drupal users: access all custom data, profile create, register for events, view event info, view event participants. We have a custom "Location T...**Environment**
CiviCRM 5.9.1 with Drupal 7. Have enabled the following permissions for all drupal users: access all custom data, profile create, register for events, view event info, view event participants. We have a custom "Location Type" called "EditedInfo" and a custom profile called "Registration Information" -- the EditedInfo Location Type is set as the default, if it makes a difference. The profile has the default "Your Registration Information" First and Last name fields (Individual - Primary), and the rest of the fields (Email, Phone, Address, etc.,) are of Type "Contact - EditedInfo".
**Problem**
When a user/contact registers for an event everything works flawlessly -- the values for the "EditedInfo" are copied correctly to their fields on the Contact record, the registration occurs and a confirmation email is sent. However, the email has blanks where the values for all the "EditedInfo" information should be. The labels are there, so the template is recognizing the fields, but the values are empty.
**Troubleshooting**
I assumed it was a permissions issue, but I could not get it solved by toggling various permissions on/off. I am not sure what else to look for at this point. I have also switched these "EditedInfo" fields to regular "Primary" fields, and they are successfully included in the email. However, this is undesirable from the CiviCRM administrators perspective and they'd like to use the "EditedInfo" Location Type fields.
Thanks!https://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/3532Determine CiviCRM host and port in Docker-friendly way - via an environment v...2024-02-25T05:03:20ZMichael McAndrewDetermine CiviCRM host and port in Docker-friendly way - via an environment variablehttps://lab.civicrm.org/dev/core/-/issues/3638Provide a fullPage property for message templates2024-02-22T05:03:26ZmfbProvide a fullPage property for message templatesIn various parts of the UI, CiviCRM allows users to send a message template either on its own, or wrapped in a header and footer.
e.g. you can send a message template to a contact.
Or, you can create a mailing based on a message templa...In various parts of the UI, CiviCRM allows users to send a message template either on its own, or wrapped in a header and footer.
e.g. you can send a message template to a contact.
Or, you can create a mailing based on a message template, with additional header and footer.
CKEditor needs different settings at civicrm/admin/ckeditor?preset=civimail re: allowed HTML tags to support these two scenarios. With fullPage = true, the HTML is forcibly wrapped with html/head/body tags, and so a message template that includes its header and footer can be composed. With fullPage = false, html/head/body are silently stripped, so this is useful for message templates that should be used with a header and footer.
However, there is only one CKEditor setting for both of these scenarios.
I would propose a new database column where we can indicate if a message template is "fullPage" - i.e. includes header and footer, or not fullPage, i.e. designed to be used with header and footer.
This would allow us to toggle the fullPage setting appropriately. It would also allow us to prevent a user from sending a message template that needs a header and footer without one, or wrapping a message template that includes its header and footer with an additional header and footer.https://lab.civicrm.org/dev/core/-/issues/3635Emails marked as bounce when quota is full2024-02-22T05:03:25ZEdselopezEmails marked as bounce when quota is fullThere are cases (usually when using Gmail SMTP) when the Outbound email fails to deliver a mailing due to the user's daily quota being exhausted. In this case, if the mailing is re-used unknowingly, attempts to re-send the mailing adds t...There are cases (usually when using Gmail SMTP) when the Outbound email fails to deliver a mailing due to the user's daily quota being exhausted. In this case, if the mailing is re-used unknowingly, attempts to re-send the mailing adds to the bounce threshold, finally surpassing the limit of three bounces, marking the email as "on hold". To solve this, I'm thinking bounce type of "Quota" should be excluded from the calculation of marking the email as on hold. Please let me know if this is reasonable and I will provide a patch.https://lab.civicrm.org/dev/core/-/issues/3631Unexpected behavior from api.MailingEventSubscribe.create2024-02-21T05:03:31ZginkgofjgUnexpected behavior from api.MailingEventSubscribe.createIn creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
* confirm that this is not an unexpected us...In creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
* confirm that this is not an unexpected use of this API,
* confirm that these behaviors are unexpected,
* get two cents from others on the approach, and
* get acceptance criteria for the PR(s) -- i.e., what tests do I need to write/pass?
The unexpecteds:
1. This is cosmetic, but the API metadata are wrong. The API Explorer describes the params as though they were for unsubscription.
2. Suppose contact X is already a member of a mailing group Y. If their IDs are passed to this API, the contact's status in the group is "downgraded" to "Pending" and the user must reconfirm membership by clicking the link emailed to them.
3. The contact's DO NOT MAIL and NO BULK EMAILS Communication Preferences are not updated. These changes should not be effected by the initial API call, but after the user clicks the confirmation link emailed to her.
The approaches:
1. This should be a trivial update to the API's `_spec()` function.
2. The API delegates to `CRM_Mailing_Event_BAO_Subscribe::subscribe()`. I would fix the problem in the delegate by checking for group membership and bailing out early if the record already exists with the appropriate status.
3. Confirmation is handled by `CRM_Mailing_Page_Confirm` which delegates to `CRM_Mailing_Event_BAO_Confirm::confirm()`. I would unset the communication preferences in question in the delegate.ginkgofjgginkgofjghttps://lab.civicrm.org/dev/core/-/issues/3620"View in Browser" does not feed mailing statistics2024-02-19T05:03:28Ztotten"View in Browser" does not feed mailing statisticsI just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more lin...I just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more links.
What happens to the stats?
* The web-based view does not count as an "Open". The MUA may or may not report back the "Open" on the original message.
* You will not have any "Click Through" events logged.
This is because the "View in browser" variant of the newsletter is not instrumented with tracking codes (while the MUA variant of the newsletter does have tracking codes).https://lab.civicrm.org/dev/core/-/issues/3616Should tracking pixel be placed at start of email for when Gmail clips messages?2024-02-18T05:03:26ZlarsssandergreenShould tracking pixel be placed at start of email for when Gmail clips messages?With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open trac...With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open tracking as the tracking pixel is only embedded at the very end of the message and thus isn't fetched unless the reader clicks "View entire message".
Would it be worthwhile to consider putting the tracking pixel at the start of the message to avoid this issue? Obviously, less than ideal for those who don't display images, but I'm not sure how these two might balance out or if there is a clever way to have the best of both worlds.
I'd be happy to provide a patch, but not sure what the best way forward is here.
(Was a former Flexmailer issue, reposted here as I think this is still important.)https://lab.civicrm.org/dev/core/-/issues/3607Feature: Provide an administrative option to make unsubscribe affect all matc...2024-02-17T05:03:32ZlolcodeFeature: Provide an administrative option to make unsubscribe affect all matching email addressesOur organization would like the unsubscribe action to unsubscribe all contacts with the same email from the group. In cases of duplicate contacts they unsubscribe once but one of the duplicates will still get an email and then we get CAS...Our organization would like the unsubscribe action to unsubscribe all contacts with the same email from the group. In cases of duplicate contacts they unsubscribe once but one of the duplicates will still get an email and then we get CASL complaints. Due to CASL we are trying to be cautious by default here.
We suggest an administrative setting for Civimail: "Unsubscribe contact (radio) or unsubscribe email address (radio)"
There was some support for this option expressed in a discussion here: https://chat.civicrm.org/civicrm/pl/sxd4jpwxpbynx8y15994ua7jea
A good point is that this needs to be guarded by token access to stop attackers being able to unsubscribe prominent emails from organisational lists (for example).
A further suggestion was made to make this a user selection option on the unsubscribe page. I feel that this would be a good but separate feature request.https://lab.civicrm.org/dev/core/-/issues/3605"Tracking Click-Throughs" option in mailings generates 404 links when using m...2024-02-17T05:03:31Zjensschuppe"Tracking Click-Throughs" option in mailings generates 404 links when using multi-language with path prefixThis occurred in a Drupal environment with multiple languages and the following configuration:
- Languages in Drupal:
- English (activated)
- German (activated, default)
- Languages in CiviCRM:
- Default language: English
- avai...This occurred in a Drupal environment with multiple languages and the following configuration:
- Languages in Drupal:
- English (activated)
- German (activated, default)
- Languages in CiviCRM:
- Default language: English
- available: German, English
- Inherit CMS language: yes
Conditions under which the erroneous behavior can be reproduced:
- Mailing language: English
- UI language: German
- language prefix in the URL: none or "de"
or:
- Mailing language: German
- UI language: English
- language prefix in the URL: none or "en"
ergo: Using a UI language different from the mailing language and having path prefixes for language detection.
The result is links to the tracking script being prefixed with the language code of the UI language, like so:
https://example.org/de/sites/all/modules/civicrm/extern/url.php?u=123&qid=12345
which is producing a 404 as obviously the path to the script file is not valid due to the language prefix.
Apparently, this code in CRM/Mailing/BAO/TrackableURL.php:93 is where the URL is constructed, but with `userFrameworkResourceURL` being prefixed with the language code:
```
$redirect = $config->userFrameworkResourceURL . "extern/url.php?u=$id";
```https://lab.civicrm.org/dev/core/-/issues/3595Mailing priority2024-02-16T05:03:23ZmfbMailing priorityOrganizations that send mailings to large lists, alongside more important messages sent to smaller lists, may need a mailing priority feature.
For example, a newsletter might go out to subscribers announcing a new campaign, while simult...Organizations that send mailings to large lists, alongside more important messages sent to smaller lists, may need a mailing priority feature.
For example, a newsletter might go out to subscribers announcing a new campaign, while simultaneously a press release is sent to press contacts. The latter would have higher priority.
CiviMail would send messages for mailings with a high priority before those with a lower priority.https://lab.civicrm.org/dev/core/-/issues/3594Core should provide bounce handling (and queueing) for transactional email2024-02-15T05:03:25ZmfbCore should provide bounce handling (and queueing) for transactional emailCurrently CiviCRM core does not provide bounce handling for transactional email. This can result in automated processes sending out a large volume of scheduled reminders, etc. (as well as user-triggered forms sending out subscription co...Currently CiviCRM core does not provide bounce handling for transactional email. This can result in automated processes sending out a large volume of scheduled reminders, etc. (as well as user-triggered forms sending out subscription confirmations, etc.) with only manual bounce handling by humans.
An extension exists to provide bounce handling and other features for transactional emails: https://civicrm.org/extensions/transactional-emails
Arguably, however, this feature should be provided by core itself, so all civi instances have bounce handling for any email message they send.
Assuming we continue the architecture where it is the CiviMail component that provides bounce handling, a solution could be that enabling CiviMail overrides how transactional email is sent, adding the extra bounce processing and other features.
Ideally, transactional email could also be queued by CiviMail, so failures are not fatal and delivery attempts can be retried. Currently, if you are over-quota or your mail delivery provider temporarily suspended your account, then you have real problems when doing some critical thing that sends a transactional email message.