@Marietta:
Um den Widerspruch "Dokument ohne Autorfeld kopieren und anschliessend als Autor bearbeiten wollen" zu umgehen, würde ich statt CopyToDatabase CopyAllItems verwenden:
- in der Ziel-DB neues Doc anlegen
- Eigene Felder belegen, zum Response-Doc machen
- Autor-/Leserfelder die nötigen Property verpassen
- CopyAllItems vom Original ins Doc
- speichern

HTH,
Bernhard

@koehlerbv:

keiner weiß mehr, wem denn nun das Notebook und der externe Brenner und das zweite Ladegerät und die SmartSuite-Lizenz gehört ...

Das hat sie dann alles mitgehen lassen  

Aber vielen Dank für die Erläuterung dieser Option.

Christian

Hi Axel!

Ich hab jetzt alles so reinkopiert, wie von Dir vorgeschlagen, aber sch..............!

Gehört bei:
Set item = New NotesItem( DocN, "Leser", doc.Leser, READERS )
         item.IsReaders= True
         Set item = New NotesItem( DocN, "Autoren", doc.Autoren, AUTHORS )
         item.IsAuthors= True

Leser und Autoren in Hochkomma, oder kommt da was anderes rein??
Bin schon fix und fertig, wahrscheinlich ist aber auch die Hitze daran schuld.

Hi Bernhard!

Und wie mach ich das bei meinem Code?

lg
Marietta

Hi,

hier die kurze Erklärung der Parameter für

Set item = New NotesItem( DocN, "Leser", doc.Leser, READERS )

DocN -> Dokument in dem das Feld (neudeutsch: Item) angelegt werden soll.

"Leser" -> Name des Feldes in Anführungszeichen

doc.Leser > Feldinhalt der in das neue FEld eingefügt werden soll.

READERS -> legt den Typ des Feldes fest, hier ein Leserfeld.


Leser und Autor ist der Feldname und die habe ich aus deinem Script entnommen. Sie gehören in Anführungszeichen.

Axel

Zu 3. Doch, doch - aber erst, als ich ihm das Wirken von AdminP bei User-Löschungen zu denken gegeben habe ;-)  Er hat dann 'ne runde Bier ausgegeben ;-)

Zu 4. Immer noch ein Mißverständnis: Natürlich haben die Manager immer Zugriff, da braucht man ja noch nicht mal 'ne Rolle (solange man nicht Buttons, Teilmasken oder Felder/Text mit Hide-when rollenabhängig ausblendet.
Es geht hier um folgende Situation - und bleiben wir mal beim schön einfachen Inventar-DB-Beispiel:
- Eine Ansicht stellt alles Inventar nach Besitzer dar.
- Frl. X wird Frau Y durch Rezertifizierung.
- Frau Y scheidet zur Kindererziehung aus.

Ist das Besitzer-Feld Names oder Text, kriegt die App nix mit von der Rezertifizierung (doof) und auch nicht von der Löschung (guuut).
Zur Lösung des Falls "Doof": Im Dokument gibt es Item, das dem Item "Besitzer" beigestellt ist (unsichtbar, in keiner Maske - wozu auch). Dieses hat die property IsReaders und wird von einem scheduled agent überwacht:
- Gibt es "BesitzerLerser" noch nicht - anlegen
- Ist "BesitzerLeser" leer - schade, aber nicht zu ändern.
- Ist BesitzerLeser <> Besitzer, dann gab's 'ne Rezertifizierung. Der Agent übernimmt nun für Besitzer den Inhalt von BesitzerLeser.

Und in unserer Ansicht steht jetzt alles Inventar von Frl. X unter dem Namen Frau Y.
Und wenn sich Frau Y dann um die lieben Kleinen kümmert und dankend auf ihren Notes-Account verzichten kann, steht ihr Inventar immer noch unter ihrem Namen.
Und wenn der Programmierer noch ganz fix war, dann hat er für den Fall BesitzerLeser = "" durch den Agent noch ein Flag setzen lassen: "Beute zu verteilen". Erscheint dann als Kategorie in einer anderen Ansicht.

Ciao,
Bernhard

Sorry, Marietta, jetzt haben wir Dich doch glatt vergessen ...

Ich versuche mal so aus dem Hut noch ein paar Erläuterungen:
Axels Vorschlag (guuut!) - Du mußt hierzu aber in den Declarations ein %Include "lsconst.lss" einbinden, sonst kennt er die Konstanten READERS und AUTHORS nicht.

Mein Vorschlag wegen CopyAllItems:

While Not (Doc Is Nothing)
         Set DocN = DBPM.CreateDocument
         Call DocN.MakeResponse(DocG)
         DocN.Doc_Subject=Doc.Subject
         DocN.Doc_PostedDate=Doc.PostedDate
         DocN.form="Memo"
         <Axels Code wegen Autoren/Leser>
         Call Doc.CopyAllItems (DocN, true)
         Call DocN.Save(True, False, True)
         
         Set Doc=col.GetnextDocument(doc)
      Wend


Wie gesagt - aus dem Hut. Wenn es noch irgendwo scheppert, bitte mit dem Debugger ermittelt, wo.

HTH,
Bernhard

Hi, ata,

was die Konstanten READERS und AUTHORS angeht: Die separat zu deklarieren ist natürlich kein Problem. Aber "eine ganze .lss einbinden" ist sicherlich erheblich einfacher (und unproblematischer) als einem newbee zu erklären, wie sie die erforderlichen Werte herausbekommt ... Und lsconst bietet ja nun einen ganzen Sack voll Konstanten, die man dauernd braucht (MB_xxxx usw.).

Wegen der konsistenten ACL müssen wir wohl alle nochmal genauer nachlesen. Ich programmiere an einem ganzen Sack voll Apps, die auf konsistente ACL angewiesen sind und kann daher folgendes sagen:
- Liegt die DB auf einem Server, braucht man definitiv keine konsistente ACL, um Rollen zu ermitteln. Sagt auch die Doku.
- R5.0.8: Die ACL wird definitiv auch repliziert, wenn deren Änderung nicht auf dem Administrations-Server vorgenommen wurde.
- Was zu checken ist: Bestimmte Änderungen in der ACL werden gecached und werden erst wirksam, wenn man hier nachhilft - nicht nur lokal (da ist es ja sowieso happig), sondern auch auf den Servern. In der Regel hilft es, das Replizierprotokoll zu löschen ...

Eure Erfahrungen würden mich hier sehr interessieren - gerade das Zusammenspiel Server-DB mit lokalen Repliken!

Beste Grüsse, Bernhard

Ich glaube, wir sollten mal 'n Thread aufmachen für "enforce consistent ACL" ;-)  Was meinst Du ? Wäre aber nur für erfahrene Notes-Admins/Programmierer ...

Erstmal zur Version: 5.0.8 habe ich als Entwicklungsplattform im Einsatz, in der Firma und erst recht beim Kunden ist es viel bunter, aber hinsichtlich konsistenter ACL immer gleich.

In der ACL rumpfuschen können - egal ob konsistente ACL oder nicht - immer nur DB-Manager. Wenn jemand 'ne lokale Replik hat OHNE konsistente ACL, ist er dort bekanntermassen Manager. Aber ob er dann dort sich selbst, der er nur Leser ist, als Manager einträgt oder nicht, oist so egal, als ob in China 'n Sack Reis umfällt - seine ACL-Änderungen werden von (jdem) Server abgelehnt, und seine unautorisierten Dokument-Änderungen auch.

Meine Kenntnis: Konsistente ACL braucht man, wenn
- lokal Rollen und Rechte (!) ausgewertet werden sollen
- und Leute nicht mit OS-Kopien einer NSF rumhantieren dürfen sollen, die sie lokal vorfinden (= nicht mir ihrer ID angelegt haben resp. sie nicht explizit NAMENTLICH in der ACL aufgeführt sind) oder sich vom Server ziehen.

Können wir uns da weiter austauschen (in einem Extra-Thread)?

Und back to the roots: Wie können wir Marietta weiter helfen? Das war doch der Ausgangspunkt ...

Ciao,
Bernhard

Ich sag doch - wir sollten dazu einen eigenen Thread aufmachen !

Ich hab' jetzt eben in einer entsprechenden DB LOKAL eine ACL-Änderung gemacht (Person hinzugefügt als Manager).
Administrationsserver ist Server A, repliziert habe ich aber mit Server B.
Und die ACL wurde geupdated auf B. Und nach Replikation mit A stand dort das selbe.

Wie gesagt, das Ganze interessiert mich auch sehr und ich habe damit seit Jahren zu tun (und bekomme teilweise erst jetzt Probleme von Kunden gemeldet, die es zu umschiffen gilt - es betrifft immer die lokalen Repliken). Wollen wir dazu nicht einen eigenen Thread aufmachen und jetzt hier nicht die arme Marietta wuschig machen ?

Herzliche Grüsse vom Rand der Alpen auf die Alb,
Bernhard

Morgen!

Wusste gar nicht, dass ich mit meinem Betrag eine Lawine losgelöst hab!

Die Berechtigungen an beiden Servern bzgl. Leser und Autorenfeldern funktionieren jetzt, nachdem ich die Replik am Admin-Server gelöscht und eine Neue erstellt hab.

Beim LS von Bernhard "frisst" er mir die Zeile mit !!!-markiert beim sichern des Script nicht:

While Not (Doc Is Nothing)
        Set DocN = DBPM.CreateDocument
        Call DocN.MakeResponse(DocG)
        DocN.Doc_Subject=Doc.Subject
        DocN.Doc_PostedDate=Doc.PostedDate
        DocN.form="Memo"
        '<Axels Code wegen Autoren/Leser>
     !! Call Doc.CopyAllItems (DocN, true)
        Call DocN.Save(True, False, True)
       
        Set Doc=col.GetnextDocument(doc)
      Wend

Marietta