[Vtigercrm-developers] Delete records from recycle bin

[Vincenzo Bruno]

The issue with*"orphan" entities*is a significant one in*Vtiger*.

The core framework does*not*check related entities, leaving 
them*orphaned*when deleting or*unlinking*the parent.

For example, deleting a*Project*leaves its*Project Tasks*orphaned. The 
same applies to its*comments, documents, activities, etc.*

We implemented a*workaround*for this with a*custom handler*that 
catches|beforedelete|and|beforeunrelate|events. If entities are related 
via a*mandatory field*, then*delete*and*unrelate*operations 
are*blocked*. In the previous example, the*Project*field in*Project 
Task*entities is mandatory, so deleting a*Project*with at least*one 
task*is prevented.

The next step is to*enable forced deletion*by adding a*"delete on 
cascade"*checkbox. However, we are concerned about potential*circular 
dependencies*in custom modules or complex entity configurations.

All of this*functionality*should be added to*Vtiger's core*and should*at 
least*work in*core modules*. Our current code is a*"quick & 
dirty"*solution that works for us, but it needs*cleanup and 
generalization*before being submitted as a*Merge Request (MR)*.

Moreover, there is another issue with the*Recycle Bin*when activated:

  *

    Deleting a parent entity marks it as*deleted*, but*related fields
    are not cleared*until the Recycle Bin is emptied.

  *

    For example, in*Projects*, you still see a*link to the deleted
    Project*in a*Task*, but clicking on it throws an error.






Il 16/07/25 11:31, Alan Lord ha scritto:
> Anyone got any thoughts on cleaning the crmentityrel table?
>
> I think maybe this would be better to include in the delete code in 
> the recycle bin model, e.g.
>
> "DELETE FROM vtiger_crmentityrel WHERE (module = ? AND crmid = ?) OR 
> (relmodule = ? AND relcrmid = ?)"
>
> Are there any potential issues with removing rows from this table? 
> Otherwise it is just going to keep on growing as far as I can tell...
>
> But then we get into the others too: seactivityrel,
>
> Cheers
>
> Al
>
> On 08/07/2025 09:29, Alan Lord wrote:
>> I've been working with the customer on this and we have created a 
>> constraint for our custom table linked to the crmentity(crmid).
>>
>> But whilst we were discussing this I also thought about the 
>> crmentityrel table. This is now really quite large and I suspect a 
>> lot of rows in this are "orphan"... When I ran a query to list any 
>> constraints for this table I found none. Perhaps some performance 
>> improvement could be found it was cleaned up?
>>
>> Question is: Should there be a "delete on cascade" constraint on that 
>> table or not?
>>
>> Thanks
>>
>> Al
>>
>>
>>
>> On 04/07/2025 09:59, Alan Lord wrote:
>>> A customer just asked me about this...
>>>
>>> When they remove some records from the Recycle bin for a custom 
>>> module, the entry in crmentity is removed, but the rows in the 
>>> module's own tables are not deleted.
>>>
>>> Looking at the Module Model for the Recycle Bin I can see why:
>>>
>>> https://code.vtiger.com/vtiger/vtigercrm/-/blob/master/pkg/vtiger/ 
>>> modules/RecycleBin/modules/RecycleBin/models/Module.php#L147
>>>
>>> So my question is really about foreign key constraints.
>>>
>>> When we create a new module, should the vtlib code be adding a 
>>> foreign key constraint and a on delete cascade?
>>>
>>> https://code.vtiger.com/vtiger/vtigercrm/-/blob/master/vtlib/Vtiger/ 
>>> ModuleBasic.php?ref_type=heads#L294
>>>
>>> Thanks
>>>
>>> Al
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/
>>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>
>
> _______________________________________________
> http://www.vtiger.com/

-- 
Vincenzo Bruno
Coopyleft -www.coopyleft.it
tel: 3287252923
Digital Polis (www.digitalpolis.it)
Hacklab Cosenza (www.hlcs.it)
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20250716/8c0e373a/attachment.html>