
Originally Posted by
matrav
Quando avrai fatto la modifica potresti mandarla anche a me o comunque renderla pubblica, credo possa interessare anche altri che magari non sono tecnicamente in grado di "arrangiarsi" come te.
Grazie e buone feste
Premessa:
1) non conosco a fondo l'architettura di Sugar, ci sto studiando,
quindi prendete con le molle quello che dico qua sotto
2) non sono un programmatore esperto, ma mi arrangio
3) la versione sulla quale ho fatto queste prove è la 5.2,
ma guardando il codice della 5.1 mi sembra del tutto uguale
(almeno per il modulo Documents che qui viene trattato)
4) mi scuso sin da ora per la lunghezza del post, non sono
riuscito a spiegarmi con meno parole.
Allora, dalle prove e dalle ricerche che ho fatto sul modulo
Documents, Sugar si comporta così (almeno mi sembra...):
supponiamo di voler aggiungere un documento, e in tempi successivi
delle revisions dello stesso.
Con Create Document inserisco i miei dati e quindi salvo.
Sugar esegue:
- l'upload di quel file, lo mette in cache/upload rinominandolo
con un suo nome interno (id)
- aggiunge un record nella tabella documents
- aggiunge un record ANCHE nella tabella document_revisions.
Consideriamo questo document come "padre" di una "famiglia" di
documents.
Ora creiamo un Document Revisions dal subpanel di quel documento "padre"
Inserisco i dati richiesti, salvo. Qui Sugar esegue:
- l'upload di quel file, lo mette in cache/upload rinominandolo
con un suo nome interno (id)
- aggiunge un record SOLO nella tabella document_revisions.
Questo document è "figlio" di quel "padre" di prima.
Ora voglio cancellare questo document, Sugar cancella TUTTA la "famiglia"
non mi permette di cancellare solo il "figlio" o solo il "padre" e questo
potrebbe essere corretto, o comunque è una scelta progettuale.
Ma come detto nei precedenti post, Sugar esegue solo una cancellazione logica
ovvero cambia il campo deleted (impostandolo = 1) nel record opportuno
nella tabella documents, NON ESEGUE la cancellazione del file fisico in
cache/upload, inoltre NON ESEGUE nemmeno la modifica al campo deleted dei
record corrispondenti nella tabella document_revisions. Questo secondo me
è un bug (secondo Voi ?) poichè in questo modo la tabella document_revisions
cresce all'infinito, nemmeno il pruneDatabase presente nello Scheduler riesce
a fare manutenzione su questa tabella.
Nella cartella modules/Documents esiste un file chiamato Delete.php; se si va a
leggere il codice presente in quel file ci si accorge che dovrebbe effettivamente
eseguire anche la cancellazione del file fisico in cache/upload, ma di fatto
questo codice NON VIENE ESEGUITO. Potete cancellare o rinominare il file
Delete.php presente in modules/Documents e Sugar non si lamenta.
Quindi, il codice che esegue l'update della tabella documents (e solo
quell'operazione), è presente da qualche altra parte, ma non ho trovato dove.
Per mettere una "pezza" al problema ho cercato qualcosa di utile nei Forums ed
ho trovato una possibile strada, che ho seguito.
In pratica ho creato un hook sulla after_delete del modulo Documents, in questo
modo:
1) Creare un file chiamato logic_hooks.php (esattamente con quel nome) in
custom/modules/Documents (se non esiste il path, createlo). Questo file deve
contenere queste righe:
PHP Code:
<?php
$hook_version = 1;
$hook_array = Array();
$hook_array['after_detele'] = Array();
$hook_array['after_delete'][] = Array(2, 'DocDelete',
'custom/modules/Documents/LogicHook.php','DocLogicHook', 'DocDelete');
?>
2) Create un file in custom/modules/Documents chiamato LogicHook.php o con
un altro nome, ma in accordo con il riferimento presente nel primo file.
Questo file deve contenere queste righe:
PHP Code:
<?php
if(!defined('sugarEntry') || !sugarEntry) die('Not A Valid Entry Point');
require_once('config.php');
require_once ('include/upload_file.php');
class DocLogicHook {
function DocDelete(&$focus, $event, $arguments) {
global $sugar_config;
// le due righe seguenti correggono quello che per me è un bug
$query = "UPDATE document_revisions SET deleted = 1 WHERE document_id = '{$focus->id}'";
$result = $focus->db->query($query, true);
//
$query = "SELECT id FROM document_revisions WHERE document_id = '{$focus->id}'";
$result = $focus->db->query($query, true);
if ($focus->db->getRowCount($result) >= 1) {
while($row = $focus->db->fetchByAssoc($result))
UploadFile::unlink_file('',$row['id']);
}
else
sugar_die("Error #1 File custom/modules/Documents/LogicHook, contact the system
administrator.");
}
}
?>
In questo modo mi sembra di aver risolto:
1) Quello che, per me, è un bug ovvero la NON cancellazione logica dei records nella
tabella document_revisions
2) La cancellazione dei file fisici "orfani" in cache/upload
Inoltre questa procedura è upgrade-safe.
Probabilmente il problema poteva essere risolto in altro modo, in particolare mi
riferisco alle funzioni che si possono aggiungere allo Scheduler, ma qualche
problemino in più sarebbe nato dal fatto che la tabella document_revisions
attualmente non viene aggiornata correttamente. Inoltre non so se fare delle
modifiche/aggiunte al file _AddJobsHere.php presente in modules/Schedulers
sia un'operazione upgrade-safe.
Se avete letto sino a qui complimenti, avete una bella resistenza, quindi
aggiungo altra benzina sul fuoco. I problemi dei file "orfani" in
cache/upload purtroppo non riguardano solo il modulo Documents, ma credo
proprio che coinvolgano anche il modulo Emails, e forse qualche altro;
se avete voglia provate a leggere qui:
http://www.sugarcrm.com/forums/showthread.php?t=39667
Questo povero jjwdesign si è ritrovato con più di 41.500 file "orfani" in
cache/upload (per parecchi Gb di spazio disco) lasciati lì dal modulo Emails.
Io da San Tommaso ho voluto provare:
- importo un'email con allegato in Sugar
- Sugar crea un record nella tabella dedicata
- mette l'allegato in cache/upload (rinominato con un suo id)
Se poi cancello quella email, Sugar cancella logicamente quel record, ma
il file fisico (che rappresenta l'allegato) se ne resta indisturbato in
cache/upload per sempre.
Speriamo che il team di sviluppatori Sugar dedichino un po' del loro tempo
alla risoluzione di questi problemi, che suppongo siano a loro già noti.
fulvio
Bookmarks