CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2018-06-04T00:31:14Zhttps://lab.civicrm.org/dev/core/-/issues/40Show Contributions Associated to Recurring Contribution on Detailed View2018-06-04T00:31:14ZCamilo RodríguezShow Contributions Associated to Recurring Contribution on Detailed View## Overview
Currently, when viewing a recurring contribution from contact's detailed view (on Contributions tab), the only information shown is its basic information. It would be great if we could also see the contributions related to th...## Overview
Currently, when viewing a recurring contribution from contact's detailed view (on Contributions tab), the only information shown is its basic information. It would be great if we could also see the contributions related to that contribution on that same view.
## How it Works Currently
1. Go to a contact with that has contributions and recurring contributions.
2. Click on contributions tab.
3. Click the **view** action on a recurring contribution.
4. Only basic information for the recurring contribution is shown. Related contributions are not shown.
## How it Should Work
1. Go to a contact with that has contributions and recurring contributions.
2. Click on contributions tab.
3. Click the **view** action on a recurring contribution.
4. Basic information for the recurring contribution is shown and a table with related contributions is also shown.
## Acceptance Criteria
* On the "View Recurring Contribution" modal, a "Contribution" accordion should be added to the bottom.
* Accordion should show a table listing all contributions that are linked to this recurring contribution.
* The table should have the look and behaviour of the current contribution table in contact record's contribution tab.5.3.0https://lab.civicrm.org/dev/core/-/issues/38Recurring Contribution Information on Membership Modal2018-05-29T18:22:20ZCamilo RodríguezRecurring Contribution Information on Membership Modal## Overview
Currently, when viewing a membership from contact's detailed view (on memberships tab), it is hard to tell if a membership has any recurring contributions associated to it, even though you can see all payments done for the me...## Overview
Currently, when viewing a membership from contact's detailed view (on memberships tab), it is hard to tell if a membership has any recurring contributions associated to it, even though you can see all payments done for the membership. It would be good if you could see both payments and recurring contributions associated to the membership, similar to how both are shown on Contact's contribution tab.
## How it Works Currently
1. Go to a contact with that has memberships, contributions and recurring contributions.
2. Click on memberships tab.
3. Click the **view** action on a membership.
4. Membership details are shown, including payments. Recurring contributions are not shown.
## How it Should Work
1. Go to a contact with that has memberships, contributions and recurring contributions.
2. Click on memberships tab.
3. Click the **view** action on a membership.
4. Membership details are shown, including payments. Recurring contributions are also shown, just after the table with membership contributions.
## Accepatance Criteria
* Relabel the "Related Contributions" accordion to "Related Contributions and Recurring Contributions".
* A contributions section is shown on the accordion showing a table of all contributions that are linked to the membership.
* A recurring contribution section showing a table of all recurring contributions that are linked to the membership.
* The recurring contributions section should reuse the recurring contribution table structure in Contact's contribution tab.
* Actions for recurring contributions work as in contributions Tab.5.3.0https://lab.civicrm.org/dev/core/-/issues/35avoid template variable leakage when processing more than one recurring contr...2023-04-28T01:39:33Zjamieavoid template variable leakage when processing more than one recurring contribution in a sessionThis bug happens if you have more than one iATS recurring contribution and an earlier contribution is assigned to a soft credit, but one or more later contributions are not assigned to a soft credit.
The later contributions have the sof...This bug happens if you have more than one iATS recurring contribution and an earlier contribution is assigned to a soft credit, but one or more later contributions are not assigned to a soft credit.
The later contributions have the soft credit information inserted into their receipt because the email message template variables are not properly cleared.
iATS processes multiple recurring contributions in a single session via a cron job, so may be uniquely triggering this error (although the bug is with CiviCRM Core).5.3.0https://lab.civicrm.org/dev/core/-/issues/34Split edit/view access on permissioned relationships2023-04-28T01:39:33Zaydunsaidan.saunders@squiffle.ukSplit edit/view access on permissioned relationshipsCurrently, relationships can be 'permissioned' such that one contact in the relationship can access the other. This access is both view and edit. It is not possible to provide 'view-only' access via a relationship.
The proposed approa...Currently, relationships can be 'permissioned' such that one contact in the relationship can access the other. This access is both view and edit. It is not possible to provide 'view-only' access via a relationship.
The proposed approach is to create an 'edit related contacts' permission that works in conjunction with the existing permissioning:
- for users with the 'edit related contacts' permission, behaviour is unchanged
- for users without the 'edit related contacts' permission, contacts that they have access to via permissioned relationships will be viewable (as now), but not editable (change).5.5.0aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/32Add option to disable cancel button on a profile form2023-04-28T01:39:33ZjitendraAdd option to disable cancel button on a profile formWhile setting up "subscribe" and "contact us" forms for a site, the default behaviour for a wordpress profile form of type "create" embedded via a shortcode is to show a cancel button.
This isn't really necessary for a single page form...While setting up "subscribe" and "contact us" forms for a site, the default behaviour for a wordpress profile form of type "create" embedded via a shortcode is to show a cancel button.
This isn't really necessary for a single page form with no existing data in it - but there doesn't appear to be a way to disable it.5.4.0https://lab.civicrm.org/dev/core/-/issues/27Move check for presence of the phone strip function to a Check (currently don...2023-04-28T01:39:33ZeileenMove check for presence of the phone strip function to a Check (currently done whenever a phone number is edited)5.40.0https://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-25T20:55:29ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Ok, but it smells bad to have columns belonging to one component in another component's table :nose: (fixme for another day) |
| `<localize_context>` | ✅ keep | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | Historically this was inferred by `<type>` but a few fields explicitly declare `<crmType>` |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename/reorganize | `attributes` | `type` gets moved out (see `<html><type>` below), while `length` gets moved in as `maxlength` |
| `<html><type>` | ⚠️ move/rename | `input_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/5028Add CKEditor/WYSIWYG to the Event Confirmation Email Text Field2024-02-28T12:47:28ZpbarmakAdd CKEditor/WYSIWYG to the Event Confirmation Email Text FieldPer a discussion with Eileen, it would be great to finally get the Confirmation Email Text field of Event Online Registrations to use CKEditor. That will allow admins to create much nicer confirmation emails (with embedded graphics and b...Per a discussion with Eileen, it would be great to finally get the Confirmation Email Text field of Event Online Registrations to use CKEditor. That will allow admins to create much nicer confirmation emails (with embedded graphics and branding) without the need to learn HTML. Given the Registration Screen Introductory Text and Thank-you Screen text both have this option, it seems like a good idea to also have it for the confirmation email.https://lab.civicrm.org/dev/core/-/issues/5020Provide support for the Peppol standard to send invoices from CiviCRM to othe...2024-03-18T15:29:58Zjustinfreeman (Agileware)Provide support for the Peppol standard to send invoices from CiviCRM to other organisationsThis is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol stand...This is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol standard to send invoices from CiviCRM to other organisations. See https://peppol.org/ and participating organisations will be listed here, https://directory.peppol.eu/publichttps://lab.civicrm.org/dev/core/-/issues/5015'Clean-up Temporary Data and Files' doesn't empty the tplCache by default2024-02-23T15:18:23ZAndrew West'Clean-up Temporary Data and Files' doesn't empty the tplCache by defaultThe 'Clean-up temporary data and files' scheduled job [doesn't clean the tpl directory by default](https://github.com/civicrm/civicrm-core/blob/06540d39dc2cedcadb19be5c351ef831a9133534/api/v3/Job.php#L631). Should it? We see this balloon...The 'Clean-up temporary data and files' scheduled job [doesn't clean the tpl directory by default](https://github.com/civicrm/civicrm-core/blob/06540d39dc2cedcadb19be5c351ef831a9133534/api/v3/Job.php#L631). Should it? We see this ballooning to tens of gigabytes when sending large mailings.
Workaround is to add the parameter, but it seems like this might catch some people out.
![image](/uploads/85b4275fb08070a8995fe094e32d466e/image.png)https://lab.civicrm.org/dev/core/-/issues/5000SearchKit: Allow formatting of the totals in the footer2024-02-14T10:06:39Zsimon.hermannSearchKit: Allow formatting of the totals in the footerSearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either ...SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either an option to choose a formatting (decimal separators, thousand separators, currencies if applicable etc) or if the total would reflect the formatting of the column it sums.https://lab.civicrm.org/dev/core/-/issues/4982Form builder - Extension provided entity settings2024-02-14T09:53:44ZseamusleeForm builder - Extension provided entity settingsJMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter ...JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter angular hook https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L76 however this means that even on non petition related form builder forms they will show up.
This is about seeing if there is a better way to achieve this and or see if we can get them put onto the specific settings page for say GeotargetedPetition Entity.
@JoeMurray @Edselopez @colemanwhttps://lab.civicrm.org/dev/core/-/issues/4979Should `die()` be called when a DB Query fails?2024-02-14T09:49:16ZhaystackShould `die()` be called when a DB Query fails?Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#...Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#L327) `die()` and all script execution stop *ahem* dead. Is this intentional?
Reproduction steps
----------------------------------------
1. Install the "Deduper" Extension (v1.7) via the API (sorry @eileen :dove:)
1. See the unrecoverable error "**Cannot execute INSERT INTO civicrm_contact_name_pair_family (id, name_a, name_b, is_most_common_form, is_active) VALUES (65, 'Takahashi', '髙𣘺', 0, 1)**".
Current behaviour
----------------------------------------
There's no way to trap this and continue with a script that installs Extensions via the API.
Edit: apparently there [is a way](https://stackoverflow.com/a/16925225) but this seems a less than sensible way to go about trapping the error.
Expected behaviour
----------------------------------------
A script that installs Extensions via the API should be able to trap the error as an `Exception` with `try/catch` and act accordingly.https://lab.civicrm.org/dev/core/-/issues/4955Upgrade to Smarty52024-02-01T10:45:19ZeileenUpgrade to Smarty5Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some mino...Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some minor challenges.
https://smarty-php.github.io/smarty/5.x/upgrading/
1) assign_by_ref needs to be replaced with assign wherever it appears (yay I've been wanting to get rid of those)
2) some php-language modifiers will stop working without intervention (not sure how affected we are but if some are common it is easy to 'make them work')
3) before we can see / address the above there is a problem with our Smarty compatibility class. Our Smarty class has functions like `getTemplateVars()` to allow sites still on Smarty2 to call the v3 functions. That particular function has a different signature in Smarty5 so overriding it causes fatals
Proposal
1) Check Smarty5 into packages like Smarty4 - see https://github.com/civicrm/civicrm-packages/pull/380
2) the path fix in Smarty4 will allow easy switch to Smarty5 for developers
3) Move `getTemplateVars()` & any other functions in the same boat from being on our Smarty compatibility class to being 'hacked onto' the Smarty 2 code in our packages folder.
4) replace assign-by-ref with assign
- That should be enough to get us to the point where we can get dev sites to load and from there we can figure out if we have to scale a mountain or a molehill to move to Smarty5 instead of 3 or 4 when we do our force changehttps://lab.civicrm.org/dev/core/-/issues/4947Proposal: Store Contribution Page ID in the `civicrm_contribution_recur` table2024-02-01T10:23:33ZjaapjansmaProposal: Store Contribution Page ID in the `civicrm_contribution_recur` tableOverview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contrib...Overview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contribution.
Example use-case
----------------------------------------
1. CiviRules can be used when a new Contribution Recur is added and a condition can then be used which Contribution Page this came from.
Current behaviour
----------------------------------------
Currently for the 'normal' contributions the contribution page ID is stored in the `civicrm_contribution` table.
Proposed behaviour
----------------------------------------
1. Add a column to the `civicrm_contribution_recur` table called `contribution_page_id`
2. When a contribution recur is added through a Contribution Page then store the contribution page id into this column
3. Optional we can show the data from this field in the user interface when a user views a contribution recur
Workaround
----------------------------------------
There is a workaround with an extension: https://lab.civicrm.org/extensions/storecontributionpageidoncontribrecurjaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/4940Proposal to Change the Invoice date in the default Invoice message template t...2024-02-08T10:45:03ZeileenProposal to Change the Invoice date in the default Invoice message template to contribution.receive_dateThis spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from ...This spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from SearchKit etc) we should clarify which value is used for the invoice_date in the default message template that we ship from \`{$invoice_date}\`
```html
{domain.now|crmDate:"Full"}
or
{contribution.receive_date|crmDate:"Full"}
```
If we change the default it will affect new installs and un-customised templates. I'm not proposing any push upgrade on the customised templates at this stage so for most invoice-using sites this will be no change at this point. However, I am going to try to 'complete' the variable to token changes in this template so that anyone who is updating their customised template or installing a new site is using the tokens (& hence will be able to benefit from message previewability via MessageAdmin now & sending & rendering from outside QF if they install a relevant extension /when we add to core).
Potentially if we want to make it clear to people that they can change it we can use one of
```html
{domain.now|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the contribution date instead {contribution.receive_date|crmDate:"Full"} *}
OR
{contribution.receive_date|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the current date instead with {domain.now|crmDate:"Full"} *}
```
Note that the assumption in this gitlab is that any change would be opt in for existing sites (since basically everyone who uses invoices puts a logo in there). There is a proposal at https://github.com/civicrm/civicrm-core/pull/28630 that would force a change on everyone. I'm not convinced we should do a force update because it is pretty clear from the code & code history that the use of now was a deliberate attempt to meet a use case. However I have added an option to the emjoi poll below to allow people to vote for a forced update - basically a string_replace on upgrade.
EMOJI POLL Options
1) :boom: Change to {domain.now|crmDate:"Full"}
2) :man_dancing_tone2: Change to {contribution.receive_date|crmDate:"Full"}
3) :avocado: Change to 1 with additional in-code comments per above
4) :bellhop: Change to 2 with additional in code comments per above
5) :pick: Do 2 with a forced upgrade to replace {$invoice_date} with the above with {contribution.receive_date|crmDate:"Full"}https://lab.civicrm.org/dev/core/-/issues/4923Possible performance improvement: When a custom field is disabled, automatica...2024-02-08T14:11:58ZDaveDPossible performance improvement: When a custom field is disabled, automatically uncheck the searchable box and remove the db indexSuppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless...Suppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless because they don't appear anywhere anyway.
If the table is large, those indexes potentially cause trouble with no benefit.
If you go to re-enable, it's true it won't automatically re-check the searchable box and recreate the index, but there's no real harm, you just go back in and check the box.
An alternative to automatically doing this would be a status check: "The following fields are disabled but marked searchable. Consider making them unsearchable to improve performance on large databases."https://lab.civicrm.org/dev/core/-/issues/4915Sending an invoice per email goes to primary address, not to billing2024-02-09T23:08:39ZMariaVSending an invoice per email goes to primary address, not to billingI have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invo...I have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invoice to the primary address.
What do you think about a setting 'send invoice email to Billing if it exists, otherwise send it to Primary'?
The setting could be optional so that nothing changes for users who want to keep it as it is.
Or is there any knowing extension already that I could not find?
Thanks in advance!https://lab.civicrm.org/dev/core/-/issues/4908Integrate Angular calendar for better usability2024-01-15T11:36:56ZshaneonabikeIntegrate Angular calendar for better usabilityI don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-...I don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-ranges-and-range-presets) (maybe there is an alternative)
Since we are already starting to use a lot of Angular I thought it could be something to consider. There is even a date range option, which could be interesting for other areas.
You can spin a demo on this stackblitz https://stackblitz.com/edit/angular-material-calendar-with-date-ranges-and-presets?file=package.json
What I like about it:
* When choosing a different year it automatically prompts to choose the month which is fairly logical and usable
* There is the possibility to set ranges (future integration with Events?)
* There is the option to have quick options like Last 30 days, Last 12 months, etc.
![Angular Material Calendar with Date Range and Range Presets](https://laros.io/images/angular-material-calendar-date-range.png)
Anyway it was just something I wanted to raise but it's not a high priority but could be a great enhancement.https://lab.civicrm.org/dev/core/-/issues/4902Unnecessary Event Breadcrumb When Editing Event2024-02-01T10:45:52ZthemakUnnecessary Event Breadcrumb When Editing EventWhen editing an event - the breadcrumbs that display are:
CiviCRM > CiviEvent Dashboard > Manage Events > Manage Events
The first 3 make sense, but the last one actually links to the edit event page that you are editing. While I have se...When editing an event - the breadcrumbs that display are:
CiviCRM > CiviEvent Dashboard > Manage Events > Manage Events
The first 3 make sense, but the last one actually links to the edit event page that you are editing. While I have seen breadcrumbs include the current page you are on, usually they are not linked and sometimes greyed out. To stay consistent with other parts of civi, I would remove the last breadcrumb. If we decide to keep for some reason - at very least it should say Configure Event - not Manage Event.
5.69.1 - also replicated in 5.71.alpha1
![Screenshot_2024-01-10_at_12.52.30_PM](/uploads/d6048cb7a5167aab82e3dca9c2aba45d/Screenshot_2024-01-10_at_12.52.30_PM.png)