Development issueshttps://lab.civicrm.org/groups/dev/-/issues2018-12-30T09:14:00Zhttps://lab.civicrm.org/dev/core/-/issues/625DB error on Case Summary report dev/core#6032018-12-30T09:14:00ZDon WijesooriyaDB error on Case Summary report dev/core#603As mentioned in dev/core#603, filtering case summary report by "Active Relationship?" throws a DB field not found error.
The submitted PR only makes it a non-mandatory field.
Seen on dmaster ( 5.10.alpha1 )
## Steps to reproduce:
1....As mentioned in dev/core#603, filtering case summary report by "Active Relationship?" throws a DB field not found error.
The submitted PR only makes it a non-mandatory field.
Seen on dmaster ( 5.10.alpha1 )
## Steps to reproduce:
1. Go to Reports->Case Reports->New Case Report
2. Select Case Summary Report
3. Deselect "Staff Member" and "Relationship" fields
4. Go to Filters tab
![summary_report](/uploads/6adbf062de3def6e64ca1a42812f09f7/summary_report.png)
5. For "Active Relationship?" select operator "Is equal to" and value "Yes"
6. Click on View Results
7. Throws the following error
![error](/uploads/5ea31c37c155b70b7517eedf73b26433/error.png)
## Issue
As mentioned in dev/core#603, the bug is due to this condition: `if ($this->_relField)`
![FromClause](/uploads/cb96fe716027aafcaf71b4fbd38ea1aa/FromClause.png)5.10https://lab.civicrm.org/dev/core/-/issues/626Case Activities no longer show overdue items first.2018-12-29T21:21:27ZRayWrightCase Activities no longer show overdue items first.Previously, the listings of activities on cases would show overdue items first.
![CaseAct-01](/uploads/744e76b6db7657cd80aded49ebb453d3/CaseAct-01.png)
When datatables were being integrated CRM-16363 https://github.com/civicrm/civicrm-...Previously, the listings of activities on cases would show overdue items first.
![CaseAct-01](/uploads/744e76b6db7657cd80aded49ebb453d3/CaseAct-01.png)
When datatables were being integrated CRM-16363 https://github.com/civicrm/civicrm-core/commit/ad280fb669e26f136bb9f56b29556ad70a78d3a6#diff-ff123c4a302e96ad0dfa6e93247dd242 they added a sort order to the table directly int the template file - resulting in this:
![CaseAct-02](/uploads/267ede7aa3a41ca0ea648af419ead426/CaseAct-02.png)
The logic to sort by overdue items first lives in the Case/BAO/Case.php file (line 1042 in 5.5.3)
`ORDER BY overdue_date ASC, display_date DESC, weight DESC";`
Simply removing the data-order 'filter' from the tpl file reverts to the previous behavior. I've put in a PR as well.5.10https://lab.civicrm.org/dev/core/-/issues/627Correct syntax for Get pledge payment count2019-12-14T21:24:27ZsunilCorrect syntax for Get pledge payment countOnce Pledge have payment (status is In-Progress), we can not update the pledge amount and number of instalment.
but if Pledge have payment and some payment status is overdue then Pledge status change to 'overdue' and this allow to updat...Once Pledge have payment (status is In-Progress), we can not update the pledge amount and number of instalment.
but if Pledge have payment and some payment status is overdue then Pledge status change to 'overdue' and this allow to update pledge amount and number of instalment.5.15.0https://lab.civicrm.org/dev/core/-/issues/628Rearrange quick search options2019-06-06T12:54:25ZshitijgRearrange quick search options**Overview:**
Mostly all the organisations use the external ID field, some of the ones that we are working with want to rearrange the quick search options so that the External ID field is at the top of the search options or at times cha...**Overview:**
Mostly all the organisations use the external ID field, some of the ones that we are working with want to rearrange the quick search options so that the External ID field is at the top of the search options or at times change the label of these fields.
**Existing:**
We can switch on/off any fields that are available to quicksearch from /civicrm/admin/setting/search?reset=1
Also, if a user selects a field from the quicksearch dropdown, that field is set as the default search option but this is just as a cookie ie local to every user.
**Proposed Implementation:**
Instead of just having a checkbox for enabling fields, we can have a table where:
- the user can rearrange the the fields which would dictate the order of the fields in the quicksearch
- the user can set a particular field as default which would be the default selection globally
- the user can change the label of any fields for eg the label of External ID can be changed to Membership ID
Screenshot attached.
![Quicksearch](/uploads/3c00f66affe93a9579001eae243f7e82/Quicksearch.png)
Thankshttps://lab.civicrm.org/dev/core/-/issues/629Authorize.Net changes how it handles some character data from 10th Jan, 20192019-06-03T05:23:41ZyashodhaAuthorize.Net changes how it handles some character data from 10th Jan, 2019As per
https://community.developer.authorize.net/t5/News-and-Announcements/Changes-to-Supported-Characters-on-January-10-2019/td-p/65435
Authorize.Net is changing how it handles some character data included in transactions submitted to ...As per
https://community.developer.authorize.net/t5/News-and-Announcements/Changes-to-Supported-Characters-on-January-10-2019/td-p/65435
Authorize.Net is changing how it handles some character data included in transactions submitted to them.
I don't think this will affect CiviCRM but needs to be double checked.https://lab.civicrm.org/dev/core/-/issues/630CiviCase multi-category/ multi-instance support2022-10-29T05:03:41ZguanhuanCiviCase multi-category/ multi-instance supportRecently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. So...Recently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. Some of them require a change to evolve CiviCase’s data model to a multi-level structure.
To support this idea, I have attached a diagram to demonstrate the multi-level structure. We have suggested that a new field “case type category” would provide a lot of flexibility.
![CiviCase_Structure](/uploads/b73a3f3e8eb1d71034ac9121e1379f9c/CiviCase_Structure.jpg)
The basic idea is, an organisation’s business is made up of many different workflows for different business areas, such as Service delivery (i.e. a Helpdesk, Counselling service or Delivering care/housing support), Prospecting (i.e. major donors, grants bid writing in), Awards (i.e. Grants out), Volunteer vacancy management and even perhaps as a set of tasks for an event etc. These completely different workflows often are managed by completely different teams (who would need to manage their own case types), produce very different data and therefore require very different analysis and reports. "Case Type” is not sufficient to support all these needs as there may be several case types which apply to any specific business area.
Each team would probably want:
- The ability to create/configure case types of their category. For example with a volunteer vacancy managers they may want to create multiple vacancies, or with Grants, there may be multiple open opportunities. For Major donors they may split these between different types of donor - i.e. trusts, individuals, government which have different timelines and activities.
- The ability to add additional fields at the case type level for each category.
- Only having access to cases with the case type category they should have access to
- Some modifications to the case screen for cases of that case type category.
We've made a more detailed [draft proposal](https://compucorp.atlassian.net/wiki/spaces/PS/pages/1014398991/CiviCase+multi-category+support) of what we need to do to eliminate these caveats. The main target is to bring out the full potential of CiviCase as CiviCRM’s workflow management suite.https://lab.civicrm.org/dev/core/-/issues/631Problem when merging contacts which have membership records2024-03-15T05:03:26ZUpperholmeProblem when merging contacts which have membership recordsAs noted at https://civicrm.stackexchange.com/questions/27885/what-is-the-most-reliable-method-for-merging-records-with-memberships when merging two contacts when one of them has a membership, the membership does not get moved to the mer...As noted at https://civicrm.stackexchange.com/questions/27885/what-is-the-most-reliable-method-for-merging-records-with-memberships when merging two contacts when one of them has a membership, the membership does not get moved to the merged record as it should. The workaround is to ensure that the record with the membership is on the right (i.e. is the record that won't get deleted).jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/632Membership payment amount is NAN.N2021-05-06T05:50:24Zvakeesan26Membership payment amount is NAN.Nwhen minimum amount of membership type is greater than 999,
while editing membership and recording the payment the amount is being populated as "NAN.N" [ we have to delete any existing contribution related to this membership to record t...when minimum amount of membership type is greater than 999,
while editing membership and recording the payment the amount is being populated as "NAN.N" [ we have to delete any existing contribution related to this membership to record the payment again ]
![image](/uploads/da98229007fca7fa802dd00ac613b13b/image.png)https://lab.civicrm.org/dev/core/-/issues/633Specify the type of activity source entity2022-09-26T05:03:42ZguanhuanSpecify the type of activity source entity**Overview**
Activity table has a column source_record_id. It can refer to different entities depending on different activity type. For example, activity type "Event Registration" uses participant records as source records while activit...**Overview**
Activity table has a column source_record_id. It can refer to different entities depending on different activity type. For example, activity type "Event Registration" uses participant records as source records while activity type "Contribution" uses contribution records as source records.
The interpretation of what type of entity the source record is referring is subject to the logics for a selection of activity type defined in the code, in other words, it's hardcoded currently (please point out if this is no longer true).
**Proposed Solution**
This can be easily improved by adding a source_record_entity_table column to the activity table next to the source_record_id to indicate the entity.
This solution will not only help avoiding hardcoding source record entity but also provide flexibility to both:
- Recording source record: Any activity can refer to any entity that initiated/ is relevant to the activity. Same type of activity can even refer to different entities in different scenarios.
- Interpreting source record: Core and extensions can define the interpretation logics for different activity types and different source record entity. This can potentially be used to enable more tokens in activity based schedule reminders.https://lab.civicrm.org/dev/core/-/issues/634Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: "Yo...2019-01-03T23:12:15ZeileenSymfony\Component\DependencyInjection\Exception\ServiceNotFoundException: "You have requested a non-existent service "civi_flexmailer_required_tokens".Hitting this locally on 5.10 rc with latest master of flexmailing - not too sure what to make of it yet
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: "You have requested a non-existent service "civi_flexmaile...Hitting this locally on 5.10 rc with latest master of flexmailing - not too sure what to make of it yet
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: "You have requested a non-existent service "civi_flexmailer_required_tokens"."
#0 /srv/www/wp-content/plugins/civicrm/civicrm/Civi.php(101): Symfony\Component\DependencyInjection\Container->get("civi_flexmailer_required_tokens")
#1 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Core/Resolver.php(79): Civi::service("civi_flexmailer_required_tokens")
#2 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Core/Resolver.php(118): Civi\Core\Resolver->get("call://civi_flexmailer_required_tokens/getRequiredTokens")
#3 /srv/www/wp-content/plugins/civicrm/civicrm/CRM/Mailing/Info.php(133): Civi\Core\Resolver->call("call://civi_flexmailer_required_tokens/getRequiredTokens", (Array:0))
#4 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Angular/Manager.php(99): CRM_Mailing_Info->getAngularModules()
#5 /srv/www//wp-content/plugins/civicrm/civicrm/Civi/Angular/Manager.php(177): Civi\Angular\Manager->getModules()
#6 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Angular/AngularLoader.php(216): Civi\Angular\Manager->resolveDefaultModules("civicrm/a")
#7 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Angular/AngularLoader.php(108): Civi\Angular\AngularLoader->findActiveModules()
#8 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Angular/Page/Main.php(83): Civi\Angular\AngularLoader->load()
#9 /srv/www/wp-content/plugins/civicrm/civicrm/Civi/Angular/Page/Main.php(69): Civi\Angular\Page\Main->registerResources()
#10 /srv/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(309): Civi\Angular\Page\Main->run((Array:3), NULL)
#11 /srv/www//wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:12))
#12 /srv/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#13 /srv/www/wp-content/plugins/civicrm/civicrm.php(1243): CRM_Core_Invoke::invoke((Array:3))
#14 /srv/www//wp-includes/class-wp-hook.php(286): CiviCRM_For_WordPress->invoke("")
#15 /srv/www/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters("", (Array:1))
#16 /srv/www/wp-includes/plugin.php(453): WP_Hook->do_action((Array:1))
#17 /srv/www/wp-admin/admin.php(224): do_action("toplevel_page_CiviCRM")
#18 {main}https://lab.civicrm.org/dev/core/-/issues/635Implement reconnect/replay-on-write for database connections2020-09-09T05:24:30ZtottenImplement reconnect/replay-on-write for database connectionsCurrently, CiviCRM always connects to a singular DSN. For epic:ro-db, we seek compatibility with a split DB architecture in which one routes MySQL requests to (a) read-only slave DBs and/or (b) read-write master DB. This issue specifical...Currently, CiviCRM always connects to a singular DSN. For epic:ro-db, we seek compatibility with a split DB architecture in which one routes MySQL requests to (a) read-only slave DBs and/or (b) read-write master DB. This issue specifically proposes a "reconnect-on-write" or "replay-on-write" (RPOW) mechanism as a general, global baseline.
## Technical Overview
One possible technique is to sprinkle flags/hints into the application to indicate which use-cases should be served by slave/rodb or by master/rwdb. *Some* of this sprinkling is likely happen, but we have a large, open-ended application (with several built-in subsystems and several third-party extensions/addons). Auditing all of these is somewhat daunting task.
RPOW aims to provide a *generic baseline* that relies primarily on MySQL semantics (and doesn't require auditing every use-case carefully). The general idea is:
1. Connect optimistically to the read-only slave (expecting a read-only use-case). We can continue using the RODB as long as requests are read-oriented (e.g. `SELECT`).
2. If there is an actual write operation (e.g. `UPDATE`), then reconnect to the read-write master.
Dynamically switching to the read-write master is not quite as simple as it sounds:
* Some SQL statements (eg `SET @foo` and `CREATE TEMPORARY TABLE`) can be legitimately used in a read-oriented operation (e.g. advanced querying/reporting) -- but they may also be prelude to a write-operation (e.g. building a temp-table with a list of targets and then updating each one). We allow these to execute on the RODB -- but, when/if we reconnect to RWDB, then we *replay* those statements.
* To support replay, we must be able to classify any SQL statement into one of three buckets:
* `READ` (Ex: `SELECT * FROM foo`): The SQL statement has no side-effects; it simply reads data.
* `BUFFER` (Ex: `SET @user_id = 123`): The SQL statement has no long-term, persistent side-effects; it can, however, have temporary side-effects during the present MySQL session.
* `WRITE` (Ex: `TRUNCATE foo`): The SQL statement has long-term, persistent side-effects and must be executed on the master. (Generally, if we can't demonstrate that something is `READ` or `BUFFER`, then we assume it is `WRITE`.)
* The MySQL query language has interesting edge-cases (e.g. `SELECT @foo := id FROM bar FOR UPDATE`) that should be handled correctly.
* We don't know anything about the delay in sync'ing between RODB and RWDB. After making a write, we'll continue sending all requests (reads or writes) to RWDB for some *period of time*. (Ex: After updating a contact in RWDB, the user's browser gets a cookie -- and, for the next 60 seconds, any additional reads should hit RWDB.)
## Limitations and Assumptions
* RPOW makes sense if user's are primarily reading from MySQL. Stock CiviCRM relies extensively on MySQL for caching and session-state, which leads to frequent writes. However, if you use the Redis integration for caches/sessions/prevnext, then this is significantly reduced.
* RPOW aims to *mitigate/reduce* the need for sprinkling use-case specific hints. However, there may still be scenarios where one wants to sprinkle hints. In particular: the contact-edit screen uses optimistic-locking (which reads the last-modified timestamp before authorizing updates); for correct oplocking, there should be a hint that any POST requests to the contact-edit screen need the RWDB.
## Relevant Tasks / Patches / Subtasks
The following are types of patches / subtasks we may expect:
* Adding a new DB driver -- an admin can opt-in to using RPOW behavior by setting `CIVICRM_DSN` to a special value (and registering DSNs for both RODBs and RWDB).
* Adding a unit-test to ensure correct classification of a range of SQL examples.
* Maintaining a cookie or session-variable to indicate that a user needs to be temporarily directed to RWDB by default.
* Updating existing use-cases to reduce gratuitous writes or to send hints about specific write-oriented use-cases.
NOTE: I've currently got a draft project in https://github.com/totten/rpow ; however, I'm filing this issue here because some of this work will need to come back into core.
## Pull Requests
* [#13394 - Reduce unnecessary SQL writes](https://github.com/civicrm/civicrm-core/pull/13394) (m)
* [#13500 - (REF) Add CRM_Utils_Cache::nack(). Use it for NaiveHasTrait](https://github.com/civicrm/civicrm-core/pull/13500) (m)
* [#13496 - Implement local array-cache for use with Redis/Memcache](https://github.com/civicrm/civicrm-core/pull/13496) (m)
* [#13489 - Deprecate CRM_Core_BAO_Cache for I/O. Optionally redirect I/O to Redis or Memcache. #13489 ](https://github.com/civicrm/civicrm-core/pull/13489) (m)
* [#13514 - CRM_Utils_Cache::nack() - Fix format](https://github.com/civicrm/civicrm-core/pull/13514) (m)tottentottenhttps://lab.civicrm.org/dev/core/-/issues/636Custom field for Address: The "No" value is not defaulted2019-01-06T19:32:14ZPradeep Nayakpradpnayak@gmail.comCustom field for Address: The "No" value is not defaultedTo replicate:
* Create custom field Yes/No for custom group "Address Details" extending address
* View contact record
* Click on the Address area
* Open "Address Details"
* Choose "No"
* Click "Save"
* Click on the Address area again
*...To replicate:
* Create custom field Yes/No for custom group "Address Details" extending address
* View contact record
* Click on the Address area
* Open "Address Details"
* Choose "No"
* Click "Save"
* Click on the Address area again
* Open "Address Details"
![Address_Custom_field](/uploads/dc88818dcdf45b50feaa45372f9b7a97/Address_Custom_field.gif)
PR: https://github.com/civicrm/civicrm-core/pull/133975.11https://lab.civicrm.org/dev/core/-/issues/638Manage groups: Error: "API permission check failed for Group/create call; ins...2019-01-16T14:09:44ZPradeep Nayakpradpnayak@gmail.comManage groups: Error: "API permission check failed for Group/create call; insufficient permission" when the user tries to edit some group's details**Precondition:** The CRM was opened by the user with the role having minimum permission to create group and contact.
The system has, for example, one group
**Steps:**
Click "View contact record"
Click "Contacts" -> "Manage Groups"
T...**Precondition:** The CRM was opened by the user with the role having minimum permission to create group and contact.
The system has, for example, one group
**Steps:**
Click "View contact record"
Click "Contacts" -> "Manage Groups"
Try to edit Name of the group from the precondition(in-line edit).
**Actual result:** There is an error: "API permission check failed for Group/create call; insufficient permission: require access CiviCRM and edit groups"
No changes are applied.
**Expected result:** Should be able to edit the Group name from Manage group screen.https://lab.civicrm.org/dev/core/-/issues/639Note: No restriction of the Subject field length2019-03-01T00:19:08ZPradeep Nayakpradpnayak@gmail.comNote: No restriction of the Subject field length**STR:**
* Navigate to Search→Find Contacts
* Find any Individual/Organisation
* On the Search results page, click vertical ellipsis and select "Add Note"
* Fill in the Subject field with more than 255 chars
* Fill in the Body fields wi...**STR:**
* Navigate to Search→Find Contacts
* Find any Individual/Organisation
* On the Search results page, click vertical ellipsis and select "Add Note"
* Fill in the Subject field with more than 255 chars
* Fill in the Body fields with some text
* Click Save
* Navigate to the created Note
* Check the number of the characters in the Subject field
**Result:** the number of saved characters in the created Note is 255
**Expected result:** during Note creation, there should be a restriction to the field length (255 char max)
PR:https://github.com/civicrm/civicrm-core/pull/134035.12.0https://lab.civicrm.org/dev/core/-/issues/640Create repeating activity requires Event permission2019-01-05T20:23:46ZdavejCreate repeating activity requires Event permissionCreating a repeating activity through the UI gives an Access Denied error unless the user has "access CiviEvent" permission.
**Steps to replicate**
1. Log in as a user without "access CiviEvent" permission.
2. From contact summary, Act...Creating a repeating activity through the UI gives an Access Denied error unless the user has "access CiviEvent" permission.
**Steps to replicate**
1. Log in as a user without "access CiviEvent" permission.
2. From contact summary, Activities tab, click New Activity, choose e.g. Meeting.
3. Expand the "Repeat Activity" section, Click the "After" radio button, Save.
**Expected result**
Confirm dialog lists the instances that will be created.
On clicking Confirm, the instances are created and listed.
**Actual result**
Confirm dialog is blank. Error message appears:
"Access Denied / Ensure you are still logged in and have permission to access this feature.".
On clicking Confirm, the instances are created and listed.
**Analysis**
Problem occurs because the confirm dialog uses a path that requires "access CiviEvent" permission. In CRM/Core/xml/Menu/Misc.xml:
```
<item>
<path>civicrm/recurringentity/preview</path>
<page_callback>CRM_Core_Page_RecurringEntityPreview</page_callback>
<access_arguments>access CiviCRM,access CiviEvent</access_arguments>
<title>Confirm dates</title>
</item>
```
Problem is resolved by removing ",access CiviEvent".5.11https://lab.civicrm.org/dev/core/-/issues/641Case Activity Assignment Restriction2022-10-12T05:04:03ZshitijgCase Activity Assignment Restriction**Overview:**
We have had a few security complaints from a few clients using cases. They mistakenly assigned an activity to a contact who was not supposed to see the details of the activity.
**How it works right now**
Currently, a us...**Overview:**
We have had a few security complaints from a few clients using cases. They mistakenly assigned an activity to a contact who was not supposed to see the details of the activity.
**How it works right now**
Currently, a user can create and assign an activity to any CiviCRM contact. This in turn sends an email notification to the assignee. However, some users have reported that they mistakenly assigned activities to contacts with similar names which meant that someone who should not have access to any details of the activity got a link stating some basic details of the activity.
Whilst, the contact who received the email wasn't a CiviCRM user, so they couldn't not login and edit the activity, just some basic details in this case acted as a security breach as the table in the email already revealed more about the activity.
**New Implementation:**
We want to add the ability to restrict the assignment of case activities to a group.
Points to note- (UPDATED ON 07/01 to have this setting on the case type)
- This can live in the case type settings ie the user can define which group can an activity be assigned to per case type (civicrm/a/#/caseType/n where 'n' is the ID of the case type)
- We can have 2 options for the field "Case activity assignment to" - 1. All Users (DEFAULT) 2. Restricted by group
- On selecting 2. - the user will be able to select a group
- Once a group is selected, the user will only be able to assign a case activity to contacts within the selected group
- If an activity from outside cases is "Filed" on case - and if the assignee is not a part of that group - there should not be any new notifications going to the assignee (this is already working this way ie no notifications are sent to the assignee on filing an out of case activity to a case)
Feel free to reach out to me on Mattermost if you need any clarifications.
Thankshttps://lab.civicrm.org/dev/core/-/issues/642New Contact Report: New report isn't created automatically when the user sele...2022-09-25T05:03:22ZPradeep Nayakpradpnayak@gmail.comNew Contact Report: New report isn't created automatically when the user selects the "Create Report" action**Steps:**
* Click "View contact record"
* Click "Contacts" > "Contact Reports"
* Click "New Contact Report"
* Open the "Constituent Report (Summary)" report
* Select some check boxes
* Open the 'Actions' drop-down
* Select 'Create Rep...**Steps:**
* Click "View contact record"
* Click "Contacts" > "Contact Reports"
* Click "New Contact Report"
* Open the "Constituent Report (Summary)" report
* Select some check boxes
* Open the 'Actions' drop-down
* Select 'Create Report'
**Actual result:** New report isn't created automatically.
**Expected result:** E.g. here is a pop-up for choosing new report name when the user selects the "Create Report" action.
![Report](/uploads/78a81c246ef230dd6d4ed9b4cc7b9a61/Report.gif)https://lab.civicrm.org/dev/core/-/issues/643Nested call to api.delete runs twice2019-01-05T20:47:10ZeileenNested call to api.delete runs twiceA recent change to use an exception has exposed a bug in the api kernal
A unit test is running
```
$contribution = $this->callAPISuccess('contribution', 'getsingle', array(
'id' => $contribution['id'],
'api.contributio...A recent change to use an exception has exposed a bug in the api kernal
A unit test is running
```
$contribution = $this->callAPISuccess('contribution', 'getsingle', array(
'id' => $contribution['id'],
'api.contribution.delete' => 1,
));
```
However the delete action is being called TWICE - the second time it is failing - looking at the kernal it is run from the respond line as well as the invoke line in the kernel
```
public function runRequest($apiRequest) {
$this->boot($apiRequest);
$errorScope = \CRM_Core_TemporaryErrorScope::useException();
list($apiProvider, $apiRequest) = $this->resolve($apiRequest);
$this->authorize($apiProvider, $apiRequest);
$apiRequest = $this->prepare($apiProvider, $apiRequest);
$result = $apiProvider->invoke($apiRequest);
return $this->respond($apiProvider, $apiRequest, $result);
}
```
See ![Screenshot_2019-01-05_10.28.35](/uploads/13bed61a0c4b79909cbf95181626c568/Screenshot_2019-01-05_10.28.35.png)
And ![Screenshot_2019-01-05_10.27.38](/uploads/d56e3c8930acbacffcd44ad761f43bf2/Screenshot_2019-01-05_10.27.38.png) after it returns from invoke
I have been fighting with delete related issues on unit tests in extendedreports - I don't know if they relate5.11https://lab.civicrm.org/dev/core/-/issues/644"From" address on membership renewal notices is wrong2019-03-13T23:50:20ZJonGold"From" address on membership renewal notices is wrongFound on [Stack Exchange](https://civicrm.stackexchange.com/q/27905/12). I don't think this is replicable on the demo server because you need to be able to send email to replicate.
### Steps to Replicate
* If using civicrm-buildkit, en...Found on [Stack Exchange](https://civicrm.stackexchange.com/q/27905/12). I don't think this is replicable on the demo server because you need to be able to send email to replicate.
### Steps to Replicate
* If using civicrm-buildkit, enable sending mail by temporarily deleting `<buildkit-root>/app/civicrm.settings.d/100-mail.php`.
* You can still set your outgoing mail to redirect to database - but `CIVICRM_MAIL_LOG` shouldn't be defined.
* Create a new non-lifetime membership on any contact.
* Select **Renew** next to the membership.
* Check the **Send Confirmation and Receipt** checkbox.
* Pres the **Renew** button.
![Selection_752](/uploads/5e877fd67625a9ca8edcd7d3e70788ba/Selection_752.png)
### Expected Result
In the "From" header, the email should have the display name of the contact selected in **Receipt From**.
### Actual Result
In the "From" header, the email has the contact ID of the contact selected in **Receipt From**.5.11JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/645Use site email domain in place of bounce email domain for automated messages2023-09-23T05:03:26ZnishantBUse site email domain in place of bounce email domain for automated messagesHello there!!
We encountered a scenario where we can whitelist only one email domain to send emails. We want to use email domain (eg: bouncedomain.com) for bounce processing and a different one (sitedomain.com) for rest of the emails wh...Hello there!!
We encountered a scenario where we can whitelist only one email domain to send emails. We want to use email domain (eg: bouncedomain.com) for bounce processing and a different one (sitedomain.com) for rest of the emails which works fine except that do-not-reply emails use the email domain set for bounce processing (bouncedomain.com) because of which AWS SES prevent those emails to be sent.
**Current behaviour:**
1. Regular emails: example@sitedomain.com
2. Bounce emails: bounce@bouncedomain.com
3. Do-not-reply emails: do-not-reply@bouncedomain.com
**Expected behaviour:**
1. Regular emails: example@sitedomain.com
2. Bounce emails: bounce@bouncedomain.com
3. Do-not-reply emails: do-not-reply@sitedomain.com
Is there already a configuration to set that or would it be a good idea to add a field where we can set the email domain for do-not-reply emails ?
Thanks!