Domino 9 und frühere Versionen > ND9: Administration & Userprobleme
Problem mit Letzte Kontakte bei Domain-Wechsel lösbar?
CarstenH:
--- Zitat von: schroederk am 09.12.19 - 11:18:05 ---Das Problem: Es werden wohl nur zukünftige Einträge nicht aufgenommen und nicht auch vorhandene gelöscht.
Obwohl der Name der Regel "Remove" anstelle von "Filter" etwas anderes vermuten ließe.
--- Ende Zitat ---
Das war wohl nur ab der Einführung des Parameters bis zur 851 so, seit 852 macht der Parameter wohl auch das wonach er klingt, also löschen.
Ein gescriptetes Ändern/Löschen bringt ohne einen solchen Parameter im Übrigen nicht viel wenn man nicht auch die Mailadressen in sämtlichen Mails rückwirkend ändert da sich die Recent Contacts ja dynamisch immer wieder neu mit den alten Adressen füllen würden. Und gegen das rückwirkende Ändern von Mails spricht so einiges - aber das ist eine andere Baustelle ;)
HTH
Carsten
schroederk:
Ich muss mich doch nochmal melden.
Ich habe über die Policy die beiden Einträge bei allen Mitarbeitern gesetzt.
Gelöscht wurden dabei bisher bei keinem die bestehenden Einträge.
Daher habe ich auch ein kleines Script geschrieben, dass einfach diese Einträge rauslöscht.
Das Script funktioniert auch prima, alles wird gelöscht, aber bei einigen (nicht allen) tauchen die alten Adressen doch wieder auf.
Für 8.5.x gab es mal einen SPR dafür, aber scheinbar ist das Problem nicht gelöst. Ist bei uns nachstellbar mit Notes 9.0.1FPx und Notes 10.0.1FP3.
Dummerweise hat es bei meinen Tests ausgerechnet bei den Testkandidaten funktioniert.
Ein Ticket habe ich auch schon eröffnet, aber HCL versucht im Moment nur es mir schmackhaft zu machen die Recent Contacts komplett zu deaktivieren.
Da es etwas unter den Nägeln brennt, hat jemand noch eine Idee, wie ich vermeiden kann, dass beim Senden an einen internen Mitarbeiter die Meldung "Eintrag nicht eindeutig" kommt? Im Moment rufen die täglich (teils mehrfach) den Button zum Löschen erneut auf.
Nachtrag: Wie ich gerade feststellen durfte, kommen die Kontakte bei allen wieder rein. Nur dauert es bei dem einen oder anderen etwas länger (in Tagen)
CarstenH:
Bei Rudi gibt's ein schönes Dokument, das die Wirkung der Parameter ganz gut erklärt - insbesondere WANN sie evaluiert werden:
https://admincamp.de/customer/notesini.nsf/85255a87005060c585255a850068ca6f/6868f00ff40835c6c125773b004d3b5c?OpenDocument
Wenn alles nichts hilft, und die Recent Contacts abzuschalten keine Option ist, kannst du deinem Script auch statt der Löschung eine Feldänderung beibringen. Das ist auf lange Sicht eh die bessere Version um ungeliebte Vorschläge loszuwerden statt sie immer wieder zu löschen oder die Ignore-Regeln immer wieder anpassen zu müssen.
Einfach den Maskennamen der falschen Vorschläge in "DPABIgnorePerson" ändern, dann sollte der Eintrag nicht mehr vorgeschlagen werden.
Falls der neue auch noch gebraucht wird muss man den Eintrag vorher duplizieren, einmal ohne Form-Änderung mit neuem Namen anlegen und mit der angegebenen Form den alten Namen "unbrauchbar" machen. Das macht ja normalerweise auch das X hinter dem Namensvorschlag den man ausblenden möchte.
HTH
Carsten
schroederk:
--- Zitat von: CarstenH am 22.01.20 - 15:51:35 ---Bei Rudi gibt's ein schönes Dokument, das die Wirkung der Parameter ganz gut erklärt - insbesondere WANN sie evaluiert werden:
https://admincamp.de/customer/notesini.nsf/85255a87005060c585255a850068ca6f/6868f00ff40835c6c125773b004d3b5c?OpenDocument
--- Ende Zitat ---
Wichtig wäre also der folgende Eintrag?:
NABEntriesSyncInterval=7*24*60 defaults 7 days in minutes when not present.
Ich hatte bisher nur von DPAB_PROMOTE_INC=30 gelesen, dass eine Aktualisierung auf 30 Minuten erzwingt.
--- Zitat von: CarstenH am 22.01.20 - 15:51:35 ---Wenn alles nichts hilft, und die Recent Contacts abzuschalten keine Option ist, kannst du deinem Script auch statt der Löschung eine Feldänderung beibringen. Das ist auf lange Sicht eh die bessere Version um ungeliebte Vorschläge loszuwerden statt sie immer wieder zu löschen oder die Ignore-Regeln immer wieder anpassen zu müssen.
--- Ende Zitat ---
Würde eine Feldänderung denn tatsächlich verhindern, dass die alten Einträge wieder reinkommen? Ich würde vermuten, dass dann zwei Einträge erstellt sind: Der geänderte Eintrag und dann wieder neu der ursprüngliche.
--- Zitat von: CarstenH am 22.01.20 - 15:51:35 ---Einfach den Maskennamen der falschen Vorschläge in "DPABIgnorePerson" ändern, dann sollte der Eintrag nicht mehr vorgeschlagen werden.
Falls der neue auch noch gebraucht wird muss man den Eintrag vorher duplizieren, einmal ohne Form-Änderung mit neuem Namen anlegen und mit der angegebenen Form den alten Namen "unbrauchbar" machen. Das macht ja normalerweise auch das X hinter dem Namensvorschlag den man ausblenden möchte.
--- Ende Zitat ---
Ich hab zu diesem Eintrag so gut wie nichts gefunden. Kannst Du mir ein Beispiel nennen?
Würde ein DPABIgnorePerson= domain verhindern, dass dieser als Vorschlag genannt wird?
CarstenH:
--- Zitat von: schroederk am 23.01.20 - 08:17:55 ---Wichtig wäre also der folgende Eintrag?:
NABEntriesSyncInterval=7*24*60 defaults 7 days in minutes when not present.
--- Ende Zitat ---
Ich selbst habe bisher nur DPABRemoveRuleSetting und DPABRemoveRule benutzt, daher kann ich zu den anderen Parametern nichts sagen - schlechter kann's damit bei dir zumindest nicht werden.
--- Zitat ---Würde eine Feldänderung denn tatsächlich verhindern, dass die alten Einträge wieder reinkommen?
--- Ende Zitat ---
Nein, das ist aber auch gar nicht der Zweck. Die Erklärung lieferst du ja selbst im nächsten Satz.
--- Zitat ---Ich würde vermuten, dass dann zwei Einträge erstellt sind: Der geänderte Eintrag und dann wieder neu der ursprüngliche.
--- Ende Zitat ---
Genauso ist es. Nur mit dem Unterschied zu vorher, dass einer davon nicht mehr als Vorschlag auftauchen wird.
--- Zitat von: schroederk am 23.01.20 - 08:17:55 ---
--- Zitat von: CarstenH am 22.01.20 - 15:51:35 ---Einfach den Maskennamen der falschen Vorschläge in "DPABIgnorePerson" ändern, dann sollte der Eintrag nicht mehr vorgeschlagen werden.
Falls der neue auch noch gebraucht wird muss man den Eintrag vorher duplizieren, einmal ohne Form-Änderung mit neuem Namen anlegen und mit der angegebenen Form den alten Namen "unbrauchbar" machen. Das macht ja normalerweise auch das X hinter dem Namensvorschlag den man ausblenden möchte.
--- Ende Zitat ---
Ich hab zu diesem Eintrag so gut wie nichts gefunden. Kannst Du mir ein Beispiel nennen?
Würde ein DPABIgnorePerson= domain verhindern, dass dieser als Vorschlag genannt wird?
--- Ende Zitat ---
Du hast meinen Vorschlag nicht korrekt verstanden, ich erkläre es nochmal anders.
Einzelne Adressen, die der Nutzer nicht (mehr) vorgeschlagen bekommen möchte, kann er verbergen, wahlweise direkt im Vorschlag ("x" am Ende der Vorschlagszeile) oder im PAB mittels Aktion "in Schnelladressierung verbergen". Die verborgenen Adressen bekommen im PAB eine Markierung (Verbotssymbol) zur Visualisierung.
Hinweis => der Unterschied zwischen Verbergen und Löschen ist einfach aber wichtig: Löschen hilft nichts, da die Adressen wieder neu gefunden und aufgenommen werden und das Spiel von vorn losgeht. Über INI-Schalter kann man zwar rudimentär ein paar Dinge blocken aber zum einen funktioniert das nicht immer so wie gedacht und zum anderen ist die Länge eines INI-Eintrags auch begrenzt, die INI's sind schwer zu kontrollieren und so weiter.
Mein Vorschlag war jetzt schlicht die Idee, die Funktion der Aktion "in Schnelladressierung verbergen" nachzustellen, die zwei Dinge tut:
1) das Feld "Form" des Adressvorschlagsdokuments wird von "DPABperson" auf "DPABIgnorePerson" geändert bzw. bei Gruppen von "DPABGroup" auf "DPABIgnoreGroup"
2) das Feld "$DPABState" kann mehrere Werte annehmen, "50" ist der normale Wert für aktive Vorschläge, die Werte "20" und "70" verbergen. Bei meinen Tests war es immer die "70", die würde ich empfehlen.
Vermutlich aus Kompatibilitätsgründen gibt es das Feld "$DPABState" nochmal als "$DPAB_State" mit identischen Werten, also ebenfalls auf "70" setzen.
Zusammengefasst: verberge die unerwünschten Einträge statt sie zu ändern oder zu löschen, dein Script sollte da nur rudimentäre Anpassung brauchen; damit bist du auch in der Übergangsphase unabhängig von den INI-Einträgen, wenn sie denn nicht funktionieren
HTH
Carsten
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln