<h1>Fragen bzw. Anforderungen</h1> <p>Da wir mehrere E-Mails pro Person im FRST unterstützen ergeben sich folgende Fragen bzw. Anforderungen:</p> <p>Webformulare und externe Systeme: - Welche der E-Mail Adressen zeigen wir bei Webformularen bei denen nur eine E-Mail Adresse möglich ist - Welche der E-Mail Adressen wird für den Datenaustausch mit externen Systemen verwendet die nur eine E-Mail pro Person unterstützen.</p> <p>Datenimport - Vorgehen beim Import von extern Personendaten mit nur einem Feld &#39;email&#39; bei der Person</p> <p>E-Mail als Login bzw Identitätsnachweis? - Soll der Account/Login (res.user) unabhängig von der/den E-Mail Adressen gehalten werden - Wenn mehrere E-Mails bei einer Person hinterlegt sind: Ist es sicher allen Adressen Tokens zu senden?</p> <h1>Wichtige Info</h1> <p>Die E-Mail stellt mittlerweile so etwas wie den Primary-Key oder anders gesagt die Identität einer Person dar. Sie ist in den meisten Fällen auch der Schlüssel zu jedweden Datenzugang (z.B.: vorausgefüllte Webformulare via Token Link). Es muss Ihr daher eine besondere Aufmerksamkeit bei der Anlage, Änderung und beim Zusammenlegen zukommen.</p> <p>Folgende Regeln würden uns die Arbeit erleichtern und die System-Sicherheit wesentlich verbessern: - Personen mit unterschiedlichen (Haupt) E-Mail Adressen dürfen nicht automatisch zusammengelegt werden - Eine Änderung der Hauptemailadresse kann nur durch - einen angemeldeten Web-User (via Token-Link oder FSO-Account), - oder eine Sachbearbeiter in FRST veranlasst werden - Eine Änderung der Hauptemailadresse führt zu einem E-Mail Umzug - Der odoo Account geht IMMER auf die Hauptemailadresse - FS-Tokens werden nur für bestätigte Hauptemailadressen erzeugt und sind nur für best. HEA gültig!</p> <p>Eine Ausnahme besteht wenn wir eine neue E-Mail Adresse bekommen und die bisherige Hauptemailadressen noch keinerlei Verlinkungen (odoo Account, PersonEmailGruppe) hat und auch nicht per DOI bestätigt wurde. In diesem Fall wird die aktueller E-Mail einfach zur neuen Hauptemailadresse.</p> <h2>Erzwungene Zusammenlegung von Personen mit unterschiedlichen Hauptemailadressen</h2> <p>Werden vom FRST-Sachbearbeiter Personen mit untersch. Hauptemailadressen zusammengelegt wird versucht die verbeleibende Hauptemailadressen automatisch zu bestimmen. Ist dies nicht eindeutig möglich muss der Sachbearbeiter die Hauptemailadressen festlegen um einen Merge durchführen zu können.</p> <p>Folgende Regeln könnte man für die Bestimmung der neuen Hauptemailadresse (HEA) anwenden: 1. Nur einer der Beiden hat eine erzwungene Hauptemailadresse = neue HEA 2. Nur einer der Beiden hat einen verknüpften odoo Account = neue HEA 3. Nur einer der Beiden hat einen verknüpften odoo Account mit FS-Tokens = neue HEA 4. Nur einer der Beiden hat einen vernküfpten odoo Account mit FS-Tokens der für ein Login verwendet wurde = neue HEA 5. Nur einer der Beiden hat PersonEmailGruppen = neue HEA 6. Keine der Beiden hat eine erzwungene HEA, einen odoo Account oder PersonEmailGruppen -&gt; Die Neuere wird zur HEA 7. Keine der Regeln trifft zu = Sachbearbeiter muss HEA festlegen</p> <p>Diese Regeln werden einfach von oben nach unten durchgearbeitet! </p> <h3>Beispiel:</h3> <p>Regel 1: Person<em>A HEA und Person</em>B HEA haben beide keine erzwungene HEA = weiter zu Regel 2:\ Regel 2: Person<em>A HEA und Person</em>B HEA haben beide einen odoo Account = weiter zu Regel 3:\ Regel 3: Person<em>A HEA hat FS-Token, Person</em>B HEA hat keine = Person<em>A HEA wird zur HEA nach dem Merge Person</em>B HEA bleibt als PersonEmail erhalten da die E-Mails ja unterschiedlich sind</p> <h1>Ziele</h1> <ul> <li>Automatische Berechnung einer Hauptemailadresse</li> <li>(Todo) Manuelle (erzwungene) Festlegung der Hauptemailadresse</li> <li>Das Feld &#39;email&#39; bei res.partner stimmt immer mit dem Feld &#39;email&#39; der Haupt-PersonEmail überein</li> <li>Die Haupt-PersonEmail wird beim res.partner verlinkt (für Comfort und Kontrolle)</li> <li>Wir berechnen die Haupt-PersonEmail immer nach dem selben Schema!\ (Es gibt daher keine gesonderten Regeln je nachdem <em>woher</em> die Daten oder Datenänderungen kommen. Ob die Daten von einem Import, einer Änderung im GUI oder durch den syncer angelegt oder verändert wurden ist also irrelevant)</li> <li>PersonEmail repariert sich wenn möglich selbst (z.B.: nach einem Merge oder bei bestehenden Datenfehlern)</li> <li>(Todo) Die Ermöglichung eines Umzuges einer PersonEmail</li> </ul> <h1>Annahmen zu PersonEmail</h1> <p>Die folgenden Annahmen müssen noch von Harald und Sebastian bestätigt werden! - Das Feld &#39;email&#39; darf nach der Anlage nicht mehr geändert werden! Lediglich durch einen Umzug\ (= Merge + Delete + Double-Opt-In) sollte man eine PersonEmail ändern können - Das Feld &#39;partner<em>id&#39; darf nach der Anlage nicht geändert werden (AUSNAHME: Merge) - Nur die Felder &#39;gueltig</em>von&#39; und &#39;gueltig<em>bis&#39; und &#39;HEA erzwingen&#39; dürfen nach der Anlage noch geändert werden\ (abgesehen von berechneten Feldern wie &#39;main</em>email&#39;, &#39;state&#39; oder &#39;last<em>email</em>update&#39;) - Es gibt immer nur eine Hauptemailadresse pro Person - Eine E-Mail darf pro Person nur einmal vorhanden sein - Eine E-Mail kann mehrfach vorkommen wenn sie bei untersch. Personen zugeordnet ist</p> <h1>Informationen zur Umsetzung</h1> <p>Um die Hauptemailadresse bestimmen zu können wird das Feld &#39;last<em>email</em>update&#39; zu PersonEmail hinzugefügt. Dieses Feld ermöglicht eine Sortierung der PersonEmails einer Person. Die gültige PersonEmail mit dem neuesten &#39;last<em>email</em>update&#39; Datum ist die Hauptemailadresse.</p> <h2>Berechnung der Hauptemailadresse</h2> <p>Die Hauptemailadresse ist von &#39;last<em>email</em>update&#39; und &#39;forced<em>main</em>address&#39; abhängig. Während &#39;forced<em>main</em>address&#39; vom Benutzer oder dem System vergeben wird um die Hauptadresse zu erzwingen wird &#39;last<em>email</em>update&#39; unter folgenden Umständen aktualisiert: - Erstellung einer neuen gültigen PersonEmail (state: active) - Statusänderung einer bestehenden PersonEmail von &quot;inactive&quot; zu &quot;active&quot;?\ (&#39;gueltig<em>von&#39;, &#39;gueltig</em>bis&#39; und das Format der E-Mail Adresse müssen passen) - Falls eine Änderung am Feld &#39;email&#39; zulässig ist wird nur wenn sich die email tatsächlich verändert hat &#39;last<em>email</em>update&#39; aktualisiert. (Diese Regel kann komplett entfallen wenn wir Änderungen am Feld &#39;email&#39; nicht zulassen sondern nur den Umzug anbieten!)</p> <h2>UMZUG: Änderung einer E-Mail Adresse</h2> <p>Wird die Hauptemailadresse geändert muss eine Umzug der PersonEmailGruppe(n) und des odoo-user-logins stattfinden. Dieser könnte in etwa so aussehen:</p> <ol> <li>Änderung des Feldes email bei res.partner -&gt; Führt zu der Anlage einer neuen PersonEmail</li> <li>Anlage einer neuen PersonEmail die zur neue Hauptemailadresse wird (status: &#39;active&#39;)</li> <li>Kopie aller (nicht bereits vorhandenen) PersonEmailGruppe(n)\ WICHTIG: Aktive PersonEmailGruppe(n) (im Status active oder approved) werden mit dem Status &#39;waiting<em>for</em>email_approval&#39; erstellt, und sind daher inaktiv bis die neue E-Mail Adresse bestätigt wird.</li> <li>Aussendung einer DOI E-Mail zur Bestätigung der neuen PersonEmail (Durch FRST oder FSON)</li> <li>Nach dem Klick auf den Bestätigungslink wechselt der Status der neuen PersonEmail von &#39;active&#39; zu &#39;approved&#39;! Weiters werden alle PersonEmailGruppen im Status &quot;waiting<em>for</em>email<em>approval&quot; auf den status &#39;active&#39; oder &#39;approved&#39; geändert (je nachdem was in ihrem Feld &#39;bestaetigt</em>am_um&#39; und bei dem zugehörigen Gruppenordner für das DOI eingestellt ist)</li> </ol> <p>Falls es keine relevanten Verknüpfungen gibt kann der Bestätigungsablauf/Umzug auch übersprungen werden.</p> <h3>E-Mail UMZUG für odoo-login-user und FS-Tokens</h3> <p>Besteht für die Person (res.partner) bereits ein odoo user (Login) muss dieser beim Umzug einer E-Mail Adresse berücksichtigt werden. Es muss also - geprüft werden ob die neue E-Mail Adresse noch als login verfügbar ist - der aktuelle odoo-login gesperrt werden - alle aktuellen fs-tokens müssen gesperrt werden</p> <p>Sobald die neue E-Mail Adresse bestätigt ist wird - das login des odoo res.user auf die neue E-Mail geändert - Die Tokens wieder aktiviert</p> <h1>Alternative Umsetzung von E-Mail Änderungen</h1> <p>Falls durch das obige Schema (zu viele) ungewollte Umzüge entstehen könnte man auch entscheiden das ein Umzug nur durch - den Sachbearbeiter in FRST mittels eigens dafür zu programmierenden GUI - oder bei Änderungen an der e-mail wenn ein User in FSO eingeloggt ist (z.B.: via Token) - oder einem PersonenMerge in FRST der sich trotz abweichender E-Mails sicher ist die Personen zusammen zu legen durchgeführt werden.</p> <p>Änderungen an dem Feld &#39;email&#39; bei res.partner würden dann zwar zu einer neuen PersonEmail führen diese würde jedoch nicht automatisch zur neuen Hauptemailadresse werden sofern für die bestehende Hauptemailadresse Gruppenanmeldungen oder ein odoo-login existieren.</p>