CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-02-01T08:31:54Zhttps://lab.civicrm.org/dev/core/-/issues/2039Address extraneous location queries2022-02-01T08:31:54ZeileenAddress extraneous location queriesWhen importing a 'contact with a donation' 18% of the total queries come from [this line of code](https://github.com/civicrm/civicrm-core/blob/d357f225f281a0862b67a60d027c703ed2292f8b/CRM/Core/BAO/Location.php#L73) for [this issue](https...When importing a 'contact with a donation' 18% of the total queries come from [this line of code](https://github.com/civicrm/civicrm-core/blob/d357f225f281a0862b67a60d027c703ed2292f8b/CRM/Core/BAO/Location.php#L73) for [this issue](https://issues.civicrm.org/jira/browse/CRM-5051). I believe the handling in the create classes likely makes it obsolete.
I'm going to dig a bit further on that & put up a PR with the case for removing the line (unless I find a reason not to)
Per https://lab.civicrm.org/dev/core/-/issues/2033
examples - openid queries make up 4% of the total queries! and the line is 18% when including all location entities. This would be higher if it were only Contact.create that were being called
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| Location queries | 15/09/20 2:54 | SELECT * FROM `civicrm_openid` WHERE ( ( is_primary = 0 OR is_primary IS NULL ) ) AND ( `civicrm_openid`.`contact_id` = 46011839 ) | 0.000643 | 0 | 0 |
| Location queries | 15/09/20 2:54 | SELECT * FROM `civicrm_openid` WHERE ( ( is_primary = 0 OR is_primary IS NULL ) ) AND ( `civicrm_openid`.`contact_id` = 46011840 ) | 0.000517 | 0 | 0 |
| Location queries | 15/09/20 2:54 | SELECT * FROM `civicrm_openid` WHERE ( ( is_primary = 1 ) ) AND ( `civicrm_openid`.`contact_id` = 46011834 ) | 0.001377 | 0 | 0 |5.31.0https://lab.civicrm.org/dev/core/-/issues/2032Proposal - add ability to segment query logs2020-10-08T00:28:45ZeileenProposal - add ability to segment query logsI'm just working on documenting how to use query logs per process & it occurs to me that it is a bit hard getting the process specific part out of a longer query log. I have a possible way we could break it out into files / give back mor...I'm just working on documenting how to use query logs per process & it occurs to me that it is a bit hard getting the process specific part out of a longer query log. I have a possible way we could break it out into files / give back more control which I will put up as part of a PR - but it is a bit hacky....5.31.0https://lab.civicrm.org/dev/core/-/issues/2030Dropdown for country seems to have reverted to a regular select instead of se...2020-09-22T22:47:09ZDaveDDropdown for country seems to have reverted to a regular select instead of select2Meant to record this earlier and forgot. For example on a contribution page the country dropdown is a regular select. It all works though.
I think it reverted around 5.27-ish.Meant to record this earlier and forgot. For example on a contribution page the country dropdown is a regular select. It all works though.
I think it reverted around 5.27-ish.5.31.0https://lab.civicrm.org/dev/core/-/issues/3335Proposal on Membership Renewal form re 'fixMembershipBeforeRenew'2022-04-22T16:17:33ZeileenProposal on Membership Renewal form re 'fixMembershipBeforeRenew'When a membership is renewed via the backoffice form one step in the process is to call
CRM_Member_BAO_Membership::fixMembershipStatusBeforeRenew
This does a couple of things
1) it checks what the correct status is as of the current d...When a membership is renewed via the backoffice form one step in the process is to call
CRM_Member_BAO_Membership::fixMembershipStatusBeforeRenew
This does a couple of things
1) it checks what the correct status is as of the current date
2) if it is not 'correct' it
- changes the status
- adds a membership log
- adds an activity
- updates a parameter which tells the calling function if the membership is now current.
My belief is that this last parameter is useful to the calling function and the other steps are byproducts of shared code that may not be that relevant.
I propose we either
1) say that it is not necessary/ helpful to change the status & add the various entries in this flow OR
2) if it is useful (probably because the scheduled job didn't run) then we do it in the preProcess function rather than the post process
@andrewhunt @justinfreeman @mattwire @KarinG any opinions on ^^
(note there are some related issues that might come up - please try to add separate issues if you want to raise points outside this specific proposal)5.31.0https://lab.civicrm.org/dev/core/-/issues/2014Search on line items Ability to aggregate on a different field2020-09-22T01:06:13ZeileenSearch on line items Ability to aggregate on a different fieldGoal is to search on line items and group by financial type but aggregate the line total and tax columns, getting a total by financial type (we hit a variant of this the other day with basically the same thing on contributions)
@colemanwGoal is to search on line items and group by financial type but aggregate the line total and tax columns, getting a total by financial type (we hit a variant of this the other day with basically the same thing on contributions)
@colemanw5.31.0https://lab.civicrm.org/dev/core/-/issues/2013Line Item support in 'create search' - create smart group2020-10-07T19:45:57ZeileenLine Item support in 'create search' - create smart groupSo in trying to define a way in which line items in search might be useful I have this issue to define a first use case
Goal - create a smart group of all contacts with the line items of price field value 'General' in Price set 'Members...So in trying to define a way in which line items in search might be useful I have this issue to define a first use case
Goal - create a smart group of all contacts with the line items of price field value 'General' in Price set 'Membership Amount' (this is a bit of an artificial choice of line item but it's on default installs)
I had some success but could not link back to contacts...
![Screen_Shot_2020-09-11_at_11.26.29_AM](/uploads/1f07529473cd70d6d7d58cdac8cbbc37/Screen_Shot_2020-09-11_at_11.26.29_AM.png)
@colemanw5.31.0https://lab.civicrm.org/dev/core/-/issues/2009Grant dashboard counts trashed contacts2020-09-10T22:21:10ZlcdwebGrant dashboard counts trashed contactsThe grant dashboard tallies include contacts that are trashed and shouldn't. To reproduce:
* observe current dashboard stats for a specific status
* create a contact and create a grant with that same status
* trash the contact
* observe...The grant dashboard tallies include contacts that are trashed and shouldn't. To reproduce:
* observe current dashboard stats for a specific status
* create a contact and create a grant with that same status
* trash the contact
* observe the dashboard stats. it will have incremented by 1, including the trashed record
If you click the hyperlink to search for grants the trashed record is properly excluded. It's just the dashboard stats that are off.5.31.0lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/3250Add custom field groups to Membership Contribution Detail report2022-04-22T15:52:41ZJonGoldAdd custom field groups to Membership Contribution Detail reportEvery other report template that has `Contact` in the `$_customGroupExtends` array also includes individual contact types - "Individual" almost always, "Organization" and "Household" where relevant.
This PR adds the contact types to the...Every other report template that has `Contact` in the `$_customGroupExtends` array also includes individual contact types - "Individual" almost always, "Organization" and "Household" where relevant.
This PR adds the contact types to the `$_customGroupExtends` array.5.31.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2003Incorrect rounding up with priceset fields2020-12-30T16:59:35ZjaapjansmaIncorrect rounding up with priceset fields**How to reproduce**
1. Set decimal separator to , [comma]
2. Set thousand separator to . [dot]
3. Go to administer --> CiviContribute --> Manage Price Fields
4. Add a price set
5. Add a price field of type option
6. Add an option with ...**How to reproduce**
1. Set decimal separator to , [comma]
2. Set thousand separator to . [dot]
3. Go to administer --> CiviContribute --> Manage Price Fields
4. Add a price set
5. Add a price field of type option
6. Add an option with value 12,987654321
7. Add an option with value 9,87
8. Add an option with value 123.456.789,987654321
**Actual result**
* The option in step 6 becomes **12,00**
* The option of step 7 becomes **9,00**
* The option of step 8 becomes **123.456.789,99**
Note the rounding with zero's for step 6 and 7 and the correct but unwanted rounding of step 8.
**Expected result**
* The option in step 6 stays **12,987654321**
* The option of step 7 stays **9,87**
* The option of step 8 stays **123.456.789,987654321**
**See also**
We discovered this issue whilst we were testing [PR 18297](https://github.com/civicrm/civicrm-core/pull/18297)
**Tested in**
dmaster (5.31.alpha1)5.31.0https://lab.civicrm.org/dev/core/-/issues/1989E_WARNING when editing custom field with trigger-based logging turned on2020-09-06T20:47:11ZDaveDE_WARNING when editing custom field with trigger-based logging turned on1. Turn on logging (admin - system settings - misc).
2. Turn off popups so you can see the warning (admin - customize - display prefs) (or install the loudnotices extension).
3. Edit an existing custom field, e.g. just change the label, ...1. Turn on logging (admin - system settings - misc).
2. Turn off popups so you can see the warning (admin - customize - display prefs) (or install the loudnotices extension).
3. Edit an existing custom field, e.g. just change the label, or don't even do anything and just click save.
`Notice: Undefined index: ADD in CRM_Logging_Schema->fixSchemaDifferencesFor() (line 444 of .../CRM/Logging/Schema.php).`
`Warning: Invalid argument supplied for foreach() in CRM_Logging_Schema->fixSchemaDifferencesFor() (line 444 of .../CRM/Logging/Schema.php).`
This might be sort of recent just not sure yet when it started.5.31.0https://lab.civicrm.org/dev/core/-/issues/1988api attachment.get gives fatal error for custom file fields on cases2020-09-21T21:45:54ZDaveDapi attachment.get gives fatal error for custom file fields on casesI don't really believe in custom fields on cases, but if you happen to have one of type file, api attachment get fails on it with a fatal error "Failed to match record to related entity".
1. Create a custom field of type file for case...I don't really believe in custom fields on cases, but if you happen to have one of type file, api attachment get fails on it with a fatal error "Failed to match record to related entity".
1. Create a custom field of type file for cases.
2. Create a case and upload a file in the custom field.
3. Run something like `cv ev "var_dump(civicrm_api3('attachment', 'get', ['id' => 1]));"` where 1 is the corresponding id from civicrm_file. You'll get a fatal error.
4. You can also see it by:
1. Going to Find Cases.
1. Select the case you created.
1. Choose export from the actions dropdown.
1. Choose selected fields (ignore the E_WARNINGs).
1. Pick your custom field.
1. Click Download File.
1. Aside: I don't know why you would do this csv export because if it were working the column output is a time-limited url, so maybe is useful as input to another process, but I'm not sure what else.
It happens because the api goes through a couple central functions including Civi\API\Subscriber\DynamicFKAuthorization which tries to do a lookup by calling CRM_Core_BAO_CustomGroup::getTableNameByEntityName() to find out what table the custom field "extends", but it doesn't know about cases.
This appears to be a quick fix, but I'm not sure what weirdness this might introduce elsewhere, or whether the cases omission is on purpose.
```diff
diff --git a/CRM/Core/BAO/CustomGroup.php b/CRM/Core/BAO/CustomGroup.php
index 3a0dac33f1..435982d336 100644
--- a/CRM/Core/BAO/CustomGroup.php
+++ b/CRM/Core/BAO/CustomGroup.php
@@ -1164,6 +1164,10 @@ ORDER BY civicrm_custom_group.weight,
$tableName = 'civicrm_grant';
break;
+ case 'Case':
+ $tableName = 'civicrm_case';
+ break;
+
```5.31.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/1986Propose altering the default of send notification to contributor checkbox on...2020-09-21T10:54:22ZeileenPropose altering the default of send notification to contributor checkbox on cancel or edit recurring to offWhen cancelling or updating a recurring contribution there is a checkbox to notify the contributor - this is checked by default.
I use this form a bit as a 'user' and often forget to uncheck it - which results in a pretty mindless commu...When cancelling or updating a recurring contribution there is a checkbox to notify the contributor - this is checked by default.
I use this form a bit as a 'user' and often forget to uncheck it - which results in a pretty mindless communication going out for what is usually either being done as part of a chain of communication with the donor (it's redundant) or an administrative change (the next scheduled date needs updating due to some oddity).
Because it's a rare-ish flow and 9 times out of 10 I mean to uncheck it I have never bothered to edit / maintain the message template.
I realise that I could add an extension to change the default - but my gut is that given I've seen it be problematic on 2 out of 2 sites it would probably be better that people actively choose to check the button rather than have to remember to uncheck it. If you forget to check it it's easy to send a quick email but impossible to recall if it you forget to uncheck it.5.31.0https://lab.civicrm.org/dev/core/-/issues/3252View Payment owned by Different contact on Membership and Participant View.2022-04-22T15:52:43ZsunilView Payment owned by Different contact on Membership and Participant View.Overview
----------------------------------------
Using Webform, we can set that, contribution assigned to contact A and Membership record will be assigned to Contact B and C (based on number Contact selected in webform). IF we visit the...Overview
----------------------------------------
Using Webform, we can set that, contribution assigned to contact A and Membership record will be assigned to Contact B and C (based on number Contact selected in webform). IF we visit the Membership Record of B and C, we can not see the linked Payment, because its owned by another contact. and there is NO way to check who own the payment record.
Current behaviour
----------------------------------------
Currently it does not show linked payment record if payment is not present on same contact.
Expected behaviour
----------------------------------------
Linked Payment record should show, irrespective of who own the payment record as long as payment is belong the respective Membership.
In this case, webform create membership payment link between each contact membership and contribution id in `civicrm_membership_payment` table.
As long as we have linking between membership and contribution id, then it shows linked payment on Membership View. Same apply to participant.
----------------------------------------
https://github.com/civicrm/civicrm-core/pull/182815.31.0https://lab.civicrm.org/dev/core/-/issues/1980Add Line Item v4 API2020-09-10T19:29:08ZeileenAdd Line Item v4 APIIn order to do this there is some preliminary work to do as the v3 api has handling that needs to be unpacked first. In general there are 2 parts
1) Get & Delete - the goal here is to use a more conventional hook to do this in financial...In order to do this there is some preliminary work to do as the v3 api has handling that needs to be unpacked first. In general there are 2 parts
1) Get & Delete - the goal here is to use a more conventional hook to do this in financialacls core extension
2) Create - not too sure what this stuff is doing yet....5.31.0https://lab.civicrm.org/dev/core/-/issues/1979Incorrect comparison of status_id when changing status of linked cases2020-09-07T14:31:35ZDaveDIncorrect comparison of status_id when changing status of linked casesIt ends up working anyway because it will just change the status of the other case to the same thing it already was so you don't see any problem, but it's comparing wrong and you get an E_NOTICE: `Undefined index: status_id in CRM_Case_F...It ends up working anyway because it will just change the status of the other case to the same thing it already was so you don't see any problem, but it's comparing wrong and you get an E_NOTICE: `Undefined index: status_id in CRM_Case_Form_Activity_ChangeCaseStatus::beginPostProcess() (line 137 of .../CRM/Case/Form/Activity/ChangeCaseStatus.php).`
1. Create a case.
1. Create another case.
1. Create a link cases activity and link them.
1. Create a change case status activity and check the box to update related cases.
1. Click save.
It looks like it's been this way since it was implemented: https://github.com/civicrm/civicrm-core/commit/74b15fae91a220e2b1ab6f29f6e86001743eac0d#diff-784c2a130a993b23166dadf7f1ddc489R156. The available field at that point is a label not the id (the word id here would really mean option_value.value, but that's not the issue).
So two options:
1. Just remove the `if`, since that's effectively what it's been doing this whole time.
1. Include status_id in the results returned from getRelatedCases().5.31.0https://lab.civicrm.org/dev/core/-/issues/1973Email & Phone storage issues in event location2020-09-18T01:07:09ZjitendraEmail & Phone storage issues in event location**Email** - Second field value cannot be saved on form submit.
To replicate -
- Navigate to Event -> Location tab - https://dmaster.demo.civicrm.org/civicrm/event/manage/location?reset=1&action=update&id=3
- Enter a value for the secon...**Email** - Second field value cannot be saved on form submit.
To replicate -
- Navigate to Event -> Location tab - https://dmaster.demo.civicrm.org/civicrm/event/manage/location?reset=1&action=update&id=3
- Enter a value for the second email field and save. The second field is empty after the form is submitted. And Email2 value is displayed on the first email field
**Phone**: Every time the Location form is submitted, a new row is inserted in phone table even if it already exist.
To replicate -
- Navigate to Event -> Location tab - https://dmaster.demo.civicrm.org/civicrm/event/manage/location?reset=1&action=update&id=3
- Fill both the phone numbers and save.
- Re-save the form without changing any value. 2 new duplicate rows have been inserted in `civicrm_phone` table.
- This happens on every submission of the Location form.
Reverting https://github.com/civicrm/civicrm-core/pull/13534/files fixes both the above issues.5.31.0https://lab.civicrm.org/dev/core/-/issues/1949Payment method should reflect the last transaction on the contribution2020-09-09T05:18:38ZyashodhaPayment method should reflect the last transaction on the contributionPayment method should reflect the last transaction on the contribution.
When the payment method is updated on the contribution, the system creates a new payment record with the new payment method attached to the contribution.
When the ...Payment method should reflect the last transaction on the contribution.
When the payment method is updated on the contribution, the system creates a new payment record with the new payment method attached to the contribution.
When the contribution is saved, we must update the payment method field on the contribution with the payment method on the most recent payment record attached to that contribution.
I know we are planning on dropping the payment method on contribution and just have it for individual transaction but till the time it does exist it should have the correct value.
Create a contribution which is pay later by check
![pay_later](/uploads/73fda0162672541c39db8f212f945f59/pay_later.png)
Record payment complete with method Cash
![new_payment](/uploads/5c721d3cf7f0d40daf02373a7ce28916/new_payment.png)
It doesn't reflect
![payment_view](/uploads/72697eeae2a99dee75dcc519ece65b97/payment_view.png)5.31.0https://lab.civicrm.org/dev/core/-/issues/3550Email to activity processing: New feature to make the creation of new contact...2022-06-11T14:50:44ZJamie Novick - CompucoEmail to activity processing: New feature to make the creation of new contacts "optional"**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts a...**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts are not created in the system when filing an email.
- In the situation of a case email where the email has a valid Case ID or Case token in the subject line the email should still be filed to a case, even if no contacts are matched.
**How it works currently:**
Currently, when CiviCRM performs email to activity processing, Civi will search CiviCRM for a contact with the relevant email address in the From / To / CC fields and then assign the created activity accordingly.
When CiviCRM cannot find a contact with a relevant email address, it simply creates a new "stub" contact with the email address.
**The problem**
For multiple reasons this is might not be desirable behaviour:
This is a security risk, as in most cases CiviCRM email-activity processing works off a mailbox, that might need to be public. As such it is possible that an unscrupulous third party may chose to spam your mailbox and thus spam your CRM with unwanted emails and content. Whilst this can be mitigated by having your automated filing on a separate mailbox, it might be preferable to simply only file the emails for contacts who already exist in your system, and to selectively add the rest.
Also, from a GDPR perspective it may not be desirable to hold the details of the persons who sent an email, whilst the contents of the email might be important (i.e. the attachments) especially in a casework context.
**Proposed solution:**
Add an additional option to the email to activity processing configurations (civicrm/admin/mailSettings?action=add&reset=1)
- When "Used For?" = Email to activity processing
- Show an additional option:
- "Do not create new contacts when filing emails"
- Checkbox
- Default null
- Help:
- If this option is enabled, CiviCRM will not create new contacts when filing emails.
- The email should also always be filed as an activity.
If checked:
- When CiviCRM checks for a matching contact, if no matching contact is found it will not create one and the email is skipped
- unless the email has a valid Case ID or Case token in the subject line, in which it will still be filed against the case, but no contacts will be linked to the email.5.31.0https://lab.civicrm.org/dev/core/-/issues/3581Email to activity processing: New feature to skip emails which do not have a ...2022-06-11T14:54:48ZJamie Novick - CompucoEmail to activity processing: New feature to skip emails which do not have a Case ID or Case token- As a CiviCRM administrator
- I would like to configure whether CiviCRM will process emails without a case ID (or case “token”) in the subject line
- so that I can ensure that emails which do not have a case ID are not filed on the con...- As a CiviCRM administrator
- I would like to configure whether CiviCRM will process emails without a case ID (or case “token”) in the subject line
- so that I can ensure that emails which do not have a case ID are not filed on the contact record outside the case by accident.
**How it works currently**
For those a little less familiar with email to activity processing:
CiviCRM will connect to a users MS exchange mailbox and create the following folder structure:
- Inbox
- /CiviCRM
- //CiviMail
- ///ignored
- ///processed
Notes:
- Users simply copy or move emails into the /civicrm folder in their inbox. CiviCRM has a scheduled job that can be configured to run periodically (say every hour) and poll the mailbox folder (Civimail) by IMAP in order to read and process the emails.
- By default CiviCRM will match any email from, to, cc fields to contacts in the CRM and file the email as an activity against those contacts (including recording any attachments as files).
- If however there is a case ID in the subject line (or a case ID "token"*) then CiviCRM will instead file the email straight onto the case itself. The format is: [case #1234] (see: https://issues.civicrm.org/jira/browse/CRM-21446)
- If the email is processed successfully it will be moved to the processed folder.
- If for any reason CiviCRM cannot file the email it will be moved to the ignored folder. This normally happens if the email address is invalid for some reason (please note: emails that are sent internally between staff on exchange server can sometimes have this problem as exchange doesn't always use the external email address but instead uses some local username/domain combination - this maybe something to test and see if it maybe a problem for NEU).
- Note: *When sending out emails from CiviCRM from CiviCase it appends a case ID token - which is a string of characters and not the exact Case ID. This is done to obscure the case ID number in the email. In effect you can have either this token or the case id in the subject line and CiviCRM will file the email correctly.
- More background: https://docs.civicrm.org/sysadmin/en/latest/setup/civimail/inbound/#autofiling-email-activities-via-emailprocessor
**Problem**
For multiple clients they want to use email to activity processing for their casework teams. However sometimes they forget to add the case ID to the subject line of the email and the system incorrectly files the email outside the case - which is a "security" risk as the emails can be sensitive.
As such they would like to be able to specify that the emails being filed from the casework team inbox will only be filed if there is a valid Case ID in the subject line and are skipped if not, and hence there is no risk of the email being filed outside of the case.
**Proposed improvement**
Approach:
When "Used For?" = Email to activity processing
Show an additional option:
- Skip emails which do not have a Case ID or Case token:
- Checkbox
- Help text:
- CiviCRM has functionality to file emails which contain the Case ID or Case Hash in the subject line in the format [case #1234] against a case record.
- Where the Case ID or Case Hash is not included CiviCRM will file the email against the contact record, by matching the email addresses on the email with any email addresses of Contact records in CiviCRM.
- Enabling this option will have CiviCRM skip any emails that do not have the Case ID or Case Hash so that the system will only process emails that can be placed on case records.
- Any emails that are not processed will be moved the ignored folder.
- Default null
- If checked:
- Emails which do not have a valid case ID or case token should be moved into the “ignored” folder. (See folders above) after processing and no Activity should be created.
Would be great to know if we can get the magical "concept approved" flag.
We need to work on this quite urgently so if there are no great concerns that would be much appreciated...5.31.0