CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-08-30T15:49:10Zhttps://lab.civicrm.org/dev/core/-/issues/4134SearchKit: Add TIMESTAMPDIFF to calculate between two dates in years, months,...2023-08-30T15:49:10ZfrancescbassasSearchKit: Add TIMESTAMPDIFF to calculate between two dates in years, months, weeks, etc.Overview
----------------------------------------
Allow to calculate number of days, weeks, months, years, etc. between two dates.
[DATEDIFF](https://github.com/civicrm/civicrm-core/pull/24875) only allows to calculate difference betwee...Overview
----------------------------------------
Allow to calculate number of days, weeks, months, years, etc. between two dates.
[DATEDIFF](https://github.com/civicrm/civicrm-core/pull/24875) only allows to calculate difference between two days in days. Instead, TIMESTAMPDIFF allows set the unit (years, months, weeks, etc.) units in which you want to get the difference between two dates.
Eg. to calculate age of a contact at the time they registered for an event between contact birthday and registration event date.
Current behaviour
----------------------------------------
Can't calculate years between two dates.
![datediff](/uploads/b7a37ccd3a0c048750934fadc5cf5763/imatge.png)
Proposed behaviour
----------------------------------------
Can calculate years (and FRAC_SECOND (microseconds), SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, QUARTER) between two dates.
![timestampdiff1](/uploads/6dcc9610fd2fc195d2157007f3b71fba/Captura_de_pantalla_de_2023-02-17_09-36-56.png)
![timestampdiff2](/uploads/b6e7b2822f7a55eee279ea251536f913/imatge.png)
Comments
----------------------------------------
TIMESTAMPDIFF can in principle reproduce the same behavior as DATEDIFF. If so, current _Days between two dates_ field transformation could be replaced with _Diff between two dates_ ensuring that it continues to work for old cases.https://lab.civicrm.org/dev/core/-/issues/4066Can the `CRM_Event_Badge` classes be deprecated and removed?2023-07-03T14:20:54ZBradley TaylorCan the `CRM_Event_Badge` classes be deprecated and removed?I recently came across these classes:
- `CRM_Event_Badge`
- `CRM_Event_Badge_Logo`
- `CRM_Event_Badge_Logo5395`
- `CRM_Event_Badge_NameTent`
- `CRM_Event_Badge_Simple`
Stylistically they're not great, and I noticed they don't seem to b...I recently came across these classes:
- `CRM_Event_Badge`
- `CRM_Event_Badge_Logo`
- `CRM_Event_Badge_Logo5395`
- `CRM_Event_Badge_NameTent`
- `CRM_Event_Badge_Simple`
Stylistically they're not great, and I noticed they don't seem to be in use.
The last 4 of these classes extend `CRM_Event_Badge`, and are referenced in the `eventBadge` option group. However, I can't see any scenario where this `eventBadge` option group is actually used.
The `Event Name Badge Layouts` configuration screen gets stored in the `civicrm_print_label` table, and `CRM_Badge_BAO_Badge` is what actually get's used when you print a selection of badges for an event. `CRM_Badge_BAO_Badge` does not use `CRM_Event_Badge` (although they are very similar. I suspect one started as a copy of the other.)
I think it would make sense to:
1. Check nobody is using the 5 classes listed above through a universe search.
2. Noisily deprecated the 5 classes, specifying `CRM_Badge_BAO_Badge` should be used instead.
3. After a period of time remove the 5 classes.
4. Tidy up (remove all trace of) the `event_badge` option group.
Of these, the last step is the one I'm most unsure of the process for. I guess it'd be removed through an upgrade step.https://lab.civicrm.org/dev/core/-/issues/4041Should we hard-code messages that event registration cancellations are not re...2022-12-20T10:01:32ZlarsssandergreenShould we hard-code messages that event registration cancellations are not refundable?Self-service cancellation of event registrations does not support refunds, so there are at least two places where the registrants are told that there are no refunds (in the registration confirmation email if self-service cancellation is ...Self-service cancellation of event registrations does not support refunds, so there are at least two places where the registrants are told that there are no refunds (in the registration confirmation email if self-service cancellation is enabled and when they actually try to cancel, though this has been broken since 5.43).
I wonder if it makes sense for CiviCRM to put this expectation that there are no refunds into code. Even though refunds are not supported via the self-service form, organizations may have policies that are different and may manually process refunds in some cases. I think it would make more sense to simply not say anything about refunds and allow organizations to define their own policies in the event registration.
So my proposal: Remove the warning about no refunds from self-service cancellation (which doesn't currently work anyways), remove the text about no refunds from event registration confirmation templates and remove the help text that mentions no refunds from the self-service cancellation option on the event registration set up.
It's far from ideal either way, but I think leaving it open is better than specifying a policy that may not work for all.https://lab.civicrm.org/dev/core/-/issues/3961Proposal: Create stub extensions for civicrm core + all components2023-07-13T10:41:05ZcolemanwProposal: Create stub extensions for civicrm core + all components*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so i...*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so is no longer relevant to this issue.
**Motivation 2**
We are starting to package SearchKit displays as replacements for Smarty/DataTables in the UI. This has worked out great for CiviGrant: now that it's an extension we can easily package Afforms, SavedSearches and other managed entities with it. But other components are not extensions and so have no mechanism for including their own managed entities, afforms, etc. Components are less modular and more monolithic than extensions.
**Motivation 3**
Currently an extension has no way to require a component, e.g. an extension cannot declare a dependency on CiviEvent.
**Motivation 4**
Extensions and Components are similar but not the same, and this is confusing to new users and new developers. In most respects Extensions are better than Components, and it would be great to "some day" have all components simply be extensions.
**Proposal**
Given the experience of converting CiviGrant to an extension was a "harder than expected" undertaking, I think converting all other components to extensions at once is not a realistic goal. It would need to be a slow, iterative process, and I propose this as the first iteration:
1. Create a small stub extension for each component (CiviEvent, CiviContribute, etc).
2. Use hooks to sync between the `civicrm_extension` table and the `civicrm_component` table, so that enabling the "CiviEvent" extension also enables the "CiviEvent" component, and vice-versa.
3. Get rid of the "Manage Components" screen. Admins can enable/disable components via the "Manage Extensions" screen.https://lab.civicrm.org/dev/core/-/issues/3871Write-off feature for pledges2022-10-11T13:07:54ZyashodhaWrite-off feature for pledges**Functional specifications:**
On a pledge, in _Edit Scheduled Payment_, we can delete a pledge payment. The total pledge amount is reduced by the amount of the scheduled payment and the balance due is recalculated.
But in this scenar...**Functional specifications:**
On a pledge, in _Edit Scheduled Payment_, we can delete a pledge payment. The total pledge amount is reduced by the amount of the scheduled payment and the balance due is recalculated.
But in this scenario, the pledge status is left as is.
We can also cancel a pledge. All scheduled payments are canceled but the pledge status is set to canceled and the pledge balance and the total pledge amount are not recalculated. So I propose a new feature for the write-off.
- Add the menu option “Write Off” before Cancel.
- All scheduled payments are canceled like for a pledge cancellation.
- Pledge status is changed to Completed.
- Total pledge amount is reduced by the existing pledge balance amount.
- Pledge balance is set to $0.
- An activity of type “Pledge write-off” is created and recorded on the contact.
- Activity Subject=total pledge amount
- Activity Date and time = date and time of the action
- Activity Status=Completed
- Actions available on the activity should be View and File on case only like for the activity type Contribution.
- The option _Write-Off_ is available only for a pledge that has at least one pledge payment. If no pledge payment has been recorded with a pledge, write-off doesn’t make any sense, so we should have only the options to delete or cancel a pledge.
- if pledge status =Pending or Overdue > Show only Cancel and Delete
- if pledge status = In progress > show only Write-Off and Delete
- if pledge status = Completed or Canceled > show only Deleteyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3868Link contribution view with asssociated entity2023-05-18T23:37:57ZyashodhaLink contribution view with asssociated entityWhen you view a contribution, there's no way to know whether this contribution was done as a part of membership, pledge or an event registration.
I propose provide this additional data. Display this under total amount
e,g
![Screens...When you view a contribution, there's no way to know whether this contribution was done as a part of membership, pledge or an event registration.
I propose provide this additional data. Display this under total amount
e,g
![Screenshot_from_2022-09-23_19-15-29](/uploads/24028770f5b17e20ab40334973061b05/Screenshot_from_2022-09-23_19-15-29.png)
Membership will be a link to membership view page.
(depending on the related entity we display the link)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3740Set default lock level to READ COMMITTED2023-10-20T07:57:25ZJoeMurraySet default lock level to READ COMMITTEDDrupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with ...Drupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with deadlocks, primarily on rebuilding group contact cache when there are hierarchies of smart groups. Should CiviCRM be more explicit about what isolation level we expect in order to get more repeatable results, and should we follow Drupal in its move to READ COMMITTED? I tend to think so.
See responses in MM chat from @demeritcowboy
https://chat.civicrm.org/civicrm/pl/gnmhfdxes7rgb8k7ppoaezo45ahttps://lab.civicrm.org/dev/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/3615<link> URLs are tracked and shouldn't be2022-06-13T09:15:05Zlarsssandergreen<link> URLs are tracked and shouldn't beIf you use <link href=URL> in a mailing template, for example to load a webfont, that URL is converted to a tracked URL. Presumably it shouldn't be as this makes a mess of the clickthrough statistics (every one of these links will be cou...If you use <link href=URL> in a mailing template, for example to load a webfont, that URL is converted to a tracked URL. Presumably it shouldn't be as this makes a mess of the clickthrough statistics (every one of these links will be counted as clicked as long as the user's mail client fetches the resource). In other words, a link being fetched in a not a click and shouldn't be counted as one.
Do we need to track any URLs that aren't inside an <a> tag? It might be easier to limit to <a... rather than trying to exclude <link.... The only valid way to write an <a> is with the tag right after the <, so I think we could just look for <a instead of <.
I can provide a patch if this approach is supported.https://lab.civicrm.org/dev/core/-/issues/3574Password for mail accounts should not be stored in plain text2024-02-14T05:03:29ZscardiniusPassword for mail accounts should not be stored in plain textMySQL field civicrm_mail_settings.password contains password in plain text. Should it? I think not
This issue could by linked with https://lab.civicrm.org/dev/core/issues/236MySQL field civicrm_mail_settings.password contains password in plain text. Should it? I think not
This issue could by linked with https://lab.civicrm.org/dev/core/issues/236https://lab.civicrm.org/dev/core/-/issues/3545Make it possible to make a copy of a draft mailing2022-06-11T14:50:35ZlarsssandergreenMake it possible to make a copy of a draft mailingIt would be quite useful to be able to make a copy of a draft mailing. As it stands currently, if you want to duplicate a draft email (for instance, if you want to send two slightly different mailings), you have to send it first and then...It would be quite useful to be able to make a copy of a draft mailing. As it stands currently, if you want to duplicate a draft email (for instance, if you want to send two slightly different mailings), you have to send it first and then reuse it.
I'm not sure if this would be complicated or simple to implement (essentially the same as re-using a mailing or something more complex). Does anyone have thoughts?5.38.0https://lab.civicrm.org/dev/core/-/issues/3541[Meta] Does CiviCRM have a single defined application HTTP entry point which ...2024-02-11T05:03:23Zxurizaemon[Meta] Does CiviCRM have a single defined application HTTP entry point which routes all requests?Various issues arise when we have multiple entry points to the application (eg scripts in `extern/`, direct call scripts like KCFinder `integration/civicrm.php`, IPN handlers).
These issues stem from duplicated / non-identical approache...Various issues arise when we have multiple entry points to the application (eg scripts in `extern/`, direct call scripts like KCFinder `integration/civicrm.php`, IPN handlers).
These issues stem from duplicated / non-identical approaches to bootstrapping / path discovery / session management.
The end goal here is to eliminate alternate entry points and ensure any callback uses CiviCRM's core routing.
As much as possible auth/bootstrap/url/path resolution should be handled in one place only (each) for maintainability.
## Background issues / examples:
* [CRM-17212](https://issues.civicrm.org/jira/browse/CRM-17212)
* [CRM-13249](https://issues.civicrm.org/jira/browse/CRM-13249)
* [CRM-12246](https://issues.civicrm.org/jira/browse/CRM-12246)
* cloud-native#6
* cloud-native#7
## Targets
* [`extern/authorizeIPN.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/authorizeIPN.php), [`ipn.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/ipn.php), [`pxIPN.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/pxIPN.php) - IPN handlers → use `civicrm/ipn/%` entry point
* [`extern/cxn.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/cxn.php)
* [`extern/open.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/open.php) - endpoint to track mail opens via image URL
* [`extern/rest.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/rest.php) - API endpoint → `civicrm/api/v3`, `civicrm/api/v4` etc
* [`extern/soap.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/soap.php) - SOAP interface, still used by CiviSMTP? → `civicrm/soap`
* [`extern/url.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/url.php) - Mailing redirect → `civicrm/redirect` ?
* [`packages/kcfinder/integration/civicrm.php`](https://github.com/civicrm/civicrm-packages/blob/master/kcfinder/integration/civicrm.php) - KCFinder integration for CiviCRM - IDK
IPN handlers should be tackled as those core payment processors are moved to extensions.https://lab.civicrm.org/dev/core/-/issues/3538Docker2022-06-11T14:45:10ZMichael McAndrewDockerHey there,
I've been doing a bit of work on [CiviCRM on Docker](https://github.com/michaelmcandrew/civicrm-buildkit-docker/). I know that others have been doing the same and I feel like it would be great to start co-ordinating a bit mor...Hey there,
I've been doing a bit of work on [CiviCRM on Docker](https://github.com/michaelmcandrew/civicrm-buildkit-docker/). I know that others have been doing the same and I feel like it would be great to start co-ordinating a bit more.
I am wondering whether cloud native is the right place for it, or if we should create a Docker project.
On the one hand, I feel like there could be a lot of Docker chat and wouldn't want to drown out other chat. On the other, I don't want to proliferate groups unnecessarily.
Any thoughts? I am erring toward a seperate group at the minute.https://lab.civicrm.org/dev/core/-/issues/3534Simplify the settings for filesystem paths2022-06-11T16:35:32ZxurizaemonSimplify the settings for filesystem paths* [Hosting environments like WPEngine don't permit (extra) .php files located in the webroot (apparently)](https://civicrm.stackexchange.com/questions/15942/is-it-possible-in-civicrm-to-change-extension-of-cached-php-files-from-php-to-s)...* [Hosting environments like WPEngine don't permit (extra) .php files located in the webroot (apparently)](https://civicrm.stackexchange.com/questions/15942/is-it-possible-in-civicrm-to-change-extension-of-cached-php-files-from-php-to-s)
* Caching generated content there means potential for info leakage or execution via input variables
* Filesystem caching can be inefficient compared to other caches
* Herb has done work to get Smarty caching via Redis?
* https://www.drupal.org/node/2570335
* https://forum.civicrm.org/index.php?topic=35125.0;nowap
* https://issues.civicrm.org/jira/browse/CRM-17401
* https://github.com/freeform/civicrm-drupal-pantheon/blob/4.6.x/patches/smarty-redis-civi-cache.patch
* would Smarty 2 choke if we just set the path to redis:// ?
* .php extension is [tacked on here](https://github.com/civicrm/civicrm-packages/blob/master/Smarty/Smarty.class.php#L1512), may be other places to change thishttps://lab.civicrm.org/dev/core/-/issues/3530[META] Does CiviCRM make it easy to install without using the UI?2024-02-08T05:03:21Zherbdool[META] Does CiviCRM make it easy to install without using the UI?Currently CiviCRM can be installed via the commandline with drush ~~or cv~~, but it doesn't allow for environmental variables in the command (from what I can tell). I'm not sure if that's the best way to automate a build anyway. To allow...Currently CiviCRM can be installed via the commandline with drush ~~or cv~~, but it doesn't allow for environmental variables in the command (from what I can tell). I'm not sure if that's the best way to automate a build anyway. To allow for builds we may need to be able to point CiviCRM to a file with the env vars and then install fresh. And may need to override the default behaviour of CiviCRM showing errors when it finds a civicrm.settings.php already.
---
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/7
* https://lab.civicrm.org/dev/cloud-native/issues/8https://lab.civicrm.org/dev/core/-/issues/3527Logging improvements2024-02-07T05:03:28ZmfbLogging improvementsI ran into some issues re: CiviCRM logging:
1. Currently, in many cases, CiviCRM does not indicate a severity level when logging a message. Thus many events are logged at info level.
1. When passing log messages thru to Drupal's watchdo...I ran into some issues re: CiviCRM logging:
1. Currently, in many cases, CiviCRM does not indicate a severity level when logging a message. Thus many events are logged at info level.
1. When passing log messages thru to Drupal's watchdog() logger, debug level is typically used, even for a fatal error. There is no attempt made to map the level appropriately.
1. Some of the CRM_Core_Error methods - e.g. CRM_Core_Error::debug_var() - don't have an argument for severity level - but we could/should add one.
1. When providing a severity level to "old school" CRM_Core_Error calls, we also have the option of "upgrading" these to instead be Civi::log() calls.
I would be curious to hear anyone's thoughts, but it seems fairly straightforward to make some big improvements here.https://lab.civicrm.org/dev/core/-/issues/3409Back-office registration of guest participants2023-01-10T15:22:25ZJKingsnorthBack-office registration of guest participants**Motivation:**
Currently it is not possible to add 'additional participants' (guests) to an event booking in the back end. Instead, you need to create a new booking for the guest record, and then there is no way to 'link' them to the le...**Motivation:**
Currently it is not possible to add 'additional participants' (guests) to an event booking in the back end. Instead, you need to create a new booking for the guest record, and then there is no way to 'link' them to the lead booker.
**Solution:**
Allow additional participants (guests) to be added to someone's booking, when managing participants through the back end, eg:
![image](/uploads/00c03cb2e27642db624ec612516927f8/image.png)
**Previous work:**
See https://issues.civicrm.org/jira/browse/CRM-19047 . The PR here (https://github.com/civicrm/civicrm-core/pull/8676) works for adding guests to peoples' bookings in the back end for free events. But we ran into some problems with paid events, because of the way the contribution row is handled.
We are currently working on this and hope to submit a new PR that will work for free and paid events by the end of January.https://lab.civicrm.org/dev/core/-/issues/3402Hide explanatory text about multiple participants unless 2 or more participan...2022-09-30T23:21:23ZlarsssandergreenHide explanatory text about multiple participants unless 2 or more participants selectedOn event registration pages, when multiple participants is enabled, there is a lengthy bit of explanatory text shown:
"Fill in your registration information on this page. If you are registering additional people, you will be able to ente...On event registration pages, when multiple participants is enabled, there is a lengthy bit of explanatory text shown:
"Fill in your registration information on this page. If you are registering additional people, you will be able to enter their registration information after you complete this page and click "Continue"."
It would be better to hide this text until the user selects a number of participants greater than one. I'll submit a patch if this change is supported.https://lab.civicrm.org/dev/core/-/issues/3389Implement tests for Event Registration pages2024-01-11T05:03:25Zmattwiremjw@mjwconsult.co.ukImplement tests for Event Registration pages`CRM/Event/Form/Registration/Register.php` needs to be refactored like `CRM/Contribute/Form/Contribution.php` so that we can implement tests on submit.
`CRM_Event_Form_Registration_Register::postProcess()` needs splitting up to call a n...`CRM/Event/Form/Registration/Register.php` needs to be refactored like `CRM/Contribute/Form/Contribution.php` so that we can implement tests on submit.
`CRM_Event_Form_Registration_Register::postProcess()` needs splitting up to call a new function `CRM_Event_Form_Registration_Register::submit()`.
Then we need to add `CRM_Event_Form_Registration_Register::testSubmit()` and write some tests to call this function.https://lab.civicrm.org/dev/core/-/issues/3358Add option to include guest information in back-office confirmation emails2024-01-07T05:03:23ZJKingsnorthAdd option to include guest information in back-office confirmation emailsProblem: when you send a confirmation email from the back-end after registering a participant, or editing their booking, it only includes the information for the 'current' participant (ie, just the lead booker). It does not include any '...Problem: when you send a confirmation email from the back-end after registering a participant, or editing their booking, it only includes the information for the 'current' participant (ie, just the lead booker). It does not include any 'additional participants' (guests) linked to their registration.
Solution: suggested CiviCRM core patch to add a checkbox to 'include guest information' for confirmation emails for participants that have guests attached to them. This would include the guest information int he email, as though it was from a front-end booking.
ie: IF the booking has additional participants, display a new checkbox:
![image](/uploads/2dbec13b633d9be6e880c2fb255a4b80/image.png)
If the checkbox is ticked, then add in the guest information, in the same way as a 'front-end' registration would add their information.