Mail-IN-Name von DBen geändert

[maxritti]

Hallo zusammen,

wir haben Mail-IN-DBen im Einsatz, die als Template das normale Mailtemplate haben.
Für diese DBen gibt es Mail-IN-Dokumente und in der ACL sind Gruppen als Editor eingetragen, so dass mehrer Personen darauf zugreifen können.

Nun ist bei einigen DBen der Mail-IN-Name umbenannt worden.
Will heissen, dass das Mail-IN-Dokument einen anderen Namen hat.
Die Gruppen in den ACLs sollten auch den neunen Namen beinhalten. Haben also auch einen neuen Namen mit den gleichen Editorrechten wie die alten Gruppen bekommen.
Das Feld Owner in dem Profildokument der DB wurde auch in den neuen Namen geändert.

Soweit so gut.

Nun ist auffällig geworden, dass die Benutzer bestehende Termine nicht mehr so wie vorher bearbeiten können.
Vor der Umbenennung gab es einen Button "Besitzeraktion", nun heisst der nur noch "Teilnehmeraktionen".
Und den "Teilnehmeraktionen" finde ich nicht wirklich im Design der Appointment Maske.

Hat dazu jemand einen Tip, warum das so ist?
Und am besten wie wir da ohne wieder den alten Mail-IN-Namen zu vergeben raus kommen?

Ein Ansatz wäre ja bei allen Kalendereinträgen das Feld Chair zu ändern.
Aber ob das alles ist?

[CarstenH]

Für Mail_in-DB's gibt es leider keinen standardmäßigen Umbenennungs-Workflow wie für Gruppen oder Personen.
Da muss dann wohl ein Korrektur-Agent drüber laufen.

Ohne die Felder jetzt alle zu mühselig zu ermitteln könnte man den Agenten einfach in alle Felder gucken lassen und anhand einer Alt-Neu-Liste die Namen austauschen. Die Kalendereinträge in den persönlichen Kalendern, die durch Einladungen entstanden sind, müsste man entweder bei der Gelegenheit mit durchgehen oder mittels Alias im Mail-In-Dokument einen Workaround bereitstellen wenn jemand nachträglich absagt oder ändert.

Mögliche Alternative: Man benennt das Mail-Dokument temporär in was-auch-immer um, legt ebenfalls temporär einen Nutzer mit dem alten Mail-In-Namen an und lässt den AdminP die Arbeit machen. Anschließend löscht man die Person (mittels ENTF! und keinesfalls mit "Person löschen"!) und benennt die Mail-In wieder um.

Die letztere Variante hatte ich vor Äonen im letzten Jahrtausend mal unter R4 erfolgreich durchgeführt.

HTH
Carsten

[maxritti]

Danke schon mal.

Das mit dem AdminP hört sich mal nicht so verkehrt an, denn der geht dann ja auch die pers. Einträge durch.
Muss ich mal diskutieren, denn das geht ja nicht mal so eben.

Wobei das mit dem Agenten ja auch nicht.
Denn der Hinweis mit den pers. Einträgen ist gut. Aber macht die Sache nicht einfacher. 

[DomAdm]

hilft vielleicht dieser Agent?
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0026397

"Important Note: You must verify that the mail file's Owner field has been set correctly before using this agent. The agent uses the Owner field to determine whether a field is correct in each entry. If the target user does not appear as the owner of the mail file, please correct this before running this agent. "

[maxritti]

Nicht wirklich. Den hatte ich auch gefunden und mal direkt auf einer lokalen Kopie einer Mail-IN DB laufen lassen.

Mit dem Erfolg, dass direkt mal ein "Object not found" oder so auftauchte.
Da war ein Objekt NotesItem nicht vorhanden, der Code wollte aber darauf zugreifen.
Das Owner Feld war korrekt gesetzt.

Von daher habe ich den mal zur Seite gelegt.