CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-10T05:03:23Zhttps://lab.civicrm.org/dev/core/-/issues/3708Feature request - Add link type to case activity setup2024-03-10T05:03:23ZkristinecFeature request - Add link type to case activity setupOverview
----------------------------------------
In CiviCase, create an option to add an internal/external link on the list of activity types.
Example use-case
----------------------------------------
1. Click on **Administer -> CiviC...Overview
----------------------------------------
In CiviCase, create an option to add an internal/external link on the list of activity types.
Example use-case
----------------------------------------
1. Click on **Administer -> CiviCase -> Case Types -> Edit Housing Support**.
2. Click on **Activity Types** tab
Current behaviour
----------------------------------------
Currently, admins can only add activity types in civicrm (using the "Add activity type" dropdown).
Proposed behaviour
----------------------------------------
Admin users could really benefit from an "add link type" setting. I propose two fields: title and path/url. This would allow admins to link to webforms/afforms in the future for additional data entry but leveraging their features (e.g., conditional fields, layout control, etc.). For example, user clicks on a case and in the dropdown, sees "Benefits Evaluation", but this is an internal path link rather than a civicase form.
Comments
----------------------------------------
Not sure if this would be considered an extension or part of civicore. Also, wouldn't mind marking this as a paid issue in case others might be interested in contributing![Link_Type](/uploads/fb77e6502f97f54e0ef323cd6abaf71e/Link_Type.png).https://lab.civicrm.org/dev/core/-/issues/2983On "My Contact Dashboard", what is the Manage Case link in the relationships ...2024-02-26T05:03:22ZDaveDOn "My Contact Dashboard", what is the Manage Case link in the relationships section supposed to do?At civicrm/user, in the relationships section, if you have a relationship to a case there's a link under More at the right that says Manage Case. But clicking it does nothing. Also there's an error on the page because it's trying to crea...At civicrm/user, in the relationships section, if you have a relationship to a case there's a link under More at the right that says Manage Case. But clicking it does nothing. Also there's an error on the page because it's trying to create the link as CRM_Core_Action::NONE but there is no offset 0 in the $links array, but I'm not sure if that's the full reason it fails.
It looks like it's supposed to do a popup-y version of manage case? Except it looks like the link if it were working would be e.g. civicrm/case/ajax/details?caseId=1&cid=3&snippet=4, which just gives a little table.
I'm just wondering if it's worth trying to fix or to just remove it. I have no idea when it broke - never even knew it existed.https://lab.civicrm.org/dev/core/-/issues/3454Migrate hook_civicrm_caseTypes to hook_civicrm_managed2024-01-26T05:03:29ZtottenMigrate hook_civicrm_caseTypes to hook_civicrm_managedOverview
---------
Since v4.x, `hook_civicrm_caseTypes` has provided a way to register a case-type using a stored file from an extension. `hook_civicrm_managed` was recently expanded (#3429 for 5.50) in a way that appears to provide a s...Overview
---------
Since v4.x, `hook_civicrm_caseTypes` has provided a way to register a case-type using a stored file from an extension. `hook_civicrm_managed` was recently expanded (#3429 for 5.50) in a way that appears to provide a superset of the functionality. During review of @herbdool's https://github.com/civicrm/civicrm-core/pull/23313, @colemanw suggested deprecating `hook_caseTypes` in favor of `hook_managed`.
This issue is to identify the steps/phases of a migration.
Pro/Con
---------
* Reasons to transition `hook_civicrm_caseTypes` => `hook_civicrm_managed`
* They support the same use-case. Having more than one way to do the same thing can be confusing.
* `hook_managed` is more generic. You get more utility/leverage from understanding it.
* `hook_managed` has more options vis-a-vis lifecycle, cleanup, etc.
* Reasons not to transition `hook_civicrm_caseTypes` => `hook_civicrm_managed`
* If it ain't broke, don't fix it.
* `hook_caseTypes` has multiple mappings which appear to work together (ie `CRM_Case_ManagedEntities`: `CaseTypes`,`ActivityTypes`,`RelationshipTypes`).
* This specific application of `hook_managed` is new. Needs more usage to see if it's fit-to-purpose.
Transition Path
---------------
IMHO, the transition would look something like this:
* Near term / Phase 1
* Do some testing around extension lifecycle/upgrades - eg if you upgrade an extension (*getting a new CaseType `definition` that adds, edits, removes some ActivityType*), then... do the interdependent things update properly? What happens if you've edited the `ActivityType` locally or added another `ActivityType`? Do policies like `cleanup=>unmodified` or `cleanup=>unused` actually work? (*I expect these to be somewhat sensible, since each part seems to have satisfactory precedent; but I encourage playing with it during QA, since this is a bit unusual and it's important to the story of "managed CaseType".*) Perhaps publish an example extension that shows that the technique is fit-for-purpose.
* Mid-term / Phase 2
* Add some docs which tell the story of exporting via `civicrm/api4` -- eg an alternative to https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type
* Try doing a conversion from `xml/case/*.xml` to `*.mgd.php`. Make sure that IDs/FKs (`case_type_id`, `activity_type_id`, etc) are stable.
* Remove https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type and maybe `civix generate:case-type` (Leave a pointer to the new docs.)
* Update `CRM_Case_ManagedEntities` and/or `mixins/case-xml` to emit a warning. Encourage folks to convert to `mgd`.
* (*Stretch goal*) Add a step to `civix upgrade` to auto-convert `*.xml` to `*.mgd.php` (or at least show a warning about the XML files). (See also: https://github.com/totten/civix/tree/master/upgrades)
* Long-term / Phase 3
* Remove `hook_caseTypes` aka `mixins/case-xml` from core
* Remove `hook_caseTypes` aka `mixins/case-xml` from civixhttps://lab.civicrm.org/dev/core/-/issues/3429API4: Make CaseType a managed entity2024-01-24T14:08:18ZherbdoolAPI4: Make CaseType a managed entityOverview
----------------------------------------
Allow CaseType to be a managed entity so it can be exported via api4.
Example use-case
----------------------------------------
1. Go to `/civicrm/api4`
1. Select CaseType and Export
C...Overview
----------------------------------------
Allow CaseType to be a managed entity so it can be exported via api4.
Example use-case
----------------------------------------
1. Go to `/civicrm/api4`
1. Select CaseType and Export
Current behaviour
----------------------------------------
Cannot export and use as a managed entity.https://lab.civicrm.org/dev/core/-/issues/3129The way the Most Recent Activity column on Find Cases is calculated makes no ...2023-12-04T05:03:27ZDaveDThe way the Most Recent Activity column on Find Cases is calculated makes no senseIt shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do no...It shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do not have recent activity. For those cases, the column displays blank, when it really should simply display the most recent activity, whenever it was.
To reproduce, create a case and complete an activity. Wait 2 weeks. Then do a find cases and look at the Most Recent Activity column for that case.
Does Find Cases even need this column?https://lab.civicrm.org/dev/core/-/issues/4797A regression? Can't assign case role in CiviCase2023-11-23T13:15:28ZtomrosenbloomA regression? Can't assign case role in CiviCaseI'm not able to assign (or re-assign) a case role to a case in CiviCase in the latest version - I can do this in our live Civi (5.64.4) but not in latest version 5.69.alpha1 either running locally or on the dmaster demo site.
Expected b...I'm not able to assign (or re-assign) a case role to a case in CiviCase in the latest version - I can do this in our live Civi (5.64.4) but not in latest version 5.69.alpha1 either running locally or on the dmaster demo site.
Expected behaviour:
1. create case, or find existing case in dashboard
2. click Manage, then expand Roles pane
3. click pencil icon next to a role
4. in dialogue box 'Assign <role>', select a contact using autocomplete
Current behaviour:
as above until step 4, where the dialogue box is broken - seems to be a plain text input instead of autocomplete, and dialogue cannot be dismissed with Save or Cancel.https://lab.civicrm.org/dev/core/-/issues/4770When adding a follow up activity on an existing case activity with multiple a...2023-11-15T16:16:35ZErikHommelWhen adding a follow up activity on an existing case activity with multiple assignees only one is savedOverview
----------------------------------------
When I add a follow up activity on an existing activity in a case (does not happen on non-case activities) and add more than 1 assignee, only the first assignee is actually saved on the a...Overview
----------------------------------------
When I add a follow up activity on an existing activity in a case (does not happen on non-case activities) and add more than 1 assignee, only the first assignee is actually saved on the activity.
Reproduction steps
----------------------------------------
1. Find an existing case activity
2. Add a follow up activity with multiple assignees
3. Hit save
Current behaviour
----------------------------------------
Only the first assignee is saved
Expected behaviour
----------------------------------------
All assignees should be saved
Environment information
----------------------------------------
CiviCRM 5.66.05.69.0ErikHommelErikHommelhttps://lab.civicrm.org/dev/core/-/issues/2875CiviCase Forces Case Status to Resolved (Closed) when all Activities in a Seq...2023-09-30T05:03:30ZpbarmakCiviCase Forces Case Status to Resolved (Closed) when all Activities in a Sequence are CompleteOverview
----------------------------------------
For Cases that use a Sequence, once all activities in the sequence are complete, the Case gets set to a Resolved (aka Closed) status. This is fine. However, after a Case is in the Resolve...Overview
----------------------------------------
For Cases that use a Sequence, once all activities in the sequence are complete, the Case gets set to a Resolved (aka Closed) status. This is fine. However, after a Case is in the Resolved status, if a user then wishes to change the status to something other than Resolved (like to a custom status), even though CiviCase says it made the change and even creates a status change activity that shows the status was changed, the case remains in Resolved status.
It looks like Civi/CCase/SequenceListener.php is firing after any case status changes are written to the DB, but SequenceListener is not accounting for someone purposefully trying to change the case status. It only looks for all activities being completed and forces the case back to Resolved.
This doesn't seem like correct behavior nor a good user experience. The listener should check to see if the action was a status change action and not fire the API call in that case. I'm not sure how that can be done (not sure what input the listener has), but that's my guess on how to resolve the issue.
Reproduction steps
----------------------------------------
1. Create a Case Type that uses a sequence of activities (doesn't matter how many)
1. Create a new Case using that type
1. Complete each activity in the sequence and see that the Case automatically changes to Resolved.
1. Try to then change the Case Status to something other than Resolved (like In Progress or Ongoing or any custom status).
1. See that the Case status remains as Resolved, even though a new case activity says it was changed.
Expected behaviour
----------------------------------------
The Case should allow a change in Status even if all Activities in a Sequence are completed. That way user can change to a custom status that also reflects completion (we have multiple status that denote completion but for a variety of reasons).https://lab.civicrm.org/dev/core/-/issues/2841Undefined index isCaseActivity when creating an activity2023-09-24T05:03:25ZDaveDUndefined index isCaseActivity when creating an activityThis is probably from one of the message template rearrangings. For the email it sends to the activity assignee.This is probably from one of the message template rearrangings. For the email it sends to the activity assignee.https://lab.civicrm.org/dev/core/-/issues/2818Context gets lost when sending an email from manage case so it redirects some...2023-09-24T05:03:25ZDaveDContext gets lost when sending an email from manage case so it redirects somewhere else afterI think this is the same cause as https://lab.civicrm.org/dev/core/-/issues/2318 where something about `$this->_single` went missing. It should redirect you back to manage case.
1. Turn off popups at administer - customize - display pre...I think this is the same cause as https://lab.civicrm.org/dev/core/-/issues/2318 where something about `$this->_single` went missing. It should redirect you back to manage case.
1. Turn off popups at administer - customize - display prefs (or when opening the link in step 3 open in a new tab).
1. Create case
1. In the roles section use the email icon to send an email to e.g. the client
1. After sending, it goes somewhere else instead of manage case. Sometimes it will take you to the contact record which at least is related, sometimes it goes to /civicrm/dashboard, sometimes somewhere else.https://lab.civicrm.org/dev/core/-/issues/3722CaseType managed entity in mgd.php file gets caught in an infinite loop2023-09-16T13:59:04ZherbdoolCaseType managed entity in mgd.php file gets caught in an infinite loopOverview
----------------------------------------
When using mgd.php file for a CaseType managed entity it creates an infinite loop when flushing the cache (which is when managed entities get checked). In `CRM_Case_BAO_CaseType::add()` ...Overview
----------------------------------------
When using mgd.php file for a CaseType managed entity it creates an infinite loop when flushing the cache (which is when managed entities get checked). In `CRM_Case_BAO_CaseType::add()` it calls `CRM_Core_ManagedEntities::scheduleReconciliation()` which seems to create the loop.
Some chat here https://chat.civicrm.org/civicrm/pl/pmcn6sa9zpboigkh7f4ukxt8yr
Reproduction steps
----------------------------------------
1. Create a new Case Type in the UI.
1. Go to API4 and export the Case Type to PHP definition.
1. Save to mgd.php file in an extension.
2. Delete the custom case type.
3. Enable the extension and flush cache (`cv flush`).
Current behaviour
----------------------------------------
Gets caught in an infinite loop, where it keeps trying to create the same case type (as I've noticed when going over it in XDebug).
Expected behaviour
----------------------------------------
Just create it once and stop.
Environment information
----------------------------------------
* __CiviCRM: 5.50.0 and uphttps://lab.civicrm.org/dev/core/-/issues/1375Export from Find Cases search results gives E_NOTICE and E_WARNING when using...2023-09-09T05:03:23ZDaveDExport from Find Cases search results gives E_NOTICE and E_WARNING when using selected fieldsNot sure when it started, just noticed it now while reviewing a PR. Can reproduce on dmaster.demo.
```
Notice: Undefined index: Select in HTML_QuickForm_Controller->exportValues() (line 495 of /srv/buildkit/build/dmaster/web/sites/all/m...Not sure when it started, just noticed it now while reviewing a PR. Can reproduce on dmaster.demo.
```
Notice: Undefined index: Select in HTML_QuickForm_Controller->exportValues() (line 495 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php).
Warning: Invalid argument supplied for foreach() in HTML_QuickForm_Controller->exportValues() (line 495 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php).
```
TBDhttps://lab.civicrm.org/dev/core/-/issues/2672CiviCase Case Type blank2023-08-29T05:03:26ZgcpowerCiviCase Case Type blankOverview
----------------------------------------
_Please describe your problem or bug in detail._
I have a new local install. I enabled CiviCase and checked permissions - all OK. I installed CiviCase and attempted to add a new case ...Overview
----------------------------------------
_Please describe your problem or bug in detail._
I have a new local install. I enabled CiviCase and checked permissions - all OK. I installed CiviCase and attempted to add a new case type and a blank screen was shown. It also froze any further activity. I deleted url up to civicrm and function restored. I flushed caches and ran rebuild.php still the same error.
Reproduction steps
----------------------------------------
1. Disable CiviCase
2. Flush caches
3. Enable CiviCase
4. Select Administer/CiviCase/Case Type
5. Blank screen and following url shown http://localhost:8891/drupal_8/web/civicrm/a#
6. System freezes and /a# removed
7. System restored
Current behaviour
----------------------------------------
No error messages shown on Drupal log file, but in Develop on Safari 404 shown when accessing CiviCRM /drupal_8/web/libraries/civicrm/core//bower_components/dc-2.1.x/dc.min.js.map```
Three 404 errors displayed when accessing Case type
/drupal_8/web/libraries/civicrm/core/bower_components/angular-file-upload/angular-file-upload.min.map```
/drupal_8/web/libraries/civicrm/core/bower_components/angular-sanitize/angular-sanitize.min.js.map```
/drupal_8/web/libraries/civicrm/core/bower_components/angular-route/angular-route.min.js.map```
```
Expected behaviour
----------------------------------------
_What should happen._
When accessing Case Types, I expect the two existing types to be displayed and an add new option is available to add more types
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Safari 14.1.1
* __CiviCRM:__ _Master/5.38.0 <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.3.24__
* __CMS:__ _Drupal 8.9.16_
* __Database:__ _MySQL 5.7.32_
* __Web Server:__ _Apache 2.4.46/Nginx 2.7.13/..._
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/2655Incorrect date format displayed on custom activity field2023-08-27T05:03:15ZAndy ClarkIncorrect date format displayed on custom activity fieldA date and time was added as a custom field to an activity type. The format for dates is d MM y with a 12 hour format, which is how the activity date displays. However the custom date displays as YYYY-MM-DD HH-MM-SS. See [this SE](http...A date and time was added as a custom field to an activity type. The format for dates is d MM y with a 12 hour format, which is how the activity date displays. However the custom date displays as YYYY-MM-DD HH-MM-SS. See [this SE](https://civicrm.stackexchange.com/questions/39781/activity-custom-date-format-display-incorrect) problem. Civi release level is 5.37.2https://lab.civicrm.org/dev/core/-/issues/1401Meta ticket for issues related to problems with closed cases2023-08-23T05:03:20ZDaveDMeta ticket for issues related to problems with closed casesJust trying to collect it all in one place.
## Open or Closed-but-Unmerged work:
Print Report for closed cases doesn't show the roles
* https://lab.civicrm.org/dev/core/-/issues/2441
* https://lab.civicrm.org/dev/core/-/issues/1948 (Re...Just trying to collect it all in one place.
## Open or Closed-but-Unmerged work:
Print Report for closed cases doesn't show the roles
* https://lab.civicrm.org/dev/core/-/issues/2441
* https://lab.civicrm.org/dev/core/-/issues/1948 (Related but for open cases, but is probably the same underlying reason.)
## Merged or sort of related:
Case manager not displayed for closed cases
* https://lab.civicrm.org/dev/core/issues/542 (**description includes a proposed idea that was never worked on**)
* https://civicrm.stackexchange.com/questions/27215/case-roles-on-closed-cases
* https://github.com/civicrm/civicrm-core/pull/13144
* https://github.com/civicrm/civicrm-core/pull/13831
* https://lab.civicrm.org/dev/core/-/issues/1947 (**contains some analysis and possibly more general long-term solution**)
Better handle Case Manager and roles on closed cases
* https://github.com/civicrm/civicrm-core/pull/13510
* https://github.com/civicrm/civicrm-core/pull/19737 (merged as a forms-level improvement)
* dev/core#500 Fix user-specific Case filtering on dashboard and searches to exclude cases from inactive relationships
* https://github.com/civicrm/civicrm-core/pull/13134
* Users with 'view own cases' permission can't open resolved cases
* https://lab.civicrm.org/dev/core/issues/1400
* https://civicrm.stackexchange.com/questions/33742/users-with-view-own-cases-permission-cant-access-resolved-cases
## Memory might be hazy:
* To-find: There's an earlier one somewhere about whether people want to see closed cases on dashboard.
* To-find: Something about different opinions on whether "closed" is like "disabled" when searching for cases and so some people don't want to even see it.https://lab.civicrm.org/dev/core/-/issues/2441Print Report from Manage Case for closed cases doesn't show roles properly2023-07-06T05:03:18ZDaveDPrint Report from Manage Case for closed cases doesn't show roles properlyIt's not identical to https://lab.civicrm.org/dev/core/-/issues/1948 but might be the same underlying reason.
1. Create a case.
2. Add some roles.
3. Close the Case.
4. Choose Print Report on Manage Case.
5. Look at the roles near the t...It's not identical to https://lab.civicrm.org/dev/core/-/issues/1948 but might be the same underlying reason.
1. Create a case.
2. Add some roles.
3. Close the Case.
4. Choose Print Report on Manage Case.
5. Look at the roles near the top - they should be there.
Ditto for the Activity Audit which is the same codebase as Print Report.https://lab.civicrm.org/dev/core/-/issues/2209Activities can't be moved to a Case re-opened by the API2023-06-02T05:03:18ZjhungerfordActivities can't be moved to a Case re-opened by the APIOverview
----------------------------------------
When the API sets a Case to an Open status, it does not clear the end date. When moving an Activity to a Case, the filter for the list of available cases requires the end date to be null....Overview
----------------------------------------
When the API sets a Case to an Open status, it does not clear the end date. When moving an Activity to a Case, the filter for the list of available cases requires the end date to be null. If a case has been closed and then reopened by the API (e.g. by filling out a webform which sets the case status), it will still have an end date, so it will not be available in this list.
The end date is not visible to the user, so there's no visual indication of why Cases reopened in this manner behave differently.
Reproduction steps (using the demo database)
----------------------------------------
1. Choose or create a Contact with at least one Activity
2. Create a Case for this Contact
3. Set the Case status to Resolved using the UI or API
4. Use the API explorer to set the status of that Case to Ongoing
5. Go to the Contact's summary screen and click on Activities
6. Choose any suitable Activity, click "File on Case"
7. Search for the newly reopened Case and note that it does not appear in the list
Current behaviour
----------------------------------------
A Case can have an Open status and an end_date, meaning it is not possible to move Activities to that Case, and the reason isn't visible to the user.
* The API and webform-civicrm do not clear the end date when setting a case to an Opened status class
* The code which filters the list of available Cases when moving an Activity (example [here](https://lab.civicrm.org/dev/core/-/blob/5.32/CRM/Case/Form/ActivityToCase.php#L96-107)) finds Open cases according to these criteria:
```
'case_id.is_deleted' => 0,
'case_id.status_id' => ['!=' => "Closed"],
'case_id.end_date' => ['IS NULL' => 1],
```
There are at least two other places which implement this logic (one in the same file, another [here](https://lab.civicrm.org/dev/core/-/blob/5.32/CRM/Case/BAO/Case.php#L2383-2388)).
Expected behaviour
----------------------------------------
If a Case has an Open status, it should be possible to move Activities to that Case.
There are several places where this could be addressed, but I think the filter shown above should check the status class, and probably should not check the end_date at all.
If it does check the end_date:
* Either the API or webform-civicrm should clear the end date (if it's in the past) when setting a Case to an Opened status
* If this is done by webform-civicrm, should it also create the Changed Status activities which would have been created if the Case were re-opened through the normal UI?
* Should the filter include Cases with future end dates as well as null end dates?
Environment information
----------------------------------------
* __CiviCRM:__ Discovered on 5.27.5, tested on 5.33.alpha1
* __CMS:__ Drupal 7.74
* __webform-civicrm:__ tested on 7.x-5.1 and 7.x-5.3
Comments
----------------------------------------
I can see reasons why the API might not want to clear the end date for a reopened Case, and how webform-civicrm is simply passing the submitted values along to the API. It's not clear which part of the system should be responsible, and I'm guessing most sites don't encounter this issue.
We considered using a CiviRule to do some extra processing when the Case status changes, but when attempting to configure this it fails with "Entity Case does not implement status condition". We can probably solve this by writing a custom CiviRule trigger (or maybe upgrading CiviRules), but it also seems like the core logic could be improved.
I've tested a patch locally which doesn't look at the end date when filtering the list of Cases in this context, and which looks for the Opened status classes by first fetching them like so:
```
$openStatuses = array_keys(CRM_Case_PseudoConstant::caseStatus('value', TRUE, "AND grouping = 'Opened'"));
```
Looking at the current code, I'm wondering whether this is checking the status class without needing to fetch the list first:
```
'case_id.status_id' => ['!=' => "Closed"],
```https://lab.civicrm.org/dev/core/-/issues/2212Case # in email subject2023-05-31T05:03:20ZErikHommelCase # in email subjectSee this StackExchange post:
https://civicrm.stackexchange.com/questions/7791/case-id-in-e-mails-from-case
A "cleaner" solution seems desirable. Happy to take this on board but what would be the best method? I can think of:
- sticking t...See this StackExchange post:
https://civicrm.stackexchange.com/questions/7791/case-id-in-e-mails-from-case
A "cleaner" solution seems desirable. Happy to take this on board but what would be the best method? I can think of:
- sticking the case_id in the session and adding the activity if this is present in the session?
- adding a temp table and writing the case_id to that table and removing it in the activity processing?
Advice is welcome :-)ErikHommelErikHommelhttps://lab.civicrm.org/dev/core/-/issues/2134Order of custom groups not correct2023-05-21T05:03:17ZxavierOrder of custom groups not correctOverview
----------------------------------------
When editing a case, the order of custom groups isn't correct (doesn't respect weight)
Reproduction steps
----------------------------------------
1. Create a new custom group for a cas...Overview
----------------------------------------
When editing a case, the order of custom groups isn't correct (doesn't respect weight)
Reproduction steps
----------------------------------------
1. Create a new custom group for a case "second"
2. Create a new custom group for a case "first"
3. change the order (weight) so "first" is before "second"
4. create a new case
Current behaviour
----------------------------------------
the custom groups are sorted by id, not by weight
Expected behaviour
----------------------------------------
The custom groups are sorted by weight
Environment information
----------------------------------------
Out of the box normal civi. Do you want me to create a test case on demo?
Comments
----------------------------------------
I spent a few hours drilling through the code, getTree (CRM/Core/BAO/CustomGroup.php) returns the groups properly sorted
but groupTree in templates/CRM/Custom/Form/CustomData.tpl isn't ;(
in CRM/Core/BAO/CustomGroup.php::buildQuickForm
$groupTree is correct (with the correct order)
but $form->assign_by_ref("{$prefix}groupTree", $groupTree);
ends up with the groupTree being re-ordered in smarty?
I'm a bit confused as when the order of the custom block is defined, but I'm pretty keen on having it respecting the weight/sort order ;)https://lab.civicrm.org/dev/core/-/issues/2080Deduping contacts creates a copy of the case instead of moving the case2023-05-17T05:03:27ZjaapjansmaDeduping contacts creates a copy of the case instead of moving the caseWhen you dedupe contacts who have a case. A copy of the case is created and the original case is marked as deleted.
**How to reproduce**
1. Create a contact with name Donald A
2. Create a case for this contact
3. Create a contact with n...When you dedupe contacts who have a case. A copy of the case is created and the original case is marked as deleted.
**How to reproduce**
1. Create a contact with name Donald A
2. Create a case for this contact
3. Create a contact with name Donald B
4. Merge Donald A with Donald B and move the cases to Donald B
**Expected result**
In the database I would expect one case
**Actual result**
In the database there are now two cases.
**Work around**
I have created an extension as a work around for this flaw: https://lab.civicrm.org/extensions/mergecaseandkeepid