Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-27T05:03:23Zhttps://lab.civicrm.org/dev/core/-/issues/3791Wizard: Navigation buttons have weird activation2024-03-27T05:03:23ZtottenWizard: Navigation buttons have weird activationOverview
----------------------------------------
A wizard, such as "New A/B Test", allows you proceed through multiple steps sequentially. Every step in a wizard should be completed in order, although it is also valid to return to a pr...Overview
----------------------------------------
A wizard, such as "New A/B Test", allows you proceed through multiple steps sequentially. Every step in a wizard should be completed in order, although it is also valid to return to a prior step and revise it.
The current behavior of the navigation-bar does not correctly implement this.
Reproduction steps
----------------------------------------
* Click on "**Mailings -> New A/B Test**."
* Within "__1. Setup__"
1. Fill in a **Name**
1. Observe: In the navbar, you are now allowed to jump from step 1 to step 2 or 3 or 4. (*Proceeding to the next step is fine, but you should not be allowed to go step 3 or 4 -- that is premature.*)
![Screenshot_from_2022-08-08_22-26-01](/uploads/eb0c0043394dcd12da65947a1dbd0571/Screenshot_from_2022-08-08_22-26-01.png)
1. Click **Next** (or click the `2. Target` link)
* Within "__2. Target__"
1. Observe: In the navbar, you cannot jump to *any* other step. (*Proceeding to step 3 would be premature, but you should be allowed to go back to step 1.*)
![Screenshot_from_2022-08-08_22-27-06](/uploads/2e70548c9d47577ae369e3e506b7bb02/Screenshot_from_2022-08-08_22-27-06.png)
1. Fill in **Recipients**
1. Observe: In the navbar, you are now allowed to jump to any other step. (*Proceeding to step 3 is OK, but you should not be allowed to jump to step 4.*)
Current behaviour
----------------------------------------
You may jump to any step *if the current step is complete*.
Expected behaviour
----------------------------------------
You may jump to any step *if its predecessors have valid complete/data* (ie *if the prerequisites for the selected step are met*).
Comments
----------------------------------------
The behavior of the "Previous" and "Next" buttons is OK. It's just the top navbar that has the quirk.
This gets to the basic difference between a "wizard" and "tab set". A "tab set" is free-form, so you may navigate to any tab at any time. A "wizard" is sequential, and the steps build upon each other. (In fact, steps may be added or removed as you go through.)
This appears to have regressed in 4.7.28 via https://github.com/civicrm/civicrm-core/commit/5919adff1dc7a531d426c211baf65d8c9b538eeb. I suspect that dev+review focused on "New Mailing", which is deceptively simple use-case (*static 2-step wizard*). The "New A/B Test" is a representative use-case (*dynamic, 4/5-step wizard*).https://lab.civicrm.org/dev/core/-/issues/5077civicrm.css loaded on front end when frontend theme set to 'None - Unstyled'2024-03-19T07:32:11ZMichael McAndrewcivicrm.css loaded on front end when frontend theme set to 'None - Unstyled'Wondering if I have found a bug or am just misunderstanding/mistaken or I have missed a decision to change things but I have reproduced this on 5.70 and 5.71. It was not happening in 5.64.4
Steps to reproduce:
1. Clean CiviCRM on WordP...Wondering if I have found a bug or am just misunderstanding/mistaken or I have missed a decision to change things but I have reproduced this on 5.70 and 5.71. It was not happening in 5.64.4
Steps to reproduce:
1. Clean CiviCRM on WordPress install
2. Set front end theme to **automatic**
3. Go to a front end page, e.g. /civicrm/mailing/subscribe
4. Notice that /wp-content/plugins/civicrm/civicrm/css/civicrm.css has been loaded - **good!**
5. Set front end theme **none - unstyled**
6. Go to a front end page, e.g. /civicrm/mailing/subscribe
7. Notice that /wp-content/plugins/civicrm/civicrm/css/civicrm.css has been loaded **- bad!**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.https://lab.civicrm.org/dev/core/-/issues/4936Standalone: drop downs not displaying fields correctly2024-01-27T21:54:10ZAndy ClarkStandalone: drop downs not displaying fields correctlyThere is a lack of room in drop downs to display field names, so that in some cases it's hard to know what the field name is. For example, selecting the phone type for a contact shows only the first letter of the phone type - only 'M' f...There is a lack of room in drop downs to display field names, so that in some cases it's hard to know what the field name is. For example, selecting the phone type for a contact shows only the first letter of the phone type - only 'M' for mobile. Or 'Website Type' which is undecipherable. Tested on both Firefox and Chrome browsers. This is using the 5.69.2 Standalone release.https://lab.civicrm.org/dev/core/-/issues/1513Built-in communication-tools should consistently handle communication-prefere...2024-01-17T05:03:28ZtottenBuilt-in communication-tools should consistently handle communication-preferencesOverview
----------------------------------------
In the discussion and review of #1378, several quirks and inconsistencies were flagged. These quirks/inconsistencies can produce confusion. We'll close #1378 because it addresses a parti...Overview
----------------------------------------
In the discussion and review of #1378, several quirks and inconsistencies were flagged. These quirks/inconsistencies can produce confusion. We'll close #1378 because it addresses a particular quirk, but we should still have a record to prompt follow-up on other quirks.
Concepts:
* A *communication preference* is a field stored on a contact record which indicates how that person prefers to communicate. Example: They prefer email over text; they do not want you to initiate phone calls (but if they call you on the phone, then you should still take the call!).
* One's respect for communication preferences depends on *the subject-matter* and *the data*:
* *The Subject Matter* -- a confirmation or receipt; an end-of-year tax report; a notice about changes in an event; an inquiry about event attendee's arrival/accommodation/diet; an inquiry/support-thread initiated by the constituent; an appeal to renew an existing membership; an appeal to fill out a general survey; an appeal to fill out a survey about something which *you just did*; notifications about progress in case-work; education about the org's work; ad nauseum.
* *The Data* -- a database which is only used for donations; a database which is used for a mix of donations, events, case-work, support; etc. (*The meaning of your data depends on where it comes from, what forms you presented to people, the context of those forms, etc.*)
* Given the same *subject-matter* and the same *data*, a user may still choose different *tools* -- one-on-one email; search+checkbox+email; CiviMail blast to a smart-group; CiviRules trigger; scheduled reminders; sui-generis application logic; etal.
For example... depending on how the specific membership program works, it's entirely reasonable to send content about renewals through a scheduled-reminder... or a CiviMail blast... or a one-on-one message. For a last-minute notification about changes in an event, I can totally see people using the individual mailer, the adhoc mail-blast, or a normal mail-blast.
Current behavior
----------------------------------------
There are several built-in tools. They are often hard-coded to respect a specific communication-preference (e.g. quietly skipping records due to communication-preferences).
This is confusing because:
* Different tools have different defaults, so they behave differently.
* Tools often do not provide a clear indication that records are being skipped.
* The default comm-prefs may be misapplied due to an incorrect expectation about the subject matter or data. (Ex: CiviMail was originally written with an expectation that it's used for newsletters. If you use it to send a last-minute logistical update for an event, then it will quietly use the wrong comm-pref.)
Proposed behavior
----------------------------------------
* Any built-in communication tool should have built-in support for comm-prefs.
* "Built-in support for comm-prefs" means:
* It defaults to behavior which respects the comm-prefs.
* It warns the backend-user/admin if they're requesting an action that would break a comm-pref.
* It warns the backend-user/admin if some action is being skipped due to a comm-pref.
* It allows the backend-user/admin to decide how/whether/which comm-pref is appropriate to the task at hand.
Comments
----------------------------------------
This issue is not ripe for coding. To address it, I would expect that one would next need to:
* Audit the existing comm-tools to note how they do (or don't) handle comm-prefs
* Design some mockup for how to consistently present comm-prefs in the existing toolshttps://lab.civicrm.org/dev/core/-/issues/3363CiviEvent Cart seems broken completely. Any chance of fixing it?2024-01-07T05:03:24ZtapashCiviEvent Cart seems broken completely. Any chance of fixing it?CiviEvent Cart seems broken completely on 5.x . Any chance of fixing it please? thanksCiviEvent Cart seems broken completely on 5.x . Any chance of fixing it please? thankshttps://lab.civicrm.org/dev/core/-/issues/4884"CiviCRM News" on Backdrop has awkward accordions on default themes2024-01-04T22:21:56Ztotten"CiviCRM News" on Backdrop has awkward accordions on default themesOn Backdrop (eg https://bmaster.demo.civicrm.org/civicrm/ ; user: `demo`; pass: `demo`) with default themes, the "CiviCRM News" dashlet is looking weird:
![Screenshot_2024-01-03_at_9.08.21_PM](/uploads/8d22ff7703e5f9eaf856a9e413be66dd/...On Backdrop (eg https://bmaster.demo.civicrm.org/civicrm/ ; user: `demo`; pass: `demo`) with default themes, the "CiviCRM News" dashlet is looking weird:
![Screenshot_2024-01-03_at_9.08.21_PM](/uploads/8d22ff7703e5f9eaf856a9e413be66dd/Screenshot_2024-01-03_at_9.08.21_PM.png)
Theories:
* At first blush, it feels like it would be a regression related to the accordion updates circa 5.69.x (eg https://lab.civicrm.org/dev/user-interface/-/issues/60). However, there's a similar problem in 5.68. This suggests that it's not a simple regression:
![Screenshot_2024-01-03_at_10.21.14_PM](/uploads/ebe6ad88b770ba5337a965cc887d194b/Screenshot_2024-01-03_at_10.21.14_PM.png)
(Note: Slightly different visual appearance with double arrows)
* Could it be that there's always been a bug like this.
* Could it be that the accordion cleanup led to changes in the news feed? In which case, maybe the question is about infra: How to make the feed(s) work with different versions of Civi?
* Interestingly, I went to an old/local copy of `bcmaster`, updated to 5.68+5.69+master, and... it seemed to display fine. But on clean builds of 5.68 and master, it didn't. (This suggests that it might still be some kind of regression.)
* (*It could be that I have a cache of an older feed? This might support the idea of an issue in how the feed works with different client environments?*)5.69.0https://lab.civicrm.org/dev/core/-/issues/3342Memberships of disabled membership types do not appear on the membership tab ...2024-01-04T05:03:20ZalicefruminMemberships of disabled membership types do not appear on the membership tab BUT do throw duplicate Membership WarningIf a contact has a Membership of the Membership Type "Student"
and the membership type "Student" gets disabled
On the contacts membership tab you will see no memberships but when you try and create a new membership for this contact a "D...If a contact has a Membership of the Membership Type "Student"
and the membership type "Student" gets disabled
On the contacts membership tab you will see no memberships but when you try and create a new membership for this contact a "Duplicate Membership" warning will appear.
To some extent this makes sense because if one were to re enable the disabled student membership type and a user had created a new membership that could be problematic. However from a UI perspective it seems like it would be useful for disabled memberships to be listed.https://lab.civicrm.org/dev/core/-/issues/3303Front End Event Registration Form - Drop Down Select List Labels not accessible2023-12-28T05:03:24ZndavisFront End Event Registration Form - Drop Down Select List Labels not accessibleOn front end registration forms, when using screen reader software (JAWS etc) When tabbing from a text field into a drop down select list field, the screen reader reads the selected data, not the field label, the way it does with other f...On front end registration forms, when using screen reader software (JAWS etc) When tabbing from a text field into a drop down select list field, the screen reader reads the selected data, not the field label, the way it does with other field types. This is broken. It should read the field label for drop down lists like it does with other field types. The user knows what is selected when they click it and it's read.
To fix this issue, change the aria-labelledby attribute of the s2id_autogen1 id'd input html element from select2-chosen-1 to s2id_autogen1
Code Example for the credit card form at https://demo.circle-interactive.co.uk/civicrm/event/register?id=1&reset=1:
`<label for="s2id_autogen1" class="select2-offscreen">Country</label>
<input class="select2-focusser select2-offscreen" type="text" aria-haspopup="true" role="button" aria-labelledby="select2-chosen-1" id="s2id_autogen1">`
**aria-labelledby="select2-chosen-1"**
needs to be changed to
`<label for="s2id_autogen1" class="select2-offscreen">Country</label>
<input class="select2-focusser select2-offscreen" type="text" aria-haspopup="true" role="button" aria-labelledby="s2id_autogen1" id="s2id_autogen1">`
**aria-labelledby="s2id_autogen1"**
This change can be extrapolated to state list drop downs (indeed any drop-downs)
For blind users this causes confusion because they don't know what field they're on if they're in a state/province named after the country and it works differently than the rest of the field types.
Changing this in the html source using developer tools of firefox or chrome fixes issue until page is refreshed.
I tried to figure out where this is happening but the javascript spaghetti is very confusing. If anyone can point me to the right file I'll patch it.
thx,
Neil P Davis
Developer
National Federation of the Blindhttps://lab.civicrm.org/dev/core/-/issues/3210Report Listing improved UX2023-12-23T05:03:22ZJonGoldReport Listing improved UXWhen you go to **Reports menu » X Reports**, where `X` is anything, you get the report listing page (`CRM_Report_Page_InstanceList`). This page hard-codes the order the reports appear in.
* First by component
* Second by the weight o...When you go to **Reports menu » X Reports**, where `X` is anything, you get the report listing page (`CRM_Report_Page_InstanceList`). This page hard-codes the order the reports appear in.
* First by component
* Second by the weight of the report template ID in the `report_template` option value list
* Third alphabetized by title.
The second sort criterium is the problematic one. I propose we sort by component, then alphabetically.
I assume the original thinking was, "Let's keep all the Contribution Summary reports together, all the Contribution Detail reports", etc. However, I think this isn't an ideal UX:
* Users don't know (or care about) the order of report templates in the option value list.
* Reports can be sorted any number of ways: By user, department, workflow - but those are unlikely to map to report templates.
* This is all especially true in an era where there's many report extensions that provide overlapping reports with core (Extended Reports, Reports Plus, Pivot Reports). I think it makes more sense not to sort by report type.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3156Proposal: include translations in installation tar/zip2023-12-10T05:03:30ZalainbProposal: include translations in installation tar/zipOverview
----------------------------------------
The default language of CiviCRM is en_US. Other languages are not included in the standard installation package.
Looking at the countries and languages on stats.civicrm.org, we can see t...Overview
----------------------------------------
The default language of CiviCRM is en_US. Other languages are not included in the standard installation package.
Looking at the countries and languages on stats.civicrm.org, we can see that a big part of the community is using another language than en_US.
It would be more inclusive and respectful to include all languages in the standard installation package.
We should practice what we preach in our [code of conduct](https://civicrm.org/code-of-conduct): "_Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society._"
Current behaviour
----------------------------------------
If you want to install CiviCRM in another language than en_US, you need to manually download the l10n file, and unpack it in the appropriate folder. This is an extra (technical) step for non en_US speakers.
Proposed behaviour
----------------------------------------
Include all languages in the standard installation package, or dynamically load the requested language during installation and upgrades.https://lab.civicrm.org/dev/core/-/issues/4466Roles - Define default taxonomy (for standalone deployments)2023-12-04T21:13:40ZtottenRoles - Define default taxonomy (for standalone deployments)Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* ...Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* __Light-touch with open taxonomy.__ This is what D7 does -- you just get 2-3 roles (anonymous, authenticated, admin). Then the site-builder can fill-in more roles to taste. When you upgrade, you may need to re-tune the roles.
* __Strong defaults with hackable taxonomy__ This is what WP does -- you get several roles out-of-the-box. Site-builders are not particularly encouraged to refine them, but it is possible (esp using APIs/add-ons). When you upgrade, it can (*I assume*) add or update roles.
* __Library of example roles__: This idea comes from looking at Google Cloud -- they have an extensive library of roles. Some of the roles are similar/overlapping (e.g. there are older and newer flavors of "File Admin"/"Storage Admin"). The upshot is that you get a presumption of continuity while still allowing the taxonomy to evolve. The downside is that the list is a bit overwhelming. But treating these as templates might mitigate that (*library of possible roles is long -- but the local site only enables a handful*).
There are some related questions - if you have strong defaults or a library of examples, then how do you deal with extensions (*i.e. the list of available perms may fluctuate depending on the extensions*).https://lab.civicrm.org/dev/core/-/issues/1416Export to PDF with useful filename2023-11-22T05:03:22ZCoreyBurgerExport to PDF with useful filenameIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titleIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titlehttps://lab.civicrm.org/dev/core/-/issues/3053Usability issue reported by user: All Reports page overrides report results s...2023-11-20T05:03:18ZDevAppUsability issue reported by user: All Reports page overrides report results settingWhen clicking on a report name on the All Reports page located at /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Freport%2Flist&reset=1
The resulting link loads the report with output=criteria on the end. This stops the default parameters ...When clicking on a report name on the All Reports page located at /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Freport%2Flist&reset=1
The resulting link loads the report with output=criteria on the end. This stops the default parameters of the results from loading, which was set to view results. The user expected results to appear when loading the report per the saved report setting. The result to the user is the report is broken.
The output=criteria is overriding the saved report behaviour. Whilst there is a view results button the right hand side of the All Reports page, it does create some confusion to the user with consistency. Perhaps if the setting is already set on the report to view results, the output=criteria could be removed from that link to create consistency... Or the GUI clearer about why the report wasn't run.
This isn't a bug, but more a usability issue.https://lab.civicrm.org/dev/core/-/issues/2548Improvements to the extensions UI and update notifications.2023-11-12T05:03:27ZhomotechsualImprovements to the extensions UI and update notifications.Overview
----------------------------------------
_Following a post on MatterMost from @DaveD we discussed how valuable the extension he wrote about and posted here: https://civicrm.org/node/11234 is and I think it's worth working into c...Overview
----------------------------------------
_Following a post on MatterMost from @DaveD we discussed how valuable the extension he wrote about and posted here: https://civicrm.org/node/11234 is and I think it's worth working into core. @KarinG then raised a related and equally valuable point that extensions managed outside of CiviCRM e.g. with Git or just existing on the filesystem are marked Green like up-to-date extensions when actually we lack enough data to determine if these extensions are, in fact, up-to-date._
_Therefore I would like to fold Dave's extension's functionality into CiviCRM core and make changes to the extensions UI to remove the green highlight and possibly at a notice to extensions that don't exist on CiviCRM.org to indicate that we cannot determine whether these are up-to-date and extension authors should check manually._
In the discussion I proposed the following:
**Core:**
* Checks for extension updates if extension is on `c.o/extensions` but only updates those approved for in-app (at the moment at least!)
* Displays a message on extensions it doesn't manage (that don't exist on `c.o`) to the effect of "We can't check for updates for this extension." - similar to how Drupal displays a notice on git-managed or custom extensions.
**Contrib:**
* Could provide for update checking for git-managed and possibly custom extensions.
I have time available to work on this last week of April.homotechsualhomotechsualhttps://lab.civicrm.org/dev/core/-/issues/3202In membership detail report the join date field has a different output date f...2023-11-10T00:08:12ZDaveDIn membership detail report the join date field has a different output date format than the other date fieldsCan reproduce on dmaster.demo.
On the membership details report in the columns tab select join date as a field. When you run the report the join date column has a different date format than the start/end date. It seems to always be yyyy...Can reproduce on dmaster.demo.
On the membership details report in the columns tab select join date as a field. When you run the report the join date column has a different date format than the start/end date. It seems to always be yyyy-mm-dd.
Doesn't seem to be a recent issue.5.69.0https://lab.civicrm.org/dev/core/-/issues/2883Proposal to change the label "Nickname" on Organisation to "Trading Name" (or...2023-10-29T05:03:27Zjustinfreeman (Agileware)Proposal to change the label "Nickname" on Organisation to "Trading Name" (or something else) and "Nickname" on Individual to "Alias" (or something else)Proposal to change the label "Nickname" on Organisation to "Trading Name" (or something else) and "Nickname" on Individual to "Alias" (or something else).
With this field having the same label on both the Individual and Organisation has...Proposal to change the label "Nickname" on Organisation to "Trading Name" (or something else) and "Nickname" on Individual to "Alias" (or something else).
With this field having the same label on both the Individual and Organisation has been **problematic because end users cannot target it with a Word Replacement, same word different contexts (Individual and Organisation).**
I think this field is useful, but the labelling reduces the usefulness so it would be good to adjust the label to make it clearer to end users as to what should be entered here.
Looking for thoughts from the community on this one.
Agileware Ref: CIVICRM-1853https://lab.civicrm.org/dev/core/-/issues/2908Contributions on recurring view are not sorted based on received date descending2023-10-20T05:03:17ZyashodhaContributions on recurring view are not sorted based on received date descendingContributions on recurring view are not sorted based on received date descending but alphabetically
![recur](/uploads/529cb945bcdb316e1292a314a728dcf3/recur.png)
Confirmed on dmasterContributions on recurring view are not sorted based on received date descending but alphabetically
![recur](/uploads/529cb945bcdb316e1292a314a728dcf3/recur.png)
Confirmed on dmasteryashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2882Proposal to add new field for Organisation contacts to record the Tax Identif...2023-10-04T05:03:19Zjustinfreeman (Agileware)Proposal to add new field for Organisation contacts to record the Tax Identification Number: ABN (AU), VATIN (EU), TIN...Proposal to add new field for Organisation contacts to record the Tax Identification Number: ABN (AU), VATIN (EU), TIN/EIN/FEIN/IRS EIN/EIN TAX ID (US) and there's probably more variations. This could also be useful on Individual contact...Proposal to add new field for Organisation contacts to record the Tax Identification Number: ABN (AU), VATIN (EU), TIN/EIN/FEIN/IRS EIN/EIN TAX ID (US) and there's probably more variations. This could also be useful on Individual contacts as well.
This information is also very relevant for the CiviCRM Domain, Organisation Contact. The CiviCRM Contribution message templates could do with adding this information to the default template.
Raising as a proposal here to gather thoughts and find out if people are recording this information elsewhere, renaming the SIC Code field for example. Not looking for responses like: "just use a custom field!" and "change the default templates" - because that's what we already do.
Agileware Ref: CIVICRM-1852