CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-02-24T05:03:58Zhttps://lab.civicrm.org/dev/core/-/issues/1653Civi::paths() - Allow bare variable lookup via getUrl/getPath2023-02-24T05:03:58ZtottenCivi::paths() - Allow bare variable lookup via getUrl/getPathOverview
----------------------------------------
The `Civi::paths()->getUrl(...)` and `Civi::paths()->getPath(...)` have a quirky interpretation of bare variable expressions (eg `getPath('[civicrm.packages]')`).
Example use-case
------...Overview
----------------------------------------
The `Civi::paths()->getUrl(...)` and `Civi::paths()->getPath(...)` have a quirky interpretation of bare variable expressions (eg `getPath('[civicrm.packages]')`).
Example use-case
----------------------------------------
```
# (A) With a file/folder/subpath
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/foo/bar');"
# (B) No slash, no dot
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]');"
# (C) With a slash
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/');"
# (D) With a slash and dot
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/.');"
```
Current behavior
----------------------------------------
In scenarios (A), (C), and (D), the value of `[civicrm.packages]` is substituted. But in situation (B), it is treated as a literal file-name and given the default prefix.
```
$ cv ev "echo Civi::paths()->getUrl('[civicrm.packages]');"
http://site/[civicrm.packages]
```
Proposed behavior
----------------------------------------
All examples -- including (B) -- should do substitution.
The `Civi\Core\PathsTest` should be expanded to check scenario (B).
Comments
----------------------------------------
[Historically](https://lab.civicrm.org/dev/wordpress/issues/47#note_33046), when `getPath()`/`getUrl()` were first drafted to support expressions like `[civicrm.files]/persist/contribute`, the primary concerns were (1) backward compatibility for older absolute+relative expressions (without any `[foo]` expressions) and (2) new use-cases like (A). The `[foo]` notation was conceived as an *optional prefix* (with an *implied default*) - and not as a straight-up *variable*. And if you *just* wanted a raw variable, I'd've imagined it'd be faster to call `getVariable()` (bypass the string-munging with `getPath()` etc).
OTOH, if you learned of this API by skimming docblocks or examples (without that historical context), then it'd be natural to assume that (B) would work, and it really is a more approachable interface that way.
Strictly speaking, it is a change in the contract for an obscure edge-case: if you had a file named `/var/www/sites/default/files/civicrm/[foo]`, and if you requested `getPath('[foo]')`, then it currently resolves to the file. With this change, it would interpret `[foo]` as a variable - the variable is probably undefined, which leads to an exception. You'd have to rewrite the call as `getPath('[civicrm.files]/[foo]')`. That's an exceedingly marginal edge-case, and I don't really think it's worth preserving.https://lab.civicrm.org/dev/core/-/issues/1648Determine how to provide parity for apiv4 vs v3 Contact.delete2023-03-26T05:03:15ZeileenDetermine how to provide parity for apiv4 vs v3 Contact.deleteThere are 4 types of Contact.delete in CiviCRM
1) soft-delete - updates is_deleted to true, deletes uf match entries
2) hard delete, - deletes contact record, aborts if related entities exist that block delete, cleans up various entries...There are 4 types of Contact.delete in CiviCRM
1) soft-delete - updates is_deleted to true, deletes uf match entries
2) hard delete, - deletes contact record, aborts if related entities exist that block delete, cleans up various entries that an FK delete will not do
3) contact.update to is_deleted = 1 does 1 without the cleanup
4) contact.delete - does 2 without the cleanup or protection
Currently apiv3 does 1 or 2 depending on the site configuration. It can be 'pushed' to do 2 but will still only do that dependent on user permissions if check_permissions is on.
apiv4 does 3 and 4
I know @colemanw is reluctant to replicate v3 behaviour but I don't think current v4 is an acceptable alternative. Nor do I think the calling function should need to check site delete confighttps://lab.civicrm.org/dev/core/-/issues/1644Merge related activities not deleted when permanently deleting a contact2023-02-26T05:03:38ZeileenMerge related activities not deleted when permanently deleting a contactWhen a contact is merged into a another contact the following happens
- the data is moved over
- the merged contact is 'deleted'
- an activity is created of type 'Contact Merged' - source is logged in contact, target is the retained...When a contact is merged into a another contact the following happens
- the data is moved over
- the merged contact is 'deleted'
- an activity is created of type 'Contact Merged' - source is logged in contact, target is the retained contact
- If the merged contact is being deleted to trash an activity is created of type 'Contact Deleted by Merge' - source is logged in contact, target is deleted contact
When we later fully delete the contact deleted-by-merge only activities linked to no other contact are deleted - in other words the 'Contact Deleted by Merge' activity remains, linked to the source contact.
I believe this activity should be deleted on true-death , as it would not be present had they been fully deleted in the first instance
@pfigel @DaveDhttps://lab.civicrm.org/dev/core/-/issues/1640Update pending contribution status action also send email without warning2020-03-21T19:38:53ZjaapjansmaUpdate pending contribution status action also send email without warningWhen you search for contributions with status pending. You have an action to batch update all contribution statuses to completed. See screenshots
![Screenshot_from_2020-03-10_22-38-02](/uploads/e533c6e42f3ed4d1545f3855d3dd81b8/Screensho...When you search for contributions with status pending. You have an action to batch update all contribution statuses to completed. See screenshots
![Screenshot_from_2020-03-10_22-38-02](/uploads/e533c6e42f3ed4d1545f3855d3dd81b8/Screenshot_from_2020-03-10_22-38-02.png)
![Screenshot_from_2020-03-10_22-39-20](/uploads/d57cd774f224eb3ec62c73dc446628e7/Screenshot_from_2020-03-10_22-39-20.png)
When you do this the system also sends an email receipt to the donor.
**There is no warning about this e-mail.**
Possible solutions:
1. Checkbox for sending e-mails or not (this will give the user control)
2. A warning text indicating that this action also sends an e-mai.
I will see if I can work on option 1.jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/1638Introduce "civi.dao.preUpdate" and "civi.dao.preInsert" events2020-05-18T17:53:27ZhaystackIntroduce "civi.dao.preUpdate" and "civi.dao.preInsert" eventsOverview
----------------------------------------
Following on from the action taken some time ago in [Add civi.dao.preDelete event](https://issues.civicrm.org/jira/browse/CRM-20458) (and the proposal raised in #161 to an extent) it woul...Overview
----------------------------------------
Following on from the action taken some time ago in [Add civi.dao.preDelete event](https://issues.civicrm.org/jira/browse/CRM-20458) (and the proposal raised in #161 to an extent) it would be helpful to apply the same `hook_civicrm_pre` + `hook_civicrm_post` pattern to the Symfony events in `CRM_Core_DAO::save()`. I propose CiviCRM introduces `civi.dao.preUpdate` and `civi.dao.preInsert` events to complement the existing `civi.dao.preDelete` event.
Symfony events have advantages over "old-style" hooks of the form `hook_civicrm_preSave`. The old-style hook format is likely to lead some devs to write callbacks in the format `extensionname_civicrm_preSave_table_name` which are difficult to unhook or prevent from running endlessly. Symfony events _can_ be unhooked and therefore make it relatively easy to avoid endless loops such as @colemanw raises concerns about in [his comment](https://lab.civicrm.org/dev/core/issues/161#note_9549). Also, they are largely undocumented and therefore avoid the effort of having to add to the Docs :-)
Example use-case
----------------------------------------
Let's look at what can be done with operations on "Option Value" data:
In both the [CiviCRM Event Organiser](https://github.com/christianwach/civicrm-event-organiser) and the [CiviCRM ACF Integration](https://github.com/christianwach/civicrm-acf-integration) plugins, I'd like to be able to inspect an Option Value _before_ it is saved to the database so that I know what the full state of the Option Value was before the update is applied. Once the edit has happened, there's (obviously) no way of retrieving the required data.
(FWIW, this is to perform actions on synced entities in WordPress rather than modifying the Option Value before it is saved, but the same applies should Option Value data need to be modified.)
Current behaviour
----------------------------------------
As far as I can tell, there isn't a hook available for me to inspect an Option Value data prior to it being created or updated programatically. I _partially_ solve this for changes made via the CiviCRM UI using the equivalent pre-post combination of `hook_civicrm_preProcess` and `hook_civicrm_postProcess`. However changes made via AJAX actions on the main "Event Type Options" listing screen can only be detected _after_ the edit has been made.
Proposed behaviour
----------------------------------------
To mirror the pattern of `hook_civicrm_pre` + `hook_civicrm_post` and `hook_civicrm_preProcess` + `hook_civicrm_postProcess` and the existing pattern of `civi.dao.preDelete` + `civi.dao.postDelete` to complete the set with:
* `civi.dao.preInsert` + `civi.dao.postInsert`
* `civi.dao.preUpdate` + `civi.dao.postUpdate`
Comments
----------------------------------------
PR to follow.5.26.0haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1634Evaluate if any indexed fields are unused2022-12-04T23:07:09ZeileenEvaluate if any indexed fields are unused
**Proposal** (note this is being updated based on discussion & comments may refer to an earlier version)
1. Remove the following columns from the xml from civicrm_activity
* phone_id
* phone_number
* relationship_id
1. Remove th...
**Proposal** (note this is being updated based on discussion & comments may refer to an earlier version)
1. Remove the following columns from the xml from civicrm_activity
* phone_id
* phone_number
* relationship_id
1. Remove the index from the xml on
* medium_id
* is_deleted
1. During upgrade we drop the above columns, if empty.
**Follow ups to consider**
2. There are other columns in the civicrm_activity table that are case specific - we might consider indexing is_current_revision & original_id only when CiviCase is enabled
3. I've been doing some tests on searches and found that searching is faster if I DROP the contribution_status_id index - it might be interesting to test the activity_type_id index although I suspect it has a much greater cardinality & is more useful
**Impact of the above**
1. Data would not be lost but api fields would no longer access those fields
2. Developers who might be using them outside of core could be impacted - we can mitigate by communicating on the dev list & perhaps putting checks & deprecation notices onto sites with data in the fields for a few months before making any changes.
3. DB size would be reduced. Note that empty fields contribute notably to table size IF they are indexed
4. Dev confusion & efficiency is improved by not having unused stuff in core.
**Background**
Obviously that's not something we should rush into so I'll have to ping the dev list etc
Looking at our civicrm_activity table it appears that each index has a base size - of around a half a gig. From there, the index size increases based on how much data is in the table. So an index on an empty field is around 57% of the size of our largest index.
There are 5 fields that are indexed + empty in our database for the civicrm_activity table (
```
Original id used for CiviCase
Medium id
Phone id
relationship_id
is_deleted
```
Plus - is_current_revision is effectively null
So my first question is are these all used in other databases - e.g when civicase is in use.
I couldn't spot references to phone_id and it feels 'wrong' to me anyway as I think you would want to either link to the contact or have a hard reference. I wonder if some of these fields are quietly obsolete?
It's very unsafe to drop core fields. However, I'm pondering dropping the indexes on these fields
@DaveD I'd appreciate your thoughts....https://lab.civicrm.org/dev/core/-/issues/1633Proposal - add an optional access_arguments key to setting spec2023-02-22T05:03:56ZeileenProposal - add an optional access_arguments key to setting specCurrently when calling Setting.get or Setting.getoptions you need 'administer CiviCRM' permission
I recently found that an angular form was broken for users without this & digging into it I'm using the hook as a short term solution...Currently when calling Setting.get or Setting.getoptions you need 'administer CiviCRM' permission
I recently found that an angular form was broken for users without this & digging into it I'm using the hook as a short term solution - ie
```
if ($entity === 'setting' &&
(($action === 'get' && isset($params['return']) && $params['return'] === 'deduper_equivalent_name_handling')
|| ($action === 'getoptions' && $params['field'] === 'deduper_equivalent_name_handling'))
) {
$permissions['setting']['get'] = [['merge duplicate contacts', 'administer CiviCRM']];
}
```
But this relies on the setting being accessed this way - so it's very brittle. I'm not sold on just lowering the whole permission level.
My feeling is that we should extend the metadata spec - ie add optional key of
'access_arguments' => ['default' => 'be amazing', 'get' => 'be fair to middling']
- this would mean only amazing people can create the setting (when check_permissions are enabled) but fair to middling people could get the setting.
In all cases the default is still 'Administer CiviCRM' if nothing is set
@colemanw @totten @seamuslee @mattwirehttps://lab.civicrm.org/dev/core/-/issues/1632End users can trigger a CiviCRM system cache flush which is an expensive proc...2020-09-17T09:44:59Zjustinfreeman (Agileware)End users can trigger a CiviCRM system cache flush which is an expensive process and has an overall negative impact on CiviCRM performance by just changing a Group Title or DescriptionEnd users can trigger a CiviCRM system cache flush which is an expensive process and has an overall negative impact on CiviCRM performance by just changing a Group Title or Description.
In fact, if you add, update or delete any CiviCRM ...End users can trigger a CiviCRM system cache flush which is an expensive process and has an overall negative impact on CiviCRM performance by just changing a Group Title or Description.
In fact, if you add, update or delete any CiviCRM Group this action will trigger a CiviCRM system cache flush and again, CiviCRM performance is impacted whilst caches are re-built.
CRM/Group/Form/Edit.php
https://github.com/civicrm/civicrm-core/blob/master/CRM/Group/Form/Edit.php#L348
```
/**
* Process the form when submitted.
*/
public function postProcess() {
CRM_Utils_System::flushCache();
```
CRM/Utils/System.php
https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System.php#L1450
```
/**
* Reset the various system caches and some important static variables.
*/
public static function flushCache() {
// flush out all cache entries so we can reload new data
// a bit aggressive, but livable for now
CRM_Utils_Cache::singleton()->flush();
```
Agileware Ref: CIVICRM-1443https://lab.civicrm.org/dev/core/-/issues/1628Fix display of administrator permissions in WordPress Multisite2020-03-05T10:13:32ZhaystackFix display of administrator permissions in WordPress MultisiteOverview
----------------------------------------
In WordPress Multisite, roles function somewhat differently to Single Site: in Multisite there is a "Network Administrator" with greater capabilities than a "Site Administrator". At prese...Overview
----------------------------------------
In WordPress Multisite, roles function somewhat differently to Single Site: in Multisite there is a "Network Administrator" with greater capabilities than a "Site Administrator". At present, the "WordPress Permissions" screen does not take this into account.
Example use-case
----------------------------------------
1. In WordPress Multisite, visit the "WordPress Permissions" screen as a "Network Administrator"
1. Notice that there is no column for modifying the permissions for a "Site Administrator"
Current behaviour
----------------------------------------
A "Network Administrator" cannot limit the permissions for a "Site Administrator"
Proposed behaviour
----------------------------------------
A "Network Administrator" should be able to limit the permissions for a "Site Administrator"
Comments
----------------------------------------
PR to follow.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1625IDN-Domain Emails - dont pass email check.2022-09-29T14:42:46ZRar9IDN-Domain Emails - dont pass email check.See Issue https://issues.civicrm.org/jira/browse/CRM-15975 and
Email validation is too restrictive (rejects IDN addresses) https://issues.civicrm.org/jira/browse/CRM-16313
Emails with these Characters should pass
https://www.denic.de/...See Issue https://issues.civicrm.org/jira/browse/CRM-15975 and
Email validation is too restrictive (rejects IDN addresses) https://issues.civicrm.org/jira/browse/CRM-16313
Emails with these Characters should pass
https://www.denic.de/en/know-how/idn-domains/idn-character-list/
Last tested with Civicrm 5.22.1 + Drupal 7
Php 7.2x Intl enabled.https://lab.civicrm.org/dev/core/-/issues/1621cascade delete of civicrm_financial_type to civicrm_entity_financial_account2023-02-20T05:04:09ZJoeMurraycascade delete of civicrm_financial_type to civicrm_entity_financial_account1. Background
The civicrm_entity_financial_account table stores, amongst other things, the relationships between civicrm_financial_type and civicrm_financial_account records.
2. Current situation
When financial types are deleted, the...1. Background
The civicrm_entity_financial_account table stores, amongst other things, the relationships between civicrm_financial_type and civicrm_financial_account records.
2. Current situation
When financial types are deleted, there are stranded records in civicrm_entity_financial_account with no referent for their financial_type_id.
3. Proposed change
When a financial type with id=n is going to be deleted, first
```sql
DELETE FROM civicrm_entity_financial_account WHERE financial_type_id=n;
```
On upgrade, run something like
```sql
DELETE efa.* FROM civicrm_entity_financial_account efa LEFT JOIN civicrm_financial_type ft ON efa.financial_type_id=ft.id WHERE ft.id IS NULL;
```seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1620Extend content array of hook_civicrm_alterMailContent2023-03-18T05:03:32ZscardiniusExtend content array of hook_civicrm_alterMailContentOverview
----------------------------------------
Extend `$content` array of alterMailContent hook
Example use-case
----------------------------------------
More fields improve possibilities durign processing the hook.
Current behavio...Overview
----------------------------------------
Extend `$content` array of alterMailContent hook
Example use-case
----------------------------------------
More fields improve possibilities durign processing the hook.
Current behaviour
----------------------------------------
According to doc https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterMailContent/ the `$content` array should have mailing_id field/index. However during sending mailings there are only 'html', 'text' and 'subject' indexes.
Proposed behaviour
----------------------------------------
The `$content` is generated by CRM_Mailing_BAO_Mailing->getTemplates() method. This method should always adds more fields, like 'mailing_id' or 'campaign_id' which can be used during processing the hook.
Comments
----------------------------------------
This modification is used for altering urls with utm params, see https://github.com/WeMoveEU/utmaltorhttps://lab.civicrm.org/dev/core/-/issues/1616Activity Search doesn't display activities with no "With Contact"2023-02-16T15:15:35ZJonGoldActivity Search doesn't display activities with no "With Contact"To replicate:
* Create a new activity without anyone listed as "With Contact".
* Search for the activity from **Find Activities**.
I hadn't considered the use case of an activity with no "With Contact", but apparently my client has - an...To replicate:
* Create a new activity without anyone listed as "With Contact".
* Search for the activity from **Find Activities**.
I hadn't considered the use case of an activity with no "With Contact", but apparently my client has - and it's not a required field. So it seems that these activities should show up in search.https://lab.civicrm.org/dev/core/-/issues/1615Migrate installers to "setup" API2024-02-07T01:05:15ZtottenMigrate installers to "setup" APIOverview
----------------------------------------
The aim of this filing is to do a round of consolidation/reconciliation in the Civi installer code: get rid of `install/*.php` and instead use `civicrm-setup`. The latter offers:
* Bett...Overview
----------------------------------------
The aim of this filing is to do a round of consolidation/reconciliation in the Civi installer code: get rid of `install/*.php` and instead use `civicrm-setup`. The latter offers:
* Better APIs and better organization - e.g. you can drill-down on most installation tasks by browsing the [plugins](https://github.com/civicrm/civicrm-setup/tree/master/plugins/) (esp `installFiles` and `installDatabase`); inspect the list of event-listeners; and [programmatically manage plugins](https://github.com/civicrm/civicrm-setup/blob/master/docs/plugins.md).
* More sensible UX - the list of options is more useful for a new admin initializing the system.
![Screen_Shot_2020-02-14_at_6.03.12_PM](/uploads/f107602f3ebd5f60b6870322711629a5/Screen_Shot_2020-02-14_at_6.03.12_PM.png)
Some background: https://civicrm.org/blog/totten/developers-revising-the-civicrm-installer-library-cli-wordpress
Use-cases
----------------------------------------
There are several different use-cases for performing installation; most permutations of the following variables are fair:
1. __UF/CMS__: Civi can be installed on top of Backdrop, Drupal 6/7/8, Joomla, WordPress.
2. __Medium__: Civi can be installed through:
* Web installation screens (e.g. `civicrm/install/index.php` and the Joomla installer)
* CLI installers (e.g. `cv core:install`)
* Scripts/packagers (e.g. Drupal "profiles", `civibuild`, `docker`)
3. __Options__: Civi can be configured with:
* CMS DB or separate DB
* Empty data or demo data
* "Components" (enabled/disabled)
* "Extensions" (enabled/disabled)
* "Settings" (defaults/overrides)
* Path/URL definitions (defaults/overrides)
Current behavior
----------------------------------------
There are separate installers. There are number of arbitrary differences and un-DRY things.
Proposed behavior
----------------------------------------
All installers use a PHP API for Civi installation.
Process
----------------------------------------
There are several things to consolidate here; it's not just one commit or PR. Suggested tasks (in approximate order):
* [x] __Move code from `civicrm-setup.git` into `civicrm-core.git`__ (*done, [#16618](https://github.com/civicrm/civicrm-core/pull/16618)*):
* `civicrm-setup` started as a separate repo so that I could iterate quickly in the early stages. However, as this gets rolled into more use-cases, it's likely to get referenced in more places (e.g. `civicrm-drupal-8.git`, `civicrm-drupal.git`, `civicrm-wordpress.git`, `civicrm-backdrop.git`), and it is also reasonable to expect a few small patches. Unfortunately, juggling small patches in that arrangement would be mentally draining. Migrating the code into `civicrm-core.git` will remove one layer of complexity.
* Like the API framework or DB framework, the *installer* is sufficiently important to `civicrm-core` go into the main repo.
* [x] __Move docs from `civicrm-setup.git` into `civicrm-dev-docs.git`__ (*done, see [Dev Guide: Setup Reference](https://docs.civicrm.org/dev/en/latest/framework/setup/)*)
* [ ] __Update Civi-WordPress__:
* [x] (Phase 1) Switch the default from `install/` UI to `civicrm-setup` UI. (*It's currently available opt-in. Switch to opt-out.*)
* [x] (Phase 2) Update `wp-cli/civicrm.php` so that WP-CLI uses `civicrm-setup` API.
* [ ] (Phase 3) Ensure that all tasks (e.g. registering base-pages or permissions) are called in WP-oriented `*.civi-setup.php` plugin.
* [ ] __Update Civi-D8/D9__
* [x] (Phase 1) Update `civicrm.install` to call `civicrm-setup` APIs (related: https://github.com/civicrm/civicrm-drupal-8/pull/37)
* [ ] (Phase 2) Update `civicrm.drush.inc` so that D7/BD use `civicrm-setup` API.
* [ ] __Update Civi-D7/BD__
* [x] (Phase 1) Update `install/index.php` so that D7/BD default to loading the `civicrm-setup` UI. The sysadmin docs may continue pointing admins to `install/index.php`. Optionally, allow one to use a parameter to opt-out and get the old UI.
* [ ] (Phase 2) Update `civicrm.drush.inc` so that D7/BD use `civicrm-setup` API.
* [x] __Update Civi-Joomla__
* [x] (Phase 2) Update to use `civicrm-setup` API
* [x] __Ignore Civi-D6__
* [ ] __Update civibuild__
* [ ] (Phase 2) Switch implementation from `civicrm_install()` to `civicrm_install_cv()` (related WIP: https://github.com/civicrm/civicrm-buildkit/pull/673)
* [ ] (Phase 3) Remove old implementation
* [ ] (Phase ??) Convert `civicrm_make_test_settings_php()` to a `civicrm-setup` plugin. Document an installer-option to initialize test/dev-harness.
* [ ] __Remove all opt-outs. Final pass to double-check/remove all remaining logic from `install/` folder__
* (*This is the last step, after all the others.*)https://lab.civicrm.org/dev/core/-/issues/1614META Token improvements (TokenProcessor)2023-03-18T06:38:34Zmattwiremjw@mjwconsult.co.ukMETA Token improvements (TokenProcessor)For quite a long time there has been a newer "TokenProcessor" in CiviCRM core, but it was only implemented for scheduled reminders initially. It can be used with this branch of the emailapi extension: https://lab.civicrm.org/mattwire/em...For quite a long time there has been a newer "TokenProcessor" in CiviCRM core, but it was only implemented for scheduled reminders initially. It can be used with this branch of the emailapi extension: https://lab.civicrm.org/mattwire/emailapi/tree/newtokenprocessor
Basically it is a more flexible token processor. @ayduns did a big chunk of work to implement activity tokens:
* https://github.com/civicrm/civicrm-core/pull/12012 - Add functionality to create PDF/Word docs from Activity searches
* https://github.com/civicrm/civicrm-core/pull/14662 - Add PDF letter functionality for Activities using new token processor
This part allows for more advanced "keyed" tokens so you can (for example) select a specific contact when there are multiple on an activity and supports activity PDFs:
* https://github.com/mattwire/civicrm-core/tree/activity_pdf_71_rebased
It would be good to extend to all token entities and we have a trait to help with that:
* ~~https://github.com/civicrm/civicrm-core/pull/16468 - REF Refactor ActivityTokens to use a trait that can be shared with other entities~~ merged
Draft PR for adding tokenprocessor support to contributions:
* https://github.com/civicrm/civicrm-core/pull/16612 - WIP Support contribution tokens using TokenProcessor
Support for Case tokens using tokenProcessor:
* https://github.com/mattwire/civicrm-core/tree/casetokenprocessor
There is some work that needs to be done to improve consistency and make development of the TokenProcessor easier. Reviewers are needed for:
* https://github.com/civicrm/civicrm-core/pull/16983 - Standardise what we pass to tokenProcessor so we don't have to add specific handling in each class for actionSchedule
* https://github.com/civicrm/civicrm-core/pull/18612 - Simplify TokenProcessor codehttps://lab.civicrm.org/dev/core/-/issues/1613updating misleading labels on buttons to confirmation pages2023-06-20T23:09:15Zyosefromanoupdating misleading labels on buttons to confirmation pagesOn contribution forms, the button leading to the confirmation page (if enabled) says 'confirm payment' which in many cases makes the user think that clicking the button submits the contribution.
On event forms, the button leading to th...On contribution forms, the button leading to the confirmation page (if enabled) says 'confirm payment' which in many cases makes the user think that clicking the button submits the contribution.
On event forms, the button leading to the confirmation page (if enabled) says 'continue' which again in many cases is misconstrued to mean 'continue and complete'
I get constant feedback from at least 50 different sites that their constituents are leaving the form before submitting it because they assume it was submitted leading to loss of revenue.
From looking at all shopping websites the industry standard with buttons leading to confirmation pages seems to be to use the word 'review'
The proposed solution in both cases is that the button label should simply say 'Review'.5.25.0https://lab.civicrm.org/dev/core/-/issues/1612Extension life-cycle bug for managed entities of a type declared in the exten...2023-02-22T05:03:55ZMichael McAndrewExtension life-cycle bug for managed entities of a type declared in the extensionLets say I have an extension that defines a new **entity type** Ocean.
And also declares some Oceans as **managed entities** (Atlantic, Pacific).
When I install it, everything works nicely. The managed oceans are created.
But when I d...Lets say I have an extension that defines a new **entity type** Ocean.
And also declares some Oceans as **managed entities** (Atlantic, Pacific).
When I install it, everything works nicely. The managed oceans are created.
But when I disable it, I start to experience problems because (I presume) attempts to manage the oceans are happening after CiviCRM no longer knows what an ocean is.
Proposed solution: ensure that entity types defined by disabled extensions are always available during attempts to manage entities.https://lab.civicrm.org/dev/core/-/issues/1607QuickSearch should search any details rather than primary details only2023-02-18T05:03:18ZmfbQuickSearch should search any details rather than primary details onlyOverview
----------------------------------------
QuickSearch currently searches primary details only. However, in all use cases I have encountered, users actually want to search any details (e.g. when searching by email address, see a l...Overview
----------------------------------------
QuickSearch currently searches primary details only. However, in all use cases I have encountered, users actually want to search any details (e.g. when searching by email address, see a list of contacts with that primary or non-primary email address).
If in fact there exists a use case where Civi users need to search primary details only, we could add a toggle to the QuickSearch form itself (which affects only that form interaction, and will not have side effects on exports, other users, etc.)
Example use-case
----------------------------------------
1. Use QuickSearch form to search by email, phone, address, etc.
1. Observe the autocomplete search results which appear below the QuickSearch box.
Current behaviour
----------------------------------------
Autocomplete shows results for primary details only.
Proposed behaviour
----------------------------------------
Autocomplete shows results for both primary and non-primary details.
Comments
----------------------------------------
In addition, it would be useful if QuickSearch could pass on the "search primary details only" preference to the advanced search page it leads to, so that the autocomplete results match the results obtained by hitting "enter".https://lab.civicrm.org/dev/core/-/issues/1599Deceased Contact via Inline doesn't update the Membership's status to Deceased2024-03-15T14:45:54ZGhost UserDeceased Contact via Inline doesn't update the Membership's status to DeceasedOverview
----------------------------------------
Editing a Contact via Inline to update it to Deceased doesn't update the status of the Membership automatically to Deceased.<br />
Checked in dmaster.
![Inline](/uploads/45fb6021711d8f2e...Overview
----------------------------------------
Editing a Contact via Inline to update it to Deceased doesn't update the status of the Membership automatically to Deceased.<br />
Checked in dmaster.
![Inline](/uploads/45fb6021711d8f2e15535832dbc4e888/Inline.png)
Reproduction steps
----------------------------------------
1. Create a new Contact.
2. Create a Membership in that Contact.
3. Edit the demographics of the contact via Inline and put it deceased.
Current behaviour
----------------------------------------
If you edit the Contact **via Inline**, the Membership **is not updated** to Deceased.
If instead of Inline you edit the Contact, the Membership **is updated** to Deceased.
Expected behaviour
----------------------------------------
The Membership status should be **updated automatically** to Deceased when editing the Contact **via Inline**.https://lab.civicrm.org/dev/core/-/issues/1590Scheduled reminder: "Additional recipients" receive reminders under circumsta...2023-12-01T05:03:19ZJonGoldScheduled reminder: "Additional recipients" receive reminders under circumstances where they ought not toThis is a superset of event#28. The issue seems to be more generalized than I'd realized.
"Additional recipients" will receive reminders on events (and presumably other entities) that have been deleted. To test:
* Create a scheduled r...This is a superset of event#28. The issue seems to be more generalized than I'd realized.
"Additional recipients" will receive reminders on events (and presumably other entities) that have been deleted. To test:
* Create a scheduled reminder for an existing event.
* Under *Limit or Add Recipients*, select **Also Include** and add a group or contact(s).
* Delete the event.
* Run the scheduled reminders job.
**Expected result**
No scheduled reminder.
**Actual result**
Scheduled reminder to the "additional recipients".
### Why it happens
Scheduled reminder recipients are decided in two passes. First, whomever qualifies by the "normal" criteria (e.g. event participants) and a second pass for anyone in "Additional Participants".
The first pass is specific to the type of reminder (event, membership, contribution); the second is the same code regardless. This caused event#28; the "additional recipients" pass, by virtue of not being event/membership/etc-specific, wasn't aware that events have the special case of templates, which other entities don't. It also doesn't check for deleted entities.
The solution is to add a new method to the `Civi\ActionSchedule\MappingInterface` interface - a `sendToAdditional` method that returns a boolean. Then, each class that implements this interface can abort the "additional recipients" pass in an entity-specific way. Besides deleted entities and event templates, contributions have templates as well now, so we should check for that.