rrd108 / sanga

CRM
GNU General Public License v2.0
1 stars 6 forks source link

duplicates #115

Open rrd108 opened 9 years ago

rrd108 commented 9 years ago

A CRM-ek egyik fontos szolgáltatása a duplikáció szűrés. Ez több dolog miatt is problémás: egyrészt más formátumban megadott adatok pl 06/30 vagy +36 30 egy telefonszámnál, másrészt amiatt, hogy egy kapcsolatot több kapcsolattartó is felvihet és nem feltétlenül látnak rá egymás adataira.

Az első problémakörre általánosan alkalmazott megoldások kikényszerítik, hogy egy adott formátumban legyenek felvíve az adatok amit én nem szeretek. A magam részéről jobban szeretem ha a program okos és megeszik mindent amit a user bekalapál.

Na szóval a /src/Model/Table/ContactsTable.php tartalmaz egy pár metódust amelyek nevei checkDuplicates-cel kezdődnek. Ezeket kéne átpakolni a /src/Shell/DuplicateFilterShell.php fileba mert menet közben rájöttem, hogy ezt úgy is cronnal fogjuk csekkolni naponta.

  1. Ellenőrizni kell userenként, hogy azok között a contactok között akiknek ő a contact personja van-e duplikáció gyanús, azaz a checkDuplicates-ek közül valamelyik ad-e találatot, illetve ha több is ad akkor a gyanú növekszik (azaz pl stimmel a telefonszám is meg a cím is)
  2. A duplikáció gyanús esetekről kell egy új rekordot betenni a notifications táblába. Ezzel kap értesítést a user a gyanús esetről.
  3. A notification-nak tartalmaznia kell, hogy melyik contact milyen adatai miatt gyanús a duplikáció és kell bele két link. Az egyik azt mondja, hogy nem, ez nem duplikáció, a másiknak pedig az, hogy összevonom a két contactot.
  4. Ha a user a nem duplikációt választja, akkor ezt a választást valahol el kell tárolni a DB-ben, hogy legközelebb ne kínálja fel. Erre per pillanat nincs DB tábla, nem gondolkoztam még rajta. Ha otthon vagy ebben találd ki, ha nem akkor kitalálom és beteszem.
  5. Ha a user az összevonás mellett dönt akkor a két contactot össze kell vonni. Az összevonás a következőképpen történik:

5/1. A nagyobb id-jű contatnál az active flag-et 0-ra kell állítani és a commentbe bele kell írni, hogy merged with: a kisebb id-jű contact. Azaz ő az aki beleolvad a másikba.

5/2. A megszűnő skilljeit, group tagságait és history rekordjait update-elni kell a megmaradó contact_id-re.

5/3. A személes adatok esetében (ezek vannak a contacts táblában) a megszűnő contat adatait bele kell olvasztani a megmaradóba. Azaz ha pl a telefonszám egyezik akkor nem csinálunk semmit, ha a megmaradónál hiányzik az infó a megszűnőnél megvan akkor meg beleírjuk.

5/4 Ha konfliktus van, azaz pl mindkettőnél szerepel telefonszám, de az nem azonos (formátumtól függetlenül, azaz más telefonszám szerepel) akkor a megszűnő adatát a commentbe kell beleírni. Persze ezek minden adatra vonatkoznak nem csak a telefonszámra.

5/5 a historyban lehetnek duplikált adományok - erre külön figyelni kell

rrd108 commented 9 years ago

soknak tünik a vizsgálatok száma. 150 contact esetében kb 11000, 200 contactnál 19900. Nekem most 310 contact van a telefonomban, ami 47895 vizsgálatot jelentene.

rrd108 commented 9 years ago

Akkor szerintem marad az amit legelőször gondoltam, de később elvetettem. Új adat bevitelnél vagy adat módosításnál elindítunk egy másik szálon egy shell scriptet ami konkrétan a változásra vizsgál duplikációt. Ezt a ContactsTable setGeo metódusa is csinálja, jól megy, a user nem lát belőle semmit, nem lassít semmit, a háttérben történik.

rrd108 commented 9 years ago

inner joinnal filedenként 1 lekérdezéssel megoldható, már csak külön kell szedni amikor az egyezés ugyanahhoz a userhez tartozik és amikor nem

rrd108 commented 9 years ago