[Vtigercrm-developers] Delete records from recycle bin

[Alan Lord]

Great,

Can I suggest we use the ticket that is already open:

https://code.vtiger.com/vtiger/vtigercrm/-/issues/1983

I'm going to review some of the code in crmentity (and the extended code 
in the modules' class file) to see why the vtiger_relatedlists_rb 
doesn't seem to get populated or used when a recyclebin is cleared...

No big rush, just comment as and when you can.

Thanks

Al

On 22/07/2025 16:20, Vincenzo Bruno wrote:
> Hi Alan,
> 
> sure, we can collaborate on this task. At the moment we are very busy, 
> but in the next days we can start this activity.
> 
> We have to discuss which features we want to include in the VT core. Do 
> we want to discuss here or on a issue on gitlab?
> 
> Bye for now
> 
> Vincenzo
> 
> 
> 
> Il 17/07/25 10:21, Alan Lord ha scritto:
>> Thanks for the follow up Vincenzo,
>>
>> Can we not collaborate on a project in Gitlab to get a merge request 
>> ready for proper testing?
>>
>> As for your last comment about related fields, in the Cloud CRM they 
>> do clear the related fields. I just deleted an organisation that was 
>> in the Contact's Organisation field and the field was cleared. When I 
>> restore the record, the field is re-populated.
>>
>> I assumed that was was all stored in the "vtiger_relatedlists_rb" 
>> table but even though it is referenced in CRMEntity (see 
>> unlinkDependencies method) it never seems to have any data in it...
>>
>> Cheers
>>
>> Al
>>
>>
>> On 16/07/2025 15:11, Vincenzo Bruno wrote:
>>> 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
>>
>> _______________________________________________
>> http://www.vtiger.com/
> 
> -- 
> Vincenzo Bruno
> Coopyleft -www.coopyleft.it
> tel: 3287252923
> Digital Polis (www.digitalpolis.it)
> Hacklab Cosenza (www.hlcs.it)
>      
> 
> 
> _______________________________________________
> http://www.vtiger.com/