CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-05-27T17:14:31Zhttps://lab.civicrm.org/dev/core/-/issues/3920Update backend footer2023-05-27T17:14:31ZlarsssandergreenUpdate backend footerThe footer shown to backend users seems like it could be improved a bit:
![image](/uploads/3c4361fd529cf3ec27872a3a10660f81/image.png)
I think that bottom line could just be:
[Support](https://civicrm.org/help) [Documentation](http...The footer shown to backend users seems like it could be improved a bit:
![image](/uploads/3c4361fd529cf3ec27872a3a10660f81/image.png)
I think that bottom line could just be:
[Support](https://civicrm.org/help) [Documentation](https://docs.civicrm.org/)
Download is covered in the version number, which is also a download link. Support is a much more useful link that leads to options: Stack Exchange, chat, Gitlab, etc. rather than just Gitlab, which is probably not the right first stop for someone with a problem, in most cases.
Alternatively, support and documentation are covered in the top menu. Maybe there is no need for a second line at all?
Minor detail: Add a space between the status box and the word CiviCRM.5.63.0https://lab.civicrm.org/dev/core/-/issues/3893Searchkit: Change Rewrite field to textarea2023-11-15T14:51:59ZshaneonabikeSearchkit: Change Rewrite field to textareaHey there,
After realizing that we can use SMARTY conditions in Searchkit this really took one of our clients systems to an entire new level. Thanks so much for all the hard work on Searchkit!
## Problem
Presently, the Searchkit Rewri...Hey there,
After realizing that we can use SMARTY conditions in Searchkit this really took one of our clients systems to an entire new level. Thanks so much for all the hard work on Searchkit!
## Problem
Presently, the Searchkit Rewrite field is a textfield, which is fine if you want to append a few characters to the end or before a value. It gets extremely hard to read and also modify (I have to use a texteditor beside) to modify if you start using SMARTY attributes.
In the situation below, we are generating one column that contains one of two values using a SMARTY ```if```.
![Selection_001](/uploads/57432093e023009c9b311a77f1fe00eb/Selection_001.png)
to generate
![Selection_002](/uploads/1a87132c9a0e9ce080c8e9bd2418c5ea/Selection_002.png)
## Proposed solution
Would it be difficult to modify this field to a textarea instead? It would make it much easier to modify and read. I really don't know if this would be a massive change but I think it would really help. Also, we could provide a help icon to inform people that they can use SMARTY in these fields as long as they put quotes around the different values being retrieved (this was the element I was missing when I first tried and didn't get it working.
![Selection_003](/uploads/10973172b4588429613fbc87616ea879/Selection_003.png)5.56.0https://lab.civicrm.org/dev/core/-/issues/3628Add pre/post hook for CRM_Mailing_BAO_MailingJob2022-06-15T11:19:25ZMonish DebAdd pre/post hook for CRM_Mailing_BAO_MailingJobThis ticket is about adding pre, post hook to MailingJob and it involve:
1. Call the pre/post hook inside `CRM_Mailing_BAO_MailingJob::create()`
2. Add `CRM_Mailing_BAO_MailingJob::deleteMailingJob` to delete Mailing Jobs and add pre/pos...This ticket is about adding pre, post hook to MailingJob and it involve:
1. Call the pre/post hook inside `CRM_Mailing_BAO_MailingJob::create()`
2. Add `CRM_Mailing_BAO_MailingJob::deleteMailingJob` to delete Mailing Jobs and add pre/post delete hook
3. Replace all the DAO call with corresponding create and delete fn in the codebase.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3533Rewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.2024-02-09T05:03:20ZtottenRewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`...## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`, `extern/rest.php`, or `extern/cxn.php`. More broadly, *all test suites and CLI processes* use a standalone bootstrap script. (These entry-points are distinct from the front-end entry-points typically associated with the UI.)
There are a number of technical details and happenstance we can go into, but there are two fundamental nubs in writing and executing a standalone script:
* *It doesn't know which CMS is active.* There's usually some *hard-coding* to the find the CMS.
* *Bootstrapping the CMS adds overhead.* Many admins have written-off this consideration as cost of doing business - but for someone, somewhere, at some point it mattered.
## Background: `civicrm.config.php` protocol
The original protocol for standalone bootstrap originated many years ago (circa 1.x or 2.x?). It's still used in several cases. It's key design elements:
* `civicrm.config.php` is *generated* at build-time to match the CMS. The tarball/zipball for each CMS includes a different build of this file. It's main purpose is to locate `civicrm.settings.php`.
* `civicrm.settings.php` includes a `define` for the `CIVICRM_UF` (among many others).
* `CRM_Utils_System::*` includes functions like `loadBootStrap()`.
* __Original protocol__: A standalone script would include `civicrm.config.php`, which would locate the `civicrm.settings.php` using a CMS-specific search. It then boots Civi by loading `civicrm.settings.php` and calling `CRM_Core_Config::singleton()`. Optionally, it also boots the CMS by calling `CRM_Utils_System_*::loadBootStrap()`.
The original boot protocol has some major consequences -- for example:
1. It requires creating an extra settings file (`civicrm.settings.php`) on every build.
2. Depending on how the page-load starts, the Civi settings file and CMS settings may load in different orders. It's not valid to infer Civi settings based on CMS settings (and vice-versa).
3. You need to figure the *absolute or relative* path of `civicrm.config.php`. This is *possible* in `civicrm-core` -- but it's basically impossible with any other publishable deliverable.
4. Reading/understanding the boot protocol requires having multiple builds of Civi (one for each CMS) -- *that's the only way to see each version of `civicrm.config.php`.
## Background: `cv` bootstrap protocol
A few years ago, I combined the various `civicrm.config.php` files with the aim of producing a universal boot script that solved `#3` and `#4`. This produced https://github.com/civicrm/cv/blob/master/src/Bootstrap.php which eventually became the heart of the `cv` command. This endeavor preserved a bunch of assumptions from the original protocol... but it made a key change: *dynamically discovering* the boot info.
The dynamic discovery works a bit like this:
* Do a file-system search (from PWD) to figure out the CMS.
* Do a file-system search (from CMS dir) to figure out where `civicrm.settings.php` is.
* Unless... you really want a faster bootstrap. Then you can set an environment variable with your boot info (and bypass the searches).
IMHO, dynamic CMS discovery (with optional env-var for optimization) is a pretty good way to make the code more robust to deploying in a variety of environments and file-structures.
There's just one problem: the *implementation* grew out of `civicrm.config.php` and kept some of the assumptions, so the implementation still shares issues `#1` and `#2`.
## Proposal: Provide a universal, CMS-first bootstrap script -- and knock over some dominoes
The basic idea is to write a CLI helper which bootstraps the CMS first -- and then bootstraps Civi. The logic is roughly:
```php
function boot($startDir) {
$parentDirectories = array($startDir, parent($startDir), grandparent($startDir), ...);
foreach ($parentDirectories as $dir)
if ($dir has Drupal) { bootDrupal(); bootCivi(); return; }
elseif ($dir has Joomla) { bootJoomla(); bootCivi(); return; }
elseif ($dir has WordPress) { bootWordPress(); bootCivi(); return; }
elseif ($dir has Backdrop) { bootBackdrop(); bootCivi(); return; }
}
}
```
This helper still provides standalone bootstrap, so we can still have all our standalone scripts/unit-tests/commands/etc. But it makes a fundamental change:
* **You can always rely on having the CMS bootstrapped first**.
* Therefore, you can detect things like `CIVICRM_BASEURL` using CMS API's -- because they're always available.
* Therefore, you don't need `civicrm.settings.php` to store those settings.
* Therefore, you don't need `install/index.php` to create `civicrm.settings.php`.
* Therefore, you don't need write-access to create `civicrm.settings.php` (in the typical case).
* Therefore, you don't need to migrate or preserve `civicrm.settings.php` (in the typical case).
*Note: Of course, the entire CiviCRM install-base currently uses `civicrm.settings.php`, and some of them use it to accomplish special ends (like custom multidomain/multisite/multitenant arrangements). Therefore, I wouldn't argue for complete removal of the file -- but, instead, it should be an optional/advanced thing.*
## General Tasks
* Write the new bootstrap script.
* Phase-in the new bootstrap script for use by `cv` and `civicrm-core`.
* Update `civicrm-core` to compute values for all those constants (`define('CIVICRM_FOO',...)`) at runtime using CMS functions.
* Update the installer to omit `civicrm.settings.php`
* Update docs to describe the advanced/optional use of `civicrm.settings.php`.https://lab.civicrm.org/dev/core/-/issues/3529Does CiviCRM work well with database replication and clustering?2022-06-11T14:44:13ZdavejDoes CiviCRM work well with database replication and clustering?There have been a few discussions on Mattermost in recent months in which people have described problems running Civi in replicated / cluster environments. In particular, Civi's use of temporary tables has caused issues. E.g.
10 Oct 20...There have been a few discussions on Mattermost in recent months in which people have described problems running Civi in replicated / cluster environments. In particular, Civi's use of temporary tables has caused issues. E.g.
10 Oct 2017 eileen:
> We have been having some replication lag issues & one metric we are investigating is the slaves (only) seem to show a large number of open temp tables on one metric. The odd thing about the replication lag is it seems to get worse the longer since a server restart (presumably just the mysql part needs to be restarted).
10 Oct 2017 jackrabbithanna:
> Ok we're dealing with Percona DB
>
> Database Error Code: Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions., 1787
>
> followed by a php error: Fatal error: Uncaught CRM_Core_Exception: [0: Transaction integrity error: Expected to find active frame thrown
>
> Per https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-restrictions.html the multi-statements transactions are not allowed as they could potentially run using the same global transaction ID (GTID)
>
> this error happens when trying to create a Drupal user, with CiviCRM profile on the form
Further comments from Eileen:
> OK - I'll have a read of that - the CiviCRM usage of temp tables is pretty common & in particular ties in with the way mailing recipients are calculated & rolled back. However, I'm also reading concerns that replicated DBs don't like temp tables (although it's not blocked in the version we have)
>
> (we use mixed mode replication)
>
> I think it's kind of a big picture question isn't it? I had thought to move all temp table creations to a single function (so if we want to do something different we can do it in there) - the thing is a lot of them are used to calculate group_contact_cache & those will cause rollback to fail
> "A recommended practice when using statement-based or mixed-format replication is to designate a prefix for exclusive use in naming temporary tables that you do not want replicated, then employ a --replicate-wild-ignore-table option to match that prefix. For example, you might give all such tables names beginning with norep (such as norepmytable, norepyourtable, and so on), then use --replicate-wild-ignore-table=norep% to prevent them from being replicated." - we could at least do that for reports etc
> if you are using statement based replication or mixed replication then any temp tables used to build real tables have to be replicated
>
> or else the query will fail on the slave
> it's an improvement basically 'make civicrm support replication'
> it does work with replication but I think that's more because various people have just configured it to do so
>
> but I don't think there has ever been any official support for that or effort to understand the design implications
13 Oct eileen:
> ... our replication issue DOES seem to be related to the temp tables created for civimail at this stage. ... What we are seeing is the DROP statement is written to the binlog BEFORE the create statement is - somewhat in line with https://www.xaprb.com/blog/2007/01/20/how-to-make-mysql-replication-reliable/
>
> (not really clear from there but it says "As I mentioned, each transaction goes into the binlog in the order in which it commits, not in the order in which it is started, so transactions may execute in a different order on the replica. ")
>
> the binlog is parsed on the slaves & they temp tables mount up
>
> not 100% sure if this will solve all our woes - but not letting civicrm use temp tables to create recipient lists seems to be important
We ran a bunch of Civi sites with MySQL replication several years ago and had a lot of problems with it: replication would fall over periodically and then everything would grind to a near standstill as it was re-sync'd.
As a starting point, it would be useful to gather some data on how many people use replication / clustering with Civi, how frequently problems are encountered, what the most common problems are and whether they have been solved.https://lab.civicrm.org/dev/core/-/issues/3520Proposal: Splitting up delete contacts permission / new permission "CiviCRM s...2024-03-03T05:03:25ZAndreasandreas.howiller@civiservice.deProposal: Splitting up delete contacts permission / new permission "CiviCRM soft delete contacts"?Overview
----------------------------------------
Currently CiviCRM already has a distinction between soft deletion and permanent deletion of contacts: With the permission _CiviCRM: delete contacts_ you're able to put a contact into the ...Overview
----------------------------------------
Currently CiviCRM already has a distinction between soft deletion and permanent deletion of contacts: With the permission _CiviCRM: delete contacts_ you're able to put a contact into the trash bin. Users with the additional permission _CiviCRM: access deleted contacts_ can then permanently delete these contacts. In many usecases this is fine – e.g. when you might just want to prevent temporary volunteer workers from accidently deleting contacts permanentely. However there are very common use cases where an explicit distinction between a soft and a hard delete permission would be needed:
Example use-case 1: Allow restoring but _not_ (hard) deleting contacts
----------------------------------------
Your're glad your temporary volunteers help taking care of your contacts. And you feel safe allowing them (soft) deletion, too, as you're happy with the fact that only a few of your colleagues have the permission to delete these contacts permanently. What you would also like, however, is for them to be able to view and restore the deleted contacts to fix mistakes.
Current behaviour
----------------------------------------
When you allow users to soft delete contacts and to view the bin to restore contacts, this combination also allows permanently deleting contacts.
Proposed behaviour
----------------------------------------
In combination with a new permission _CiviCRM: soft delete contacts_ the permission _CiviCRM: access deleted contacts_ would allow this use case.
It seems like there had been a workaround for that around the permission _CiviCRM: edit all contacts View, Edit and Delete ANY CONTACT in the CiviCRM database_ which is not working anymore ([see this discussion on StackExchange](https://civicrm.stackexchange.com/questions/42008/allow-deletion-of-contacts-but-not-in-trash)).
Example use-case 2: Allow deduplication but _not_ (hard) deleting contacts
----------------------------------------
You deal a lot with event submissions and imports, so deduplication is very important for you. That is why you want your team to be able to deduplicate and also to fix mistakes by looking in the trash. But you don't want everybody to delete contacts in trash.
Current behaviour
----------------------------------------
Same like in use-case 1 except that even the broken workaround mentioned there would not work here as _CiviCRM: merge duplicate contacts_ requires the delete contacts permission.
Proposed behaviour
----------------------------------------
In combination with a new permission _CiviCRM: soft delete contacts_ the permissions _CiviCRM: merge duplicate contacts_ plus _CiviCRM: access deleted contacts_ would allow this use case.
Comment
----------------------------------------
Since this would mean touching a basic thing and might have some unexpected consequences in practice or in code (I'm not a developer) a broader discussion would be great :-)https://lab.civicrm.org/dev/core/-/issues/3180Import contributions, memberships etc - usefulness of contact type...2023-01-31T04:38:32ZeileenImport contributions, memberships etc - usefulness of contact type...When importing contributions, memberships etc there is an option to select the contact type.
On digging into the code I think it only makes sense to specify contact type if
1) you are matching by email and
2) you specifically want to on...When importing contributions, memberships etc there is an option to select the contact type.
On digging into the code I think it only makes sense to specify contact type if
1) you are matching by email and
2) you specifically want to only import to a contact of a particular type.
If you are giving the contact_id or external_identifier it makes sense that we make to whatever type we find (this also saves from having to do multiple uploads if there is a mix of types).
However, I can see that with email it makes sense that there are both organizations and individuals with that email and you want it to choose the organization.
I propose that we make the field optional and ONLY validate for emails (if set)
![image](/uploads/67ada1ec273c176a6f974cab6d846bf9/image.png)https://lab.civicrm.org/dev/core/-/issues/3003Preserve previous tab when navigating to and from contact page2022-05-05T14:57:50ZBradley TaylorPreserve previous tab when navigating to and from contact pageThe contact page is structured around a series of tabs: Summary, Contributions, Membership etc. There are often times when you click through from a contact to a related entity (say a related contact from the relationships tab). It would ...The contact page is structured around a series of tabs: Summary, Contributions, Membership etc. There are often times when you click through from a contact to a related entity (say a related contact from the relationships tab). It would be nice if using the browser's back button returned you to the tab you were previously looking at rather than returning to the summary tab each time.
This is a bigger issue for users with the "Enable Popup Forms" option unticked, but all users are affected by this.
This shouldn't be a massive technical change, but I do think this is one of those little annoyances, where fixing should improve the overall usability of the CRM for those who need to use it on a daily basis.
**Implementation details**
It is already possible to link to a specific tab with the `selectedChild` query parameter. I propose that whenever the active tab is changed, the [replaceState](https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState) API is used to amend the `selectedChild` parameter in the URL.5.49.0https://lab.civicrm.org/dev/core/-/issues/2887ical/ics files generated by Civi are not compatible with Outlook during Dayli...2023-12-13T15:33:23ZStoobical/ics files generated by Civi are not compatible with Outlook during Daylight SavingsOverview
----------------------------------------
Since the inclusion of timezone in the ical/ics files that CiviCRM produces RFC5545 timezone is technically correct but Outlook doesn't interpret them properly
Reproduction steps
-------...Overview
----------------------------------------
Since the inclusion of timezone in the ical/ics files that CiviCRM produces RFC5545 timezone is technically correct but Outlook doesn't interpret them properly
Reproduction steps
----------------------------------------
1. during daylight savings (until Nov 7 in this year, 2021) create an event
2. download the ics/ical file from the event 'info' page
3. open that ics/ical file in Outlook
4. notice that it is one hour forward (later) than should be
Commentary
----------------------------------------
Hi guys, I wanted to make you aware of a new twist on this issue since timezones were added to the Civi-generated ical/ics files. Good news and bad, but wanted to share my research.
Good news: timezones are good, and as you know ical/ics from Civi didn't have them until 5.37.
Bad news: timezone glitches in Outlook.
The standards are meticulous but illustrate the format here: https://icalendar.org/iCalendar-RFC-5545/3-8-3-1-time-zone-identifier.html and the TZ zones can be clearly seen here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
How does this relate to Outlook, might you ask? Good question. Well I scoured the internet and people unrelated to CiviCRM have reported issues with timezone discrepancies in Outlook....
- As far back as 2016: https://theeventscalendar.com/support/forums/topic/ical-timezone-issue-with-microsoft-outlook
- And as recently as 2019: https://answers.microsoft.com/en-us/msoffice/forum/all/outlook-cant-read-timezone-in-ics-file-a-slew-of/495cadf9-4630-48b5-99ce-88d94980f289
... what these tend to have in common is that the discrepancies happen during Daylight Savings, which we are in right now, and which ends Nov 7. And they all have to do with ical/ics files that use a format of "America/New_York" whereas Outlook uses a different naming convention.
But how does this relate to CiviCRM? An even better question. Prior to version CiviCRM 5.37 which was released in June, CiviCRM ical/ics files had NO timezone at all, here: #19762 I never knew this. Lack of timezone caused problems of its own, but with most folks who are in the same timezone it doesn't matter.
When I made a mandatory security update to 5.38 CiviCRM a few months ago, the problems surfaced for a large nonprofit organization that uses primarily Outlook. That is because although CiviCRM now creates its ical/ics file to the RFC5545 standard, Outlook does not (attached). And now that CiviCRM is putting in timezones, we notice the issue for the first time...but only in Outlook. In one of the above posts it clearly states that Outlook misinterprets America/New_York in Daylight Savings.
So all that to say this is where we stand, between a rock and a hard place, metaphorically but perhaps even literally getting Microsoft to change their software might be like moving a mountain. And CiviCRM, well-meaning though we may be, may not want to accommodate a change to Civi that doesn't meet standards.
Solution ?
--------------------------------
There might be an exception or compromise in this mess, but it will more likely be on the CiviCRM side. Originally detected by agilware on this repo: https://github.com/civicrm/civicrm-core/pull/19762
![comparison](/uploads/8ef08e1138430a9793a18ad7966581f3/comparison.png)
[outlook-created.ics](/uploads/dee2cccb0c4a19b61ff106cb54f8ee5a/outlook-created.ics)5.52.2justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/2866Start phasing out 'preferred_mail_format'2024-02-27T05:03:24ZeileenStart phasing out 'preferred_mail_format'Preferred mail format was the idea of sending a message in html or text or both depending what you knew about their preferrences. However, mostly this is an email client setting - you send both and the client deals with it.
We actually ...Preferred mail format was the idea of sending a message in html or text or both depending what you knew about their preferrences. However, mostly this is an email client setting - you send both and the client deals with it.
We actually invest quite a lot of code & unnecessary queries into this feature & when it came up there was general support for removing it. I also included it in the dev digest on 12 Sep 2021 - so I think we are a couple of emojis away from concept approval on this
https://github.com/civicrm/civicrm-core/pull/21426#pullrequestreview-751423307https://lab.civicrm.org/dev/core/-/issues/2755Proposal: add `civicrm_contact.image_file_id` column2023-04-20T00:24:59ZcolemanwProposal: add `civicrm_contact.image_file_id` columnProblem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_...Problem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_contact.image_URL` column with a link to an ajax callback for accessing the image.
3. Not create a record in the `civicrm_file` table.
4. Not create a record in the `civicrm_entity_file` table.
**Deleting a contact image in the UI will:**
1. Not delete the file.
2. Set `civicrm_contact.image_URL` to `null`.
Proposed New Behavior
-------------------
*Add a `civicrm_contact.image_file_id` column, FK to `civicrm_file.id`.*
**Uploading a contact image will:**
1. Store the file as before.
2. Update the `civicrm_contact.image_URL` column as before.
3. Create a record in the `civicrm_file` table.
4. Store the file id in the `civicrm_contact.image_file_id` column
5. *Undecided:* should an entry also be created in `civicrm_entity_file`? See #2760
**Deleting a contact image in the UI will:**
1. Delete the file if an id is present in `image_file_id` column.
2. Set `civicrm_contact.image_URL` and `civicrm_contact.image_file_id` to `null`.
See PR https://github.com/civicrm/civicrm-core/pull/21141https://lab.civicrm.org/dev/core/-/issues/2521Hidden smart group does not update when mailing is sent or opened unless smar...2022-10-03T04:18:08ZlarsssandergreenHidden smart group does not update when mailing is sent or opened unless smart group cache clearedWhen you create a mailing to send to a set of contacts from search results, this is displayed as a "hidden smart group". However, this group is just a set of contacts that you select, not actually a smart group (i.e. it does not update b...When you create a mailing to send to a set of contacts from search results, this is displayed as a "hidden smart group". However, this group is just a set of contacts that you select, not actually a smart group (i.e. it does not update based on the search terms used). One of our staff members had been assuming that it would update as it is a "smart group". Maybe smart group makes sense from the backend, but for a user, it is confusing to use smart group when it is actually not a smart group in the sense that matters.
I propose changing this to "hidden group".
I believe the text should be changed [here.](https://github.com/civicrm/civicrm-core/blob/96f9e1a5ccb2774bb3cc8899ce52b69e11e82c9c/CRM/Contact/BAO/Group.php#L712)
EDIT: Changed title to reflect discussionhttps://lab.civicrm.org/dev/core/-/issues/2384Remove text about email receipts for each recurring contribution.2021-03-19T21:23:23ZlarsssandergreenRemove text about email receipts for each recurring contribution.On a contribution page, when you select a recurring contribution, this is part of the message that appears: "You will receive an email receipt for each recurring contribution" if [email receipt is enabled for the contribution page.](http...On a contribution page, when you select a recurring contribution, this is part of the message that appears: "You will receive an email receipt for each recurring contribution" if [email receipt is enabled for the contribution page.](https://github.com/civicrm/civicrm-core/blob/e4c693f6e2114a1f536d406d2ef107fc56e7952c/CRM/Core/Payment.php#L596)
I'm sure we're not the only org that sends an email receipt for the first recurring contribution through the contribution page, but doesn't send a receipt for every contribution, making this text inaccurate. It would also be incorrect if a donor isn't entering an email address.
From the perspective of the person filing out the form, I'm not sure whether or not they'll receive an email receipt for every contribution is necessary information. My suggestion is to remove this sentence. I think this kind of information makes sense in an email receipt (where it is also more easily editable) rather than on a contribution page.
I would also suggest removing this sentence: "Your recurring contribution will be processed automatically." I think it is quite obvious that if someone is making a recurring contribution, it will be processed automatically.
If both these sentences were removed, then there is no additional text shown when someone makes a recurring contribution on a page where they can't select the number of instalments, which would be nice and simple.5.37.0https://lab.civicrm.org/dev/core/-/issues/2184OAUTH2 google doesn't seem to give you refresh tokens easily2023-06-15T01:11:27ZDaveDOAUTH2 google doesn't seem to give you refresh tokens easilyIf you run the authorization_code flow to obtain an access token from google I find the response often doesn't contain a refresh token, so then it can't really be used for cron jobs.
There was some suggestion that you have to delete the...If you run the authorization_code flow to obtain an access token from google I find the response often doesn't contain a refresh token, so then it can't really be used for cron jobs.
There was some suggestion that you have to delete the token in the civi admin AND at google. This [issue](https://github.com/googleapis/google-api-python-client/issues/213#issuecomment-612412147) suggests it only gives a refresh token when you are prompted for consent and not subsequent times (or if you pass the prompt=consent parameter).
It may only come up as a problem during a testing cycle where you keep failing and re-requesting, and for people who are setting up an account and get it right the first time it won't be a problem.
TBD5.64.0https://lab.civicrm.org/dev/core/-/issues/2155Remove 'onlinePendingContribution' payment support from membership edit form2020-11-16T20:05:33ZeileenRemove 'onlinePendingContribution' payment support from membership edit formI want to proposed removing support for 'onlinePendingContribution' from the Membership Edit form.
**What is onlinePendingContribution support you ask?**
It's this box on the membership edit form
![Screen_Shot_2020-10-31_at_6.30.02_PM]...I want to proposed removing support for 'onlinePendingContribution' from the Membership Edit form.
**What is onlinePendingContribution support you ask?**
It's this box on the membership edit form
![Screen_Shot_2020-10-31_at_6.30.02_PM](/uploads/10211382f41b9d0fe92362f620e68d6e/Screen_Shot_2020-10-31_at_6.30.02_PM.png)
**Hey but I've never seen that box!**
Well you only see if if someone has created a pending pay later membership through an online form which you later complete through the membership edit form
**And it allows you to send a customised receipt?**
No, it says you can, you can't
**How else would someone complete that contribution?**
Well - they could do it the same way they would for a pending contribution created in any other way - use the link a moment further down the page
![Screen_Shot_2020-10-31_at_6.27.20_PM](/uploads/3e29866a816528a9265a26a852aa73de/Screen_Shot_2020-10-31_at_6.27.20_PM.png)
**And why do you want to remove it**
There is considerable code complexity needed to support it - about 85 lines of code. Oh, and it's broken in master
**But how do we know no-one is using it**
Well I tested on 5.21 & it's broken there too so my guess is is has broken for a long time....5.33.0https://lab.civicrm.org/dev/core/-/issues/2137Asset building breaks the site2021-03-10T23:23:22ZAlanDixonAsset building breaks the site## NOTE:
This ticket is not about how to solve this problem, which has some known causes and some unknown causes, it was just about logging instead of crashing. Check your civi log (ConfigAndLog) or visit https://civicrm.stackexchange.co...## NOTE:
This ticket is not about how to solve this problem, which has some known causes and some unknown causes, it was just about logging instead of crashing. Check your civi log (ConfigAndLog) or visit https://civicrm.stackexchange.com/questions/37994/why-cant-the-asset-builder-find for help solving the problem.
## Description:
Upon upgrade of a Drupal 8 site to CiviCRM 5.30.1 from 5.29.something, the site broke completely with this php error in the drupal watchdog:
`Civi\Core\Exception\UnknownAssetException: Unrecognized asset name: crm-menubar.css in Civi\Core\AssetBuilder->render() (line 217 of /var/www/drupal/vendor/civicrm/civicrm-core/Civi/Core/AssetBuilder.php).`
Missing assets shouldn't break the site.5.36.0https://lab.civicrm.org/dev/core/-/issues/1987Fix theme configuration section on Display preference and improve `isFrontend...2020-10-14T01:27:41Zswastik-compucorpFix theme configuration section on Display preference and improve `isFrontendPage` function for Drupal CMSProblem Motivation
----------------------------------------
While working on the Drupal web-forms, when we are using CiviCRM fields (like payment processors) on the Drupal webform pages, the CiviCRM current theme JS and CSS files were le...Problem Motivation
----------------------------------------
While working on the Drupal web-forms, when we are using CiviCRM fields (like payment processors) on the Drupal webform pages, the CiviCRM current theme JS and CSS files were leaking (rendering) on the Drupal webform page. This was making the page styling more difficult as one has to first reset the leaking CSS and then style on top of them. Also, there were some bootstrap JS libraries (when Shoreditch is the CiviCRM) file which was loading on the page. So, if a developer wants to develop a bootstrap based Drupal 7 themes and try to style the CiviCRM components, the Shoreditch bootstrap JS files conflicts with Drupal 7 bootstrap theme JS files.
To fix this we had to find a way to stop CiviCRM to apply its theme assets. The best way of it is to find a way in CiviCRM which will contextually select/deselect a CiviCRM theme on Drupal CMS pages. And apparently, the CiviCRM core provides such a feature under the display preference page to select different Front-end and Back-end theme. Unfortunately, this feature was not for Drupal CMS and hence the issue.
Problem Overview
----------------------------------------
For the Drupal CMS, the CiviCRM doesn't provide separate configurations for setting the frontend theme (FE) and the backend theme (BE). This is however present for other CMS integrations
For Drupal, on the Display Preference page, we only have one option for setting the global theme and it sets the BE only and the user can only set the BE.
![3ffa703e-9774-4224-abb0-c967b809dbef](/uploads/821e12db022a5accb4c5d8f7d8063ae3/3ffa703e-9774-4224-abb0-c967b809dbef.png)
The problem with this is that the Drupal User couldn't set the front end theme and the backend theme separately. So, to fix this we remove [the extra if logic](https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Admin/Form/Preferences/Display.tpl#L210-L225) just for Drupal CMS which hides the configuration for the FE-theme and BE-theme and loads the configuration for drupal as well. This will print both the configuration fields.
![3403e6d0-6a80-4e20-ac50-bd24190cc858](/uploads/d9efbd1d109e2bb15b0938debda8e32e/3403e6d0-6a80-4e20-ac50-bd24190cc858.png)
Also, the CiviCRM theme CSS was leaking on drupal pages too which uses the CiviCRM fields (and in turn called `civicrm_initialise()` function). This is because `$config->userSystem->isFrontEndPage()` function is buggy for Drupal CMS as it return `false` if the user opens a drupal public page. This is because [`isFrontEndPage()` function ](https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System/DrupalBase.php#L658-L664))doesn't take care of the corner case of page URLs which are not CiviCRM's one. As it only checks if the URLs is a CiviCRM public URL
```
$item = CRM_Core_Menu::get($path);
// What if `$item` is empty?
return !empty($item['is_public']);
```
If `$item` is empty (that means it's a non-CiviCRM page) even then it returns `false` because the logic is incomplete. It doesn't check if the `$item` is empty.
This [fix](https://github.com/civicrm/civicrm-core/pull/18322) addresses both these issues.
Example use-case
----------------------------------------
1. Click on **Administration -> Customise data and screens -> Display preference**.
2. Go to `Theme` section
Current behaviour
----------------------------------------
![3ffa703e-9774-4224-abb0-c967b809dbef](/uploads/821e12db022a5accb4c5d8f7d8063ae3/3ffa703e-9774-4224-abb0-c967b809dbef.png)
Proposed behaviour
----------------------------------------
![3403e6d0-6a80-4e20-ac50-bd24190cc858](/uploads/d9efbd1d109e2bb15b0938debda8e32e/3403e6d0-6a80-4e20-ac50-bd24190cc858.png)5.31.0https://lab.civicrm.org/dev/core/-/issues/1933Failed scheduled reminders should log message somewhere more useful2021-12-16T14:06:16ZAndy ClarkFailed scheduled reminders should log message somewhere more usefulOverview
----------------------------------------
A failed schedule reminder should log the error in a place that the end user can see why it failed.
Example use-case
----------------------------------------
A schedule reminder is set u...Overview
----------------------------------------
A failed schedule reminder should log the error in a place that the end user can see why it failed.
Example use-case
----------------------------------------
A schedule reminder is set up to send an SMS to a contact with a bad phone number. The reminder will fail, and a message will be added to table civicrm_action_log. The user who set up the reminder will not know whether it failed, or why, since they cannot view database tables.
Proposed behaviour
----------------------------------------
I propose a couple of alternatives:
1. The error message should be logged as an activity, either against the creator of the schedule reminder or the target. Then the user can check for this.
Or
2. The error message should be written to the system log, so at least someone with the 'Log Viewer' extension could see it.
Comments
----------------------------------------
My preference would be the first of the alternatives. There are a number of questions on SE about analysing failed Schedule Reminders - this would be a help with that.5.46.0https://lab.civicrm.org/dev/core/-/issues/1863System check severities out of whack2023-09-08T02:20:40ZAndie HuntSystem check severities out of whackThe severities for system checks are [defined in PSR-3](https://www.php-fig.org/psr/psr-3/#3-psrlogloggerinterface), and the first system checks attempted to match them pretty closely.
| Level | Description (per PSR-3) | Examples (per P...The severities for system checks are [defined in PSR-3](https://www.php-fig.org/psr/psr-3/#3-psrlogloggerinterface), and the first system checks attempted to match them pretty closely.
| Level | Description (per PSR-3) | Examples (per PSR-3) | What happens in CiviCRM |
| ------ | ----- | ----- | ----- |
| emergency | System is unusable. | | You'll never see it because the system won't be functioning. |
| alert | Action must be taken immediately. | Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up. | Red pop-up when an admin logs in; item has a red header. |
| critical | Critical conditions. | Application component unavailable, unexpected exception. | Red pop-up when an admin logs in; item has a red header. |
| error | Runtime errors that do not require immediate action but should typically be logged and monitored. | | Red pop-up when an admin logs in; item has a red header. |
| warning | Exceptional occurrences that are not errors. | Use of deprecated APIs, poor use of an API, undesirable things that are not necessarily wrong. | Orange pop-up when an admin logs in; item has an orange header. |
| notice | Normal but significant events. | | Item has a blue header. |
| info | Interesting events. | User logs in, SQL logs. | Item has a green header. |
| debug | Detailed debug information. | | Never displayed. |
However, over the years a few things have happened:
1. Some system checks have severities that don't quite match the specifications here, especially skewing too high.
2. System checks are used to nudge people to update their hosting environment for the future.
3. The system checks have become dominated by things that users don't quite understand.
4. Partners and others supporting lots of organizations have become frustrated that system checks scare or confuse users.
I see there being four main ways to address this:
1. Narrowing who sees the system check messages to only those who are in a position to act on them (through permissions or otherwise).
2. Giving more warning (through upgrade messages and a longer runway of escalating severity) for things that are not currently critical but will become so.
3. Improving the presentation of system check messages and how to snooze or hush them.
4. Doing a better job of giving a system check the right severity.
There's been discussion on the first and second items elsewhere. This ticket is focused on the fourth. Fundamentally, some things will be at the level of "drop everything and fix it", but we don't want to cry wolf.
Here are the existing system checks and their severities. My hope is that by having them all in the same place it will be easier to decide which are more severe than others. The ID column is just here to ease discussion.
| ID | Class | Title | Message | Severity |
| -- | ----- | ----- | ------- | -------- |
| 1 | CRM_Utils_Check_Component_AddressParsing | Street address parsing | Street address parsing is enabled but not supported by your locale | warning |
| 2 | CRM_Utils_Check_Component_Case | CiviCase | Case type "%1" has duplicate XML files ("%2" and "%3") | warning |
| 3 | CRM_Utils_Check_Component_Case | CiviCase | Case type "%1" corresponds to XML file ("%2") The XML file should be named "%3". | warning |
| 4 | CRM_Utils_Check_Component_Case | Timestamps for Activities and Cases | The tables "<em>civicrm_activity</em>" and "<em>civicrm_case</em>" were updated to support two new fields, "<em>created_date</em>" and "<em>modified_date</em>".... | notice |
| 5 | CRM_Utils_Check_Component_Case | Relationship Type Internal Name Duplicates | Relationship type <em>%1</em> has the same internal machine name as another type.... | error |
| 6 | CRM_Utils_Check_Component_Case | Relationship Type Display Label Duplicates | Relationship type <em>%1</em> has the same display label as another type. | error |
| 7 | CRM_Utils_Check_Component_Case | Relationship Type Cross-Duplication | Relationship type <em>%1</em> has an internal machine name that is the same as the display label as another type.... | warning |
| 8 | CRM_Utils_Check_Component_Case | Relationship Type Ambiguity | Relationship type <em>%1</em> appears to be unidirectional, but has the same internal machine name for both sides.... | warning |
| 9 | CRM_Utils_Check_Component_Case | Relationship Type Ambiguity | Relationship type <em>%1</em> appears to be unidirectional internally, but has the same display label for both sides.... | warning |
| 10 | CRM_Utils_Check_Component_Case | Missing Roles | The following roles listed in your case type definitions do not match any relationship type defined in the system: <em>%1</em>.... | error |
| 11 | CRM_Utils_Check_Component_Case | Missing Case Type Definition | Unable to locate xml file for Case Type "<em>%1</em>". | error |
| 12 | CRM_Utils_Check_Component_Case | Missing Case Roles | CaseRoles seems to be missing in the xml file for Case Type "<em>%1</em>". | error |
| 13 | CRM_Utils_Check_Component_Case | Invalid Case Role | CaseRole "<em>%1</em>" in the xml file for Case Type "<em>%2</em>" doesn\'t seem to match any existing relationship type. | error |
| 14 | CRM_Utils_Check_Component_Case | Case Role using display label instead of internal machine name | Please edit the XML file for case type "<em>%2</em>" so that the case role label "<em>%1</em>" is changed to its corresponding name "<em>%3</em>".... | warning |
| 15 | CRM_Utils_Check_Component_Env | PHP Up-to-Date | This system uses PHP version %1 which meets or exceeds the recommendation of %2. | info |
| 16 | CRM_Utils_Check_Component_Env | PHP Out-of-Date | This system uses PHP version %1. This meets the minimum recommendations and you do not need to upgrade immediately, but the preferred version is %2. | notice |
| 17 | CRM_Utils_Check_Component_Env | PHP Out-of-Date | This system uses PHP version %1. This meets the minimum requirements for CiviCRM to function but is not recommended.... | warning |
| 18 | CRM_Utils_Check_Component_Env | PHP Out-of-Date | This system uses PHP version %1. To ensure the continued operation of CiviCRM, upgrade your server now.... | error |
| 19 | CRM_Utils_Check_Component_Env | Forward Compatibility: Enable "mysqli" | Future versions of CiviCRM may require the PHP extension "mysqli". To ensure that your system will be compatible, please install it in advance.... | warning |
| 20 | CRM_Utils_Check_Component_Env | Timestamp Mismatch | Timestamps reported by MySQL (eg "%2") and PHP (eg "%3" ) are mismatched. | error |
| 21 | CRM_Utils_Check_Component_Env | Debug Mode Enabled | Warning: Debug is enabled in system settings. This should not be enabled on production servers. | warning |
| 22 | CRM_Utils_Check_Component_Env | Outbound Email Disabled | Warning: Outbound email is disabled in system settings.... | warning |
| 23 | CRM_Utils_Check_Component_Env | Complete Setup | Please enter your organization's name, primary address and default FROM Email Address (for system-generated emails). | warning |
| 24 | CRM_Utils_Check_Component_Env | Configure Default Mailbox | Please configure a default mailbox for CiviMail. | warning |
| 25 | CRM_Utils_Check_Component_Env | Cron Running OK | Last cron run at %1. | info |
| 26 | CRM_Utils_Check_Component_Env | Cron Not Running | Last cron run at %1. / No cron runs have been recorded. | warning / error |
| 27 | CRM_Utils_Check_Component_Env | Resource URLs: Make them portable | Resource URLs may use absolute paths, relative paths, or variables. Absolute paths are more difficult to maintain.... | notice |
| 28 | CRM_Utils_Check_Component_Env | Directory Paths: Make them portable | Directories may use absolute paths, relative paths, or variables. Absolute paths are more difficult to maintain.... | notice |
| 29 | CRM_Utils_Check_Component_Env | Directory not writable | The %1 is not writable. Please check your file permissions. | error |
| 30 | CRM_Utils_Check_Component_Env | Directory not writable | Directory %1 is not writable. Please change your file permissions. *(this is actually an error checking the version)* | error |
| 31 | CRM_Utils_Check_Component_Env | Update Check Disabled | The check for new versions of CiviCRM has been disabled.... | notice |
| 32 | CRM_Utils_Check_Component_Env | *Version update messages* | *As provided by version check* | info / notice / warning / critical |
| 33 | CRM_Utils_Check_Component_Env | Directory not writable | Your extensions directory is not set.... | notice |
| 34 | CRM_Utils_Check_Component_Env | Extensions directory incorrect | Your extensions directory path points to %1, which is not a directory.... | error |
| 35 | CRM_Utils_Check_Component_Env | Read-Only Extensions | Your extensions directory (%1) is read-only.... | notice |
| 36 | CRM_Utils_Check_Component_Env | Extensions url missing | The extensions URL is not properly set.... | error |
| 37 | CRM_Utils_Check_Component_Env | Extensions check disabled | Not checking remote URL for extensions since ext_repo_url is set to false. | notice |
| 38 | CRM_Utils_Check_Component_Env | Extension download error | *Message thrown by extension check* | error |
| 39 | CRM_Utils_Check_Component_Env | No Extensions Available for this Version | There are currently no extensions on the CiviCRM public extension directory which are compatible with version %1.... | notice |
| 40 | CRM_Utils_Check_Component_Env | Extensions | No extensions installed. | info |
| 41 | CRM_Utils_Check_Component_Env | Extension Error | Failed to read extension (%1).... / %1 extension (%2) is installed but missing files. | error |
| 42 | CRM_Utils_Check_Component_Env | Extension Update Available | %1 (%2) version %3 is installed. Upgrade to version %5. | warning |
| 43 | CRM_Utils_Check_Component_Env | Extensions | All extensions are up-to-date | info |
| 44 | CRM_Utils_Check_Component_Env | Extension Upgrades Pending | Extension upgrades should be run as soon as possible. | error |
| 45 | CRM_Utils_Check_Component_Env | Database Version Missing | Version information found to be missing in database.... | error |
| 46 | CRM_Utils_Check_Component_Env | Database Version Invalid | Database is marked with invalid version format.... | error |
| 47 | CRM_Utils_Check_Component_Env | Database Partially Upgraded | Database check failed - the database looks to have been partially upgraded. | alert |
| 48 | CRM_Utils_Check_Component_Env | Database Upgrade Required | New codebase version detected.... | alert |
| 49 | CRM_Utils_Check_Component_Env | Database In Unexpected Version | Your database is marked with an unexpected version number.... | error |
| 50 | CRM_Utils_Check_Component_Env | MyISAM Database Engine | Your database is configured to use the MyISAM database engine.... | error |
| 51 | CRM_Utils_Check_Component_Env | No Default value for Auto Responder. | Reply Auto Responder is not set to any default value in Headers, Footers, and Automated Messages.... | warning |
| 52 | CRM_Utils_Check_Component_Env | Missing mbstring Extension | The PHP Multibyte String extension is needed for CiviCRM to correctly handle user input among other functionality.... | warning |
| 53 | CRM_Utils_Check_Component_Env | Non-Production Environment | The environment of this CiviCRM instance is set to '%1'.... | alert |
| 54 | CRM_Utils_Check_Component_Env | Incorrect Resource URL | The Resource URL is not set correctly.... | error |
| 55 | CRM_Utils_Check_Component_Env | MySQL Emoji Support (utf8mb4) | Future versions of CiviCRM may require MySQL to support utf8mb4 encoding.... | warning |
| 56 | CRM_Utils_Check_Component_Env | PHP MySQL Driver (mysqlnd) | It is recommended, though not yet required, to upgrade your PHP MySQL driver (mysqlnd) to >= 5.0.9 for utf8mb4 support. | warning |
| 57 | CRM_Utils_Check_Component_Env | PHP MySQL Driver (libmysqlclient) | It is recommended, though not yet required, to upgrade your PHP MySQL driver (libmysqlclient) to >= 5.5.3 for utf8mb4 support. | warning |
| 58 | CRM_Utils_Check_Component_Env | MySQL Out-of-Date | This system uses MySQL/MariaDB v%1. To ensure the continued operation of CiviCRM, upgrade MySQL now.... | error |
| 59 | CRM_Utils_Check_Component_Env | MySQL Out-of-Date | This system uses MySQL/MariaDB v%1. To prepare for CiviCRM v%5, please upgrade MySQL.... | warning |
| 60 | CRM_Utils_Check_Component_Env | MySQL Out-of-Date | This system uses MySQL/MariaDB v%1. You can continue to use this version of MySQL.... | notice |
| 61 | CRM_Utils_Check_Component_FinancialTypeAcls | Extension Missing | CiviCRM will in the future require the extension %1 for CiviCRM Reports to work correctly with the Financial Type ACLs. | warning |
| 62 | CRM_Utils_Check_Component_OptionGroups | Option Values with problematic Values | The Following Option Values contain value fields that do not match the Data Type of the Option Group.... | notice |
| 63 | CRM_Utils_Check_Component_PriceFields | Invalid Price Fields | the following Price Set Fields use disabled or invalid financial types and need to be fixed if they are to still be used.... | warning |
| 64 | CRM_Utils_Check_Component_Schema | Performance warning: Missing indices | The following tables have missing indices.... | warning |
| 65 | CRM_Utils_Check_Component_Schema | Missing Log Tables | You don't have logging enabled on some tables.... | warning |
| 66 | CRM_Utils_Check_Component_Schema | Smart Group check did not run | The smart group check was unable to run. | info |
| 67 | CRM_Utils_Check_Component_Schema | Disabled/Deleted fields on Smart Groups | The following smart groups include custom fields which are disabled/deleted from the database.... | warning |
| 68 | CRM_Utils_Check_Component_Schema | Deprecated monetary value display format configuration | The Monetary Value Display format is a deprecated setting, and this site has a non-standard format. | warning |
| 69 | CRM_Utils_Check_Component_Security | Security Warning | The CiviCRM debug log should not be downloadable. | warning |
| 70 | CRM_Utils_Check_Component_Security | Private Files Readable | Files in the data directory (%2) should not be downloadable.... | warning |
| 71 | CRM_Utils_Check_Component_Security | Browseable Directories | Directory %2 should not be browseable via the web.... | error |
| 72 | CRM_Utils_Check_Component_Security | Unsafe Files | File '%1' presents a security risk and should be deleted. | critical |
| 73 | CRM_Utils_Check_Component_Security | Remote Profiles Enabled | Warning: External profile support (aka "HTML Snippet" support) is enabled in system settings. | warning |
| 74 | CRM_Utils_Check_Component_Security | Security Warning | The system administrator has disabled security settings (%1). Connections to remote applications are insecure. | warning |
| 75 | CRM_Utils_Check_Component_Source | Old files | The local system includes old files which should not exist.... | warning |
| 76 | CRM_Utils_Check_Component_Timestamps | Timestamps and Timezones | This MySQL database stores certain fields with data-type "DATETIME". To improve timezone support, you <em>may</em> want to change these from "DATETIME" to "TIMESTAMP".... | notice |
See also discussion on [PR #17698](https://github.com/civicrm/civicrm-core/pull/17698).https://lab.civicrm.org/dev/core/-/issues/1413Search the contacts modified in a period of time by a user2023-01-09T05:03:22ZdmunioSearch the contacts modified in a period of time by a userOverview
----------------------------------------
Possibility to search the contacts added or modified in a period of time by a particular user.
Example use-case
----------------------------------------
1. Click on **Search -> Advanced ...Overview
----------------------------------------
Possibility to search the contacts added or modified in a period of time by a particular user.
Example use-case
----------------------------------------
1. Click on **Search -> Advanced Search**.
2. In set **Change log**, enter time period and sort name of the user who added or modified the contacts sought.
3. Click on **Search button**.
Current behaviour
----------------------------------------
Currently it is only possible to search for contacts added or modified in a certain period. And separately, you can filter the contacts added and modified by a specific user. In the current version of civicrm (5.20) a note is displayed that clarifies this functionality in the **Modified By** field: **Note this field just filters on who made a change no matter when that change happened, It doesn't have any link to the modified date field.**
Proposed behaviour
----------------------------------------
Having the possibility to search for contacts added or modified in a period of time and by a specific user, constitutes a fundamental functionality in the monitoring of change logs.
For this improvement we have made the following pull request: https://github.com/civicrm/civicrm-core/pull/15913
Comments
----------------------------------------