Merge function for Accounts orphans related Cases

Hi,

We currently use Enterprise v11.0.3 but we have found this bug. The system orphans related records when merging. Looking at the portal, this was identified in v7.8 (2017-02-17).

What is the status of this bug? It seems quite a significant issue, has anyone else noticed this?

Kind regards john

Status
New
Priority
High
Type
Defect
Sugar Edition
Found In Release
7.8.0.0
Fixed In Release
Product
Sugar (CRM application)
Resolution
Product Category
Merge Duplicates
Date Created - 2017-02-17 21:26
Private Bug

Date Modified
2022-04-12 22:01
Description
Steps to reproduce:
In Sugar 7.8.0.0
- Create two Accounts, Company A and Company B
- Create 5 Cases related to Company A
- Create 105 Cases related to Company B
- Merge Company B into Company A from Accounts listview

Expected results:
Post merge Company A has 110 related Cases.

Actual results:
Post merge Company A has less than 110 related Cases. In testing this was 94 but the number can vary.

Notes:
Looking at the cases table in the database reveals that the account_id field on the missing cases is NULLless

Parents
  • Hi John and Julia -

    I looked into bug 78302 and it has been recently escalated. I'll keep an eye on it to make sure it does not lose focus or priority.

    For now if you plan to merge accounts that have > 75 related records, please contact support to coordinate any needed post merge cleanup. We can identify the orphaned related records by date_modified and then manually set these to the correct account_id. Alternately this could also be done through the UI by filtering for records without a related account and then mass updating these. 

  • Identifying records by date modified on a large system runs the risk that some data will be included that just happens to have been modified at the same time. It's a low risk, but the consequences may be severe depending on rules around visibility etc.

    Selecting records missing a link may also not be ideal for certain record types where a link is not always required - the result would be a single record linked to all prior orphans.

    Arguably, due to Sugar blotting out the link id on foreign key relationships during a parent deletion event, the only way to be absolutely certain of data consistency would be to refer to a backup - a luxury that may not be available to some system admins depending on when they spot the consequences of this bug.

    In short: this bug permanently deletes data in a way that may require costly and time consuming investigation to recover, with no absolute guarantees of full restoration.

    P.S. 75 records may not be the trigger point - depending on factors such as network speed, it may be considerably lower (over 40).

Reply
  • Identifying records by date modified on a large system runs the risk that some data will be included that just happens to have been modified at the same time. It's a low risk, but the consequences may be severe depending on rules around visibility etc.

    Selecting records missing a link may also not be ideal for certain record types where a link is not always required - the result would be a single record linked to all prior orphans.

    Arguably, due to Sugar blotting out the link id on foreign key relationships during a parent deletion event, the only way to be absolutely certain of data consistency would be to refer to a backup - a luxury that may not be available to some system admins depending on when they spot the consequences of this bug.

    In short: this bug permanently deletes data in a way that may require costly and time consuming investigation to recover, with no absolute guarantees of full restoration.

    P.S. 75 records may not be the trigger point - depending on factors such as network speed, it may be considerably lower (over 40).

Children
No Data