Wir arbeiten in unserer Firma mit einer extra Domäne für alle Notesdatenbanken auf die mit Browser zugegriffen wird. Um die Replikation zu ermöglichen, enthalten alle Dokumente ein verstecktes Autorenfeld in dem die ganzen Servergruppen eingetragen werden.
Da ist jetzt eine neue Gruppe hinzugekommen und ich stehe jetzt vor dem Problem, diese versteckten Felder auf den aktuellen Stand bringen zu müssen.
Die Felder sind bisher definiert als "berechnet beim Anlegen". Das muss ich ja nun wohl ändern. Reicht es, wenn ich diese Felder auf "berechnet zur Anzeige" ändere? Werden die Doks bei einem Replikationszugriff neu berechnet? Oder ist es besser, diese Einstellung zu belassen, damit die Werte im Dokument gespeichert sind? Dann müsste ich aber wohl per Agent alle bestehenden Doks updaten. Kann ich Felder die als "berechnet beim Anlegen" definiert sind per Agent updaten? Muss man dabei irgendwas beachten?
Viele Fragen, hoffe auf viele Antworten!  

Danke.
Das mit der Gruppe wird nichts werden, da hab ich keine Chance. Unsere Admins haben eben z. Zt. 4 solche Gruppen und die muss ich halt jetzt verwenden.

Gute Frage!
Ich kann nicht sagen, warum, aber zwei von den Servergruppen sind keine Manager. Eine Gruppe hat Editor- die andere gar nur Leser-Rechte. Ich wollte auch meine Frage nicht unnötig aufblähen, aber es geht bei diesen Manipulationen auch um mehrere Felder (Leser/Autoren). Fakt ist, dass ich in den "Web-Repliken" viele Dokumente nicht sehe und meine einzige Spur sind fehlende Zugriffsrechte der Server.
BTW: Reicht es eigentlich, über die Doks ein ComputeWithForm laufen zu lassen; also werden so die Felder "berechnet beim Anlegen" aktualisiert?  

Ich mein ja: das verstehe ich auch nicht!
Die Lesergruppe hat allerdings zusätzlich das Recht "Dokumente replizieren und kopieren" angehakt. Meiner Meinung nach eine sinnlose Kombi. Kann das denn funktionieren?

Danke.
Dann weiss ich doch, "wo der Hund begraben liegt".
Genau diese Einstellung haben die Admins dann wohl für die Replikation ins Intranet gewählt und da ich diese Gruppe nicht in einem Leser- oder Autorenfeld erwähnt hatte, kann das dann natürlich nicht klappen.
BTW: Durch deine Empfehlung mit der neuen Gruppe bin ich jetzt auf den Trick gekommen, dass ich eine Rolle "Server" in die ACL aufnehme und diese Rolle in ein Autorenfeld schreibe. Dann bin ich zumindest unabhängig von eventuellen Änderungen seitens der Admins. Wenn die dann mal wieder eine neue Servergruppe erfinden, dann müssen die nur dieser Gruppe die Rolle zuweisen und dann klappts wieder. Sollte doch funktionieren?

Nächstes Problem: Die Einstellung des Autorenfeldes lautete ja bisher "berechnet zum Anzeigen"  und es gibt auch einige Masken in denen diese Felder noch fehlen, wo sie aber jetzt rein müssen. D. h. ich kann mit meinem Agent nicht testen :

 if doc.HasItem("AFeld")
......
weil ja dieses Item leider nicht da ist. Muss ich jetzt wirklich hergehen und auf die Maske testen:
 
(if doc.Form(0) = "MaskeA" | doc.Form(0)="MaskeB" |.....)
............
 oder gibts da was Eleganteres?

Es hat aber ein netter Kollege nicht in alle relevanten Masken dieses Feld integriert und dann auch noch bei einigen Masken als "berechnet zur Anzeige". Und das ganze Problem wurde ja auch erst jetzt akut, weil zukünftig die Web-Version richtig genutzt werden soll. Jedenfalls hab ich nun das Problem, dass ich die Felder in allen betroffenen Dokumenten aktualisieren muss und ein erster Agentlauf mit doc.HasItem ging voll daneben. (von 13500 Doks wurden gerade mal 4000 aktualisiert, weil der Rest eben dieses Feld nicht hat) Also werde ich wohl nach Maske suchen und aktualisieren müssen.

Da habt Ihr aber einen saumässigen Verhau ! Das ist ja grauslich ...

Da geb ich dir Recht!

Aber Dein Problem mit HasItem verstehe ich noch nicht ganz: Wenn das False zurückgibt, ist doch klar, das das Item nicht vorhanden ist. In dem Fall legst Du es einfach neu an mit den Werten, die alle drin sein müssen.

Wenn es man so einfach wäre...
Die neuen Felder müssen zwar in massig viele, aber nicht in alle Masken. In der Datenbank läuft z. B. auch eine selbstgebaute Leserstatistik (weil wegen Datenschutz (LOL) die Aufzeichnung der Benutzeraktivität verboten wurde) und diese Doks sollen/dürfen natürlich nicht repliziert werden. Deshalb is nix mit : hasItem  

Ich wollte auch meine Frage nicht unnötig aufblähen, aber es geht bei diesen Manipulationen auch um mehrere Felder (Leser/Autoren).

Das zum ersten.

Zum zweiten gilt auch hier:

Rule #10 - If there are both Readers fields and Authors fields on a document, the Authors fields are also Readers fields

This one may not make sense right away, so I'll provide an example. Let's say that your document has a Readers field with a value of "[Admin]" in it. Your document also has an Authors field with a value of "CN=John Doe/OU=Your Organization/O=Your Company". Because John Doe is listed in the Authors field, he automatically will be able to see the document in views. He does not need to also be listed in a Readers field. The Readers field removed access from John Doe, but the Authors field gave that access back again.

I'll point out that this is the only time that Authors fields can have an affect for users with Editor or higher access to the database. If John Doe was a Designer of this sample database, the Authors field comes into play and allows him to see the document in views, even though he has higher than Author access to the database.

I hope you'll understand and this may help you.

Deshalb will ich die Server alle zusammenfassen indem ich diesen eine gemeinsame Rolle gebe. Diese Rolle steht dann in einem Autoren-Feld und dann ist es mir egal ob die Admins beschliessen, dass die jeweilige Server-Gruppe Leser- oder Autor- oder Manager-Zugriff hat. Die Rolle sollte immer passen! Oder?

Da hast du wieder Recht.
Aber das gibts ja auch.
Ganz früher ... und lange vor meiner Zeit wurde in dieser Datenbank schon mal mit irgendwelchen eingeschränkten User-Rechten gearbeitet (vielleicht sollte ich lieber sagen: EXPERIMENTIERT). Und aus dieser Zeit gibt es mittlerweile in allen Masken ein Leserfeld, welches die Rolle "AlleAngaben" enthält. Diese Rolle haben mittlerweile alle Benutzer (ausser denen, welche die Admins in die ACL schreiben). Und weil ich nicht davon abhängig sein will, was die Admins ihren Servern für ACL-Rechte geben, kommen die einfach in ein Autorenfeld!
Und nicht dass du jetzt auf den Vorschlag verfällst, man sollte diese Anwendung mal komplett überarbeiten. Das fällt aus wegen Finanzen. Max 5MT/Jahr gibts für diese Sache und davon habe ich dann etliche an der Backe... Danke für deine Hilfe.

EDIT: Wie erstelle ich per Script ein Autorenfeld, wie ändere ich ein bestehendes Leserfeld in Autorenfeld(Script)?