CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-08-20T02:32:58Zhttps://lab.civicrm.org/dev/core/-/issues/2611Change default_value column for custom fields from varchar to text2023-08-20T02:32:58ZlarsssandergreenChange default_value column for custom fields from varchar to textA custom field can be of many types, including note. For a custom field that is a note, you may want to use a default value that is longer than 255 characters, but currently the default value is stored as a varchar(255). It would make se...A custom field can be of many types, including note. For a custom field that is a note, you may want to use a default value that is longer than 255 characters, but currently the default value is stored as a varchar(255). It would make sense to change this column to text, so that longer values can be entered.
In the custom fields UI, this field would be changed to a textarea when note is selected.
For us, the use case would be storing the content of a short waiver, so that the exact value of the waiver at the time of signing can be stored on the participant for an event, but I can imagine there may be other use cases.
Will submit PR if supported.https://lab.civicrm.org/dev/core/-/issues/2635Download latest version of an extension without installing2023-08-19T05:03:24Zmagnolia61Download latest version of an extension without installingOverview
----------------------------------------
It would be good to be able to download the latest version of an extension without installing it for security reasons.
Current behaviour
----------------------------------------
1. an ex...Overview
----------------------------------------
It would be good to be able to download the latest version of an extension without installing it for security reasons.
Current behaviour
----------------------------------------
1. an extension that was previously installed but since disabled or uninstalled remains present in the extension directory
2. the extensions management ui provides buttons to download and install
![image](/uploads/c618c97b6ec39f98d9b884b0211187fb/image.png)
Proposed behaviour
----------------------------------------
1. an extension that was previously installed but since disabled or uninstalled remains present in the extension directory
2. the extensions management ui provides buttons to "download" or to "download and install"
Comments
----------------------------------------
Of course best practice is to remove any extension which is uninstalled, but disabled extensions are also present in the filesystem. Being able to update extensions that are not installed, improves security as the latest stable code can be downloaded.https://lab.civicrm.org/dev/core/-/issues/4502SearchKit should provide special options - here: get financial_account inform...2023-08-17T17:44:46ZDetlev SieberSearchKit should provide special options - here: get financial_account information for payment_instrument## Overview
I am working on a replacement for the report "Bookkeeping Transactions", based on SearchKit.
A similar thing I had done years ago by customizing this core report - but that customizing doesn't work anymore with current Civi...## Overview
I am working on a replacement for the report "Bookkeeping Transactions", based on SearchKit.
A similar thing I had done years ago by customizing this core report - but that customizing doesn't work anymore with current CiviCRM versions and I thought it were a smart idea to refactor that using SearchKit.
Unfortunately, it is very hard (if not impossible) to get this some information into this report:
## Current behaviour
1) I did not succeed at all in exporting financial transactions. So I decided, as a workaround, to use line times instead (which is sufficient in my current use case, but is not sufficient for a replacement of the report "Bookkeeping Transactions".
2) Still, I was not able to get information on the accounting_code of the payment_instrument (or any other data from the financial_account table)
## Proposed behaviour
It would be nice to have a simple way to achieve the accounting_code for a payment_instrument.
## Comments
As a workaround, until there is a fix, I used the description field of the payment method to record the accounting code to "rewrite" the field in the display - this might help until a better fix.
`{"[LineItem_Contribution_contribution_id_01.payment_instrument_id:description]"}`https://lab.civicrm.org/dev/core/-/issues/1536Develop unit tests that catch red warning boxes on common forms2023-08-17T05:03:27ZDaveDDevelop unit tests that catch red warning boxes on common formsMaking myself a rainy day todo.
* Forms are not well covered by unit tests. In general that's not what pure unit tests are supposed to do, but I'm thinking there could be something minimal.
* Since the addition of popup forms, warnings ...Making myself a rainy day todo.
* Forms are not well covered by unit tests. In general that's not what pure unit tests are supposed to do, but I'm thinking there could be something minimal.
* Since the addition of popup forms, warnings and notices don't get seen when testing because they get snippet'd out.
* It's happening often enough where changes introduce some type of "missing XXX" from forms.
So it might be as simple as a test that runs through some common forms and sets up some vars and calls preprocess and buildform and when run as tests that should show notices. It won't catch everything, but might reduce the problem.https://lab.civicrm.org/dev/core/-/issues/2639Money: Plan to migrate from currency separators from locale2023-08-16T05:03:18ZeileenMoney: Plan to migrate from currency separators from localeThere is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com...There is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com/civicrm/civicrm-core/pull/20296#issuecomment-855377189
"Override currency separators" - "By default CiviCRM will format currency in accordance with the locale for the user that is viewing the information"
I've moved the text below from a comment on the github PR to here ....
In terms of adding a setting I went hunting for where it was discussed before & it is here
https://github.com/civicrm/civicrm-core/pull/19753
![image](https://user-images.githubusercontent.com/336308/120940640-63d47800-c772-11eb-8b46-302f4d311ef3.png)
Further down the same PR is the content that was pasted into the dev-digest
![image](https://user-images.githubusercontent.com/336308/120940681-92eae980-c772-11eb-9ff9-588d1e3ca663.png)
Compared to @mattwire's suggestion this is
1) implicitly opt in at the start - ie let early adopters set it & when we are confident be more aggressive
2) a different setting name / description - I think setting money_locale might be less intuitive short term (since it magically disables the other settings) and more intuitive longer term since the other settings should become meaningless & disappear over time.
Revisiting @jaapjansma's comment
![image](https://user-images.githubusercontent.com/336308/120940808-33410e00-c773-11eb-9bae-9910a3ff7583.png)
It DOES seem like site locale is going to be wanted as a setting - although it could be that this is not the point where we add ithttps://lab.civicrm.org/dev/core/-/issues/2595Change Log Tab Excrutiatingly Slow - Poorly Performing Query and Fix (from 8 ...2023-08-14T13:09:44ZgordanChange Log Tab Excrutiatingly Slow - Poorly Performing Query and Fix (from 8 minutes down to 4 seconds)The page takes about 8 minutes to return which is absurdly slow for anything expected to be remotely interactive. It is so slow that my client is referring to it as the "Triangle of Doom".
I tracked it down to this query:
```
INSERT IG...The page takes about 8 minutes to return which is absurdly slow for anything expected to be remotely interactive. It is so slow that my client is referring to it as the "Triangle of Doom".
I tracked it down to this query:
```
INSERT IGNORE INTO civicrm_tmp_e_logsummary_ffa3ac146126d178ade367f2a5d17bf5
SELECT activity_id, IF (entity_log_civireport.log_action = 'Insert' AND extra_table.activity_type_id = 51 , GROUP_CONCAT(entity_log_civireport.contact_id), 1) , entity_log_civireport.log_action as log_civicrm_entity_log_action, 'log_civicrm_activity_contact' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id, entity_log_civireport.log_date as log_civicrm_entity_log_date, modified_contact_civireport.display_name as log_civicrm_entity_altered_contact, modified_contact_civireport.id as log_civicrm_entity_altered_contact_id, entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id, modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted, altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM staging_civicrm.log_civicrm_activity_contact entity_log_civireport
JOIN civicrm_contact modified_contact_civireport ON (entity_log_civireport.contact_id = modified_contact_civireport.id )
JOIN staging_civicrm.log_civicrm_activity extra_table ON extra_table.id = entity_log_civireport.activity_id
LEFT JOIN civicrm_contact altered_by_contact_civireport ON (entity_log_civireport.log_user_id = altered_by_contact_civireport.id)
WHERE modified_contact_civireport.id = 338520 AND
entity_log_civireport.log_action != 'Initialization'
GROUP BY entity_log_civireport.log_conn_id,
entity_log_civireport.log_user_id,
EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date),
entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC;
EXPLAIN shows:
```
```
+------+-------------+-------------------------------+--------+---------------+---------+---------+---------------------------------------------------+---------+-------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------------------------------+--------+---------------+---------+---------+---------------------------------------------------+---------+-------------------------------------------------+
| 1 | SIMPLE | modified_contact_civireport | const | PRIMARY | PRIMARY | 4 | const | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | extra_table | ALL | NULL | NULL | NULL | NULL | 3014020 | |
| 1 | SIMPLE | entity_log_civireport | ALL | NULL | NULL | NULL | NULL | 5518537 | Using where; Using join buffer (flat, BNL join) |
| 1 | SIMPLE | altered_by_contact_civireport | eq_ref | PRIMARY | PRIMARY | 4 | staging_civicrm.entity_log_civireport.log_user_id | 1 | Using where |
+------+-------------+-------------------------------+--------+---------------+---------+---------+---------------------------------------------------+---------+-------------------------------------------------+
```
The fix passes:
First pass:
```
ALTER TABLE log_civicrm_activity_contact ADD INDEX index_activity_id (activity_id);
```
With no further changes, this alone makes the above query go from 8 minutes to 1m45s.
Explain plain:
```
+------+-------------+-------------------------------+--------+-------------------+-------------------+---------+---------------------------------------------------+---------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------------------------------+--------+-------------------+-------------------+---------+---------------------------------------------------+---------+---------------------------------+
| 1 | SIMPLE | modified_contact_civireport | const | PRIMARY | PRIMARY | 4 | const | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | extra_table | ALL | NULL | NULL | NULL | NULL | 3014020 | Using where |
| 1 | SIMPLE | entity_log_civireport | ref | index_activity_id | index_activity_id | 5 | staging_civicrm.extra_table.id | 1 | Using where |
| 1 | SIMPLE | altered_by_contact_civireport | eq_ref | PRIMARY | PRIMARY | 4 | staging_civicrm.entity_log_civireport.log_user_id | 1 | Using where |
+------+-------------+-------------------------------+--------+-------------------+-------------------+---------+---------------------------------------------------+---------+---------------------------------+
```
Second pass:
```
ALTER TABLE log_civicrm_activity ADD INDEX index_id (id);
```
Change the JOIN order explicitly and add a hint for the query optimizer to not re-order the JOINs:
```
SELECT STRAIGHT_JOIN activity_id, IF (entity_log_civireport.log_action = 'Insert' AND extra_table.activity_type_id = 51 , GROUP_CONCAT(entity_log_civireport.contact_id), 1) , entity_log_civireport.log_action as log_civicrm_entity_log_action, 'log_civicrm_activity_contact' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id, entity_log_civireport.log_date as log_civicrm_entity_log_date, modified_contact_civireport.display_name as log_civicrm_entity_altered_contact, modified_contact_civireport.id as log_civicrm_entity_altered_contact_id, entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id, modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted, altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM civicrm_contact modified_contact_civireport
JOIN staging_civicrm.log_civicrm_activity_contact entity_log_civireport ON entity_log_civireport.contact_id = modified_contact_civireport.id
JOIN staging_civicrm.log_civicrm_activity extra_table ON extra_table.id = entity_log_civireport.activity_id
LEFT JOIN civicrm_contact altered_by_contact_civireport ON entity_log_civireport.log_user_id = altered_by_contact_civireport.id
WHERE modified_contact_civireport.id = 338520 AND
entity_log_civireport.log_action != 'Initialization'
GROUP BY entity_log_civireport.log_conn_id,
entity_log_civireport.log_user_id,
EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date),
entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC;
```
New EXPLAIN:
```
+------+-------------+-------------------------------+--------+-------------------+----------+---------+---------------------------------------------------+---------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------------------------------+--------+-------------------+----------+---------+---------------------------------------------------+---------+---------------------------------+
| 1 | SIMPLE | modified_contact_civireport | const | PRIMARY | PRIMARY | 4 | const | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | entity_log_civireport | ALL | index_activity_id | NULL | NULL | NULL | 5518537 | Using where; Using filesort |
| 1 | SIMPLE | extra_table | ref | index_id | index_id | 5 | staging_civicrm.entity_log_civireport.activity_id | 1 | |
| 1 | SIMPLE | altered_by_contact_civireport | eq_ref | PRIMARY | PRIMARY | 4 | staging_civicrm.entity_log_civireport.log_user_id | 1 | Using where |
+------+-------------+-------------------------------+--------+-------------------+----------+---------+---------------------------------------------------+---------+---------------------------------+
```
This gets it down to 4 seconds!
Since the first index we started with is no longer getting used in the final variant, we can just not add it.
Summary:
To fix "Change Log" tab taking forever to load, the following fix is needed:
Add index:
```
ALTER TABLE log_civicrm_activity ADD INDEX index_id (id);
```
Make the code emit the query modified as follows:
```
INSERT IGNORE INTO civicrm_tmp_e_logsummary_ffa3ac146126d178ade367f2a5d17bf5
SELECT STRAIGHT_JOIN activity_id, IF (entity_log_civireport.log_action = 'Insert' AND extra_table.activity_type_id = 51 , GROUP_CONCAT(entity_log_civireport.contact_id), 1) , entity_log_civireport.log_action as log_civicrm_entity_log_action, 'log_civicrm_activity_contact' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id, entity_log_civireport.log_date as log_civicrm_entity_log_date, modified_contact_civireport.display_name as log_civicrm_entity_altered_contact, modified_contact_civireport.id as log_civicrm_entity_altered_contact_id, entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id, modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted, altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM civicrm_contact modified_contact_civireport
JOIN staging_civicrm.log_civicrm_activity_contact entity_log_civireport ON entity_log_civireport.contact_id = modified_contact_civireport.id
JOIN staging_civicrm.log_civicrm_activity extra_table ON extra_table.id = entity_log_civireport.activity_id
LEFT JOIN civicrm_contact altered_by_contact_civireport ON entity_log_civireport.log_user_id = altered_by_contact_civireport.id
WHERE modified_contact_civireport.id = 338520 AND
entity_log_civireport.log_action != 'Initialization'
GROUP BY entity_log_civireport.log_conn_id,
entity_log_civireport.log_user_id,
EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date),
entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC;
```
Not only does this speed it up from 8 minutes down to 4 seconds, it also doesn't wreak havoc with row locking where every row scanned gets locked by the transaction engine, potentially resulting in a massive query pile-up in the database.https://lab.civicrm.org/dev/core/-/issues/521PCP Owner notification email sending before payment2023-08-14T05:03:17Zrita_compucorpPCP Owner notification email sending before paymentHi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates y...Hi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates you out from civicrm to its own payment page (like sagepay, or paypal standard) the owner notification is sent before the payment has been made.
Steps:
- create a contribution page and enable fundraising pages to be created under it
- make the payment processor to be Sagepay or Paypal standard
- create a fundraising page
- then log out and start donating to the fundraising page
- when you click confirm button on the fundraising page, you will get navigated to the payment processor you set up for the contribution page --> this is the point when the notification email is sent to the fundraiser
Expected result: notification for the owner is sent only after a successful donation to the fundraising pagehttps://lab.civicrm.org/dev/core/-/issues/3361View and Edit links for event participants are inconsistent and in some cases...2023-08-12T00:24:39ZlarsssandergreenView and Edit links for event participants are inconsistent and in some cases do not allow editingWhen using a price set, the View and Edit links for a participants lead to different forms depending on if the registration has an associated contribution. When there is a contribution record, the Edit link does not allow the user to edi...When using a price set, the View and Edit links for a participants lead to different forms depending on if the registration has an associated contribution. When there is a contribution record, the Edit link does not allow the user to edit the price set selections, while it is possible to edit those selection from the View link (with Change Selections). I believe this is a regression.
When there is no contribution record, you cannot edit the price set selections from the View link, but you can from the Edit link. That seems confusing for users and it would be best to make it consistent.
Here are some screenshots:
1) View with a contribution, this makes sense
![image](/uploads/52e7c3a5b96befe0a404f57850cc5bcf/image.png)
2) View without a contribution, seems like it there should be possible to change selections here as well for consistency (or else a user may think they can't edit the price set selections)
![image](/uploads/c93e10bbecf9ae053ea771becb07ac12/image.png)
3) Edit with a contribution, this should be the same as the View with a contribution, i.e. there should be a Change Selections link and the table of selections above it
![image](/uploads/95edcf86ca33d6bcdff302cee619acf8/image.png)
4) Edit without a contribution, this makes sense
![image](/uploads/12e211610125abb94b4f829bca465ebe/image.png)
I believe 3 - Edit with a contribution is a regression. I get his behaviour on dmaster, 5.37 and 5.35.2, but not on 5.24.5, where there is a Change Selections link and the table above.
Changing 2 - View without a contribution may be more complicated. What about adding an Edit Registration link, in the same place where the Change Selections link would otherwise be, that simply takes you to the edit form? As far as I can tell, trying to use Change Selections with a registration that doesn't have a contribution will result in errors. I'm not sure what would be involved in making it possible to use Change Selections in this case, but it seems like adding an edit link would be a simpler solution to keep some consistency between these two cases.https://lab.civicrm.org/dev/core/-/issues/2609Move full text search to an extension?2023-08-11T05:03:16ZeileenMove full text search to an extension?We just hit an issue where someone crashed our db with the full text search. It feels like something that should be deliberately enabled rather than available by default....We just hit an issue where someone crashed our db with the full text search. It feels like something that should be deliberately enabled rather than available by default....https://lab.civicrm.org/dev/core/-/issues/2562Simplify when scheduled reminders are sent or not sent for events2023-08-07T15:14:25ZlarsssandergreenSimplify when scheduled reminders are sent or not sent for eventsFor event scheduled reminders, you can set emails to be sent on specific days or N hours or days before or after an event (or before or after registration ends or starts). For emails sent on a specific day, this is straightforward. They ...For event scheduled reminders, you can set emails to be sent on specific days or N hours or days before or after an event (or before or after registration ends or starts). For emails sent on a specific day, this is straightforward. They are sent on that day and anyone who registers after that day does not receive the email.
But for emails scheduled N hours or days before or after an event, the behaviour is less clear. My testing indicates contacts registered soon after an event has ended can still receive emails scheduled to go out 24 hours before the event start or 30 hours before the event end (but contacts registered somewhat later won't receive these emails). Similarly, contacts registered a day after an event ends will receive an email scheduled to go out an hour after the event start. I can't find any documentation that tells users what will happen when they schedule these reminders, though there are a few questions on Stack Exchange wondering about what actually does happen (opinions vary, which is a bad sign).
I think the clearest and best option would be to simply send scheduled reminders at the time they are scheduled and not afterwards. For one, this is simple and probably what users assume happens. It's certainly what our users think. Secondly, let's say you have an event with a confirmation email, one scheduled reminder a day before the event and one 2 hours before the event: with the current system a person who registers at the last minute will receive three emails in short order, which doesn't make sense. Thirdly, if a user registers someone in the backend for an event after the event has ended, just to record their attendance, they probably don't want that person to automatically receive emails previously scheduled to go out right after the event start or similar (this could be avoided by using a different status for the post-event registration and the scheduled reminder, but that's a pretty fine point that users won't think about).
In short, I think there are so many potential pitfalls with a system that sends scheduled reminders after the time set on the reminder has passed, especially when none of this behaviour is apparent to users when they set up the reminders. To me, this outweighs the potential convenience of having reminders sent to late registrants, so we should simply not send scheduled reminders whose time has passed.
I haven't dug into the code yet to see how this all works, but I'll do that and submit a PR as long as this is supported.
EDIT: removed aside on timing of scheduled reminders.https://lab.civicrm.org/dev/core/-/issues/2597Tabset for manage contribution pages or manage events requires Classname to e...2023-08-07T15:13:57ZlarsssandergreenTabset for manage contribution pages or manage events requires Classname to equal pathIf you add a tab to a tabset for Configure Event, it will work fine with the last word of the class name different from the last word of the path, except for trying to save, which will save, but redirect to Manage Events instead of stayi...If you add a tab to a tabset for Configure Event, it will work fine with the last word of the class name different from the last word of the path, except for trying to save, which will save, but redirect to Manage Events instead of staying on the same tab. This is because [code here](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Event/Form/ManageEvent.php#L377) expects lastWord from CRM_myExtension_Form_lastWord to be the same as the path, i.e. /civicrm/event/manage/lastword. Everything else works as expected if these are different, except Save.
Looks like this same issue exists for [Contribution Pages](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Contribute/Form/ContributionPage.php#L427
) and probably elsewhere.
For now, I've added a warning to the docs for [the tabset hook](https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/908). It would be good to fix this so the code linked above uses the path for the url instead of the class, at some point.https://lab.civicrm.org/dev/core/-/issues/2557Add hook support for Report tabs.2023-08-06T05:03:24ZyashodhaAdd hook support for Report tabs.Add hook support for Report tabs.Add hook support for Report tabs.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2584Proposal - Separation of Default Language for contacts from the default Language2023-08-05T05:03:23ZVangelisPProposal - Separation of Default Language for contacts from the default Language## Scenario
Right now, the preferred communication language for new contacts is bound to what the site's default language is in or to 'use language in use at the time' is in but as it seems, neither of them fits the scenario below:
A m...## Scenario
Right now, the preferred communication language for new contacts is bound to what the site's default language is in or to 'use language in use at the time' is in but as it seems, neither of them fits the scenario below:
A multinational organization in country A has 2 (or more) enabled languages in their Drupal configuration, thus into each user's profile. They want to have the preferred communication language for each of their contacts set to country A's language while the menus needs to be retained in English by force.
## How to replicate
1. On a Drupal 7 site, allow 2 languages, set the English as default
1. In CiviCRM > Administer > Localisation, set:
* the default language to the non-English
* Inherit CMS language to 'Yes'
* Available Languages: Add the 2 languages that you've added in Drupal
* Default Language for contacts: Any (I tried all options)
* Logout and login again
1. Try to create a new contact
## Possible solution
The suggestion is besides what already is in the selector, to add also a list of available languages to the field 'Default Language for contacts' so that we can enforce a language.
I've already worked on a patch that does the above, I'm not sure if my approach of this idea hides any potentials flaws.
Selector before:
![image](/uploads/f19b2c389213236f81e0df86a5335d33/image.png)
Selector after:
![image](/uploads/75e42b33fe04528f1e2b0d298b03ac30/image.png)
Example: Danish
![Screenshot_from_2021-05-03_09-58-12](/uploads/b12950fd7f96ee0604c839ee1bcbb61e/Screenshot_from_2021-05-03_09-58-12.png)
![Screenshot_from_2021-05-03_09-56-50](/uploads/96302b55f8779875e89b5b565cdd07d0/Screenshot_from_2021-05-03_09-56-50.png)
---
PR is [here - 20214](https://github.com/civicrm/civicrm-core/pull/20214)https://lab.civicrm.org/dev/core/-/issues/852Provide wysiwyg editor for additional confirmation email text2023-08-05T04:15:04ZyashodhaProvide wysiwyg editor for additional confirmation email textProvide wysiwyg editor for additional confirmation email text for online and offline event registrations. (In other words, this is the text from the text area widget on the Manage Event page, not the event template itself.)
https://civi...Provide wysiwyg editor for additional confirmation email text for online and offline event registrations. (In other words, this is the text from the text area widget on the Manage Event page, not the event template itself.)
https://civicrm.stackexchange.com/questions/21255/confirmation-email-providing-a-wysiwyg-so-users-can-add-html-ified-contentyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4470Allow disabling household contact type2023-08-04T03:59:56ZlarsssandergreenAllow disabling household contact typeCurrent proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disab...Current proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disabled, so at least disabling households shouldn't break anything. Organizations might be different though and less important to allow disabling. Maybe worth trying to allow disabling households first and then see.https://lab.civicrm.org/dev/core/-/issues/2565HTML editor for additional event confirmation email text2023-08-02T21:16:19ZlarsssandergreenHTML editor for additional event confirmation email textIt would be nice to be able to have an HTML editor for the additional event confirmation text entered on the Manage Event Page that gets inserted into the System Template email template. The benefit would be to be able to easily add link...It would be nice to be able to have an HTML editor for the additional event confirmation text entered on the Manage Event Page that gets inserted into the System Template email template. The benefit would be to be able to easily add links, etc. I understand this will be a complicated one, but it does seem worthwhile as almost every other similar field is HTML, so this one really stands out. [See previous issue.](https://lab.civicrm.org/dev/core/-/issues/852#note_58464)
How it works now: Text from the event confirmation email text is added into the event confirmation message template with some minimal tags added. I see a <p> wrapper around the text and <br /> inserted for newlines, at a cursory glance.
Here's my guess at what needs to happen:
1. Add HTML editor to Event Configuration
2. Add HTML editor on the New Event Registration page (which is also Add Participant from events or Add Event Registration for a contact), so that the message can be edited before sending.
3. Inject content as HTML into Message Templates, i.e. remove code that adds tags, wrap code in div or something.
4. Convert all existing content in the DB with the same process now taken to inject the text into the Message Template or handle the content injection into the Message Template with two cases based on text/HTML.
The first three should be relatively simple, but the last one there seems like the tricky part. How has this has been handled in the past?https://lab.civicrm.org/dev/core/-/issues/2570Option to identify 'deceased' contacts when viewing relationships2023-07-31T05:03:26ZrebeccatregennaOption to identify 'deceased' contacts when viewing relationshipsOverview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, however, it would be extremely useful when viewing relationships on c...Overview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, however, it would be extremely useful when viewing relationships on contact records to know whether one of the contacts involved in the relationship is deceased.
Current behaviour
----------------------------------------
- John is the 'partner of' Fiona
- John is deceased but the relationship (as not manually changed) remained active
- A system user is taking a call from Fiona and looks up her contact record and casually asks how John is, as nothing indicates his passing on the relationship tab thus causing upset and potentially losing a donor
Proposed behaviour
----------------------------------------
Add an icon to the relationship to indicate the contact is deceased.https://lab.civicrm.org/dev/core/-/issues/2551Proposal - add support for defining 'fields' within json blobs2023-07-29T05:03:23ZeileenProposal - add support for defining 'fields' within json blobsThis covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_pro...This covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_processor by having fields that we kinda rename via the payment_processor_type table and as long as there are only 4 fields it's fine. However, it's not a great structure.
I'm working on a monolog extension and like payment processor and geocoders the configuration options desired by the service varies - but it's not 100% open ended - ie we don't want to just pass through 'whatever'. The best data model to store this is a json blob- however, we then have no UI knowledge of what would go in there and afform is unable to present this field in a UI-friendly way
We looked at the idea of having something like
```
<field>
<name>contact_type</name>
</field>
<field>
<name>contact_sub_type</name>
</field>
<field>
<name>options</name>
<type>text</type>
<serialize>json</serialize>
<schema-callback>CRM_My_Schema::getFields</schema-callback>
<schema-watch>contact_type,contact_sub_type</schema-watch>
</field>
```
Where the UI layer would need to implement the ability to watch the fields defined as schema-watch and update the UI based on it (presumably only for fields that are ALSO already displayed)
A simple xml definition of subfields might look like https://gist.github.com/totten/84c140310d4adc9b5d3842b5d3364a9e - which could be rendered by a generic function.
@totten @seamuslee - anything else you think is important to transfer over here?https://lab.civicrm.org/dev/core/-/issues/2545Free memberschip sign up (eg. prayerteam) assumes contribution involved2023-07-29T05:03:22Zmagnolia61Free memberschip sign up (eg. prayerteam) assumes contribution involvedOverview
----------------------------------------
Managing memberships in civicrm currently pretty much assumes a contribution is involved. Which is not the case for many forms of memberships. It is even not possible to create a membersh...Overview
----------------------------------------
Managing memberships in civicrm currently pretty much assumes a contribution is involved. Which is not the case for many forms of memberships. It is even not possible to create a membership sign up page without using a contribution page!
Right now for our summercamps it's pretty strange for people to sign up to become a member of the prayerteam to "review their contribution". Although technically they give their contribution in the form of prayer one could argue.
Example use-case
----------------------------------------
1. Create a membership sign up page in CiviCRM for a free membership
2. Look at the wording of the sign-up button
Current behaviour
----------------------------------------
The current button to sign up for a membership says 'review your contribution'.
Proposed behaviour
----------------------------------------
The button text here should be editable, or for signing up for free memberships a different default wording should be used.
Comments
----------------------------------------
Consistent UI would be I guess to be able to create a membership sign up page from the membership menu. Underwater this could be a contribution page with or without fees involved.https://lab.civicrm.org/dev/core/-/issues/2544Move Contact Layout Editor to a core extension2023-07-27T05:03:20ZcolemanwMove Contact Layout Editor to a core extensionAt some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core...At some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core tarball (via distmaker import), or the `ext/` directory of the core repo.
Today might not be the day for that, but logging some notes on it anyway:
- Today, the only benefit of moving the extension into core is it would be more visible to end-users.
However, in the future, benefits might include:
- Easier simultaneous development of extension & core with no version conflicts.
- Possible to enable the extension by default.
- Possible to rip out redundant functionality from core.
Challenges
- There isn't an easy upgrade path when an extension is moved into core; you end up with 2 copies of the extension
- Currently, the extension scanner does not give the core `ext/` directory top priority, which means older versions of the extension outside core would take precedence.
Considerations
- As handy as it is, Contact Layout Editor still uses smarty to render the page.
- Maybe the end-game is to make that page an Afform instead. However, that day is a long way off given Afform's current capabilities.