Autorenfelder

[koehlerbv]

@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]

@Christian:
Mit dem Update der Autoren- und Leserfeldern muß man aber auch aufpassen, daß man sich dabei nicht selbst ins Knie schiesst.
Nehmen wir mal eine Inventar-DB. Falls Frl. X heiratet und rezertifiziert wird, soll ja auch ihr Inventar entsprechend unter dem neuen Namen aufgelistet werden. Ergo: Wir machen aus dem Feld "Besitzer" gleich ein Autorenfeld, und der AdminP wird's dann schon richten.
Dumm wird's aber, wenn Frau Y (wie sie jetzt heißt) wegen Nachwuchs die Firma verläßt. AdminP entfernt jetzt ihren Namen aus dem Feld "Besitzer", und keiner weiß mehr, wem denn nun das Notebook und der externe Brenner und das zweite Ladegerät und die SmartSuite-Lizenz gehört ...

[Christian97]

@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

[Axel]

@Christian:
Mit dem Update der Autoren- und Leserfeldern muß man aber auch aufpassen, daß man sich dabei nicht selbst ins Knie schiesst.
Nehmen wir mal eine Inventar-DB. Falls Frl. X heiratet und rezertifiziert wird, soll ja auch ihr Inventar entsprechend unter dem neuen Namen aufgelistet werden. Ergo: Wir machen aus dem Feld "Besitzer" gleich ein Autorenfeld, und der AdminP wird's dann schon richten.
Dumm wird's aber, wenn Frau Y (wie sie jetzt heißt) wegen Nachwuchs die Firma verläßt. AdminP entfernt jetzt ihren Namen aus dem Feld "Besitzer", und keiner weiß mehr, wem denn nun das Notebook und der externe Brenner und das zweite Ladegerät und die SmartSuite-Lizenz gehört ...

Hi,

seit wann soll denn ein "Normalsterblicher" Einträge in einer Inventar-DB ändern dürfen ? Autorenrechte sollte hier die EDV haben und sonst keiner.
Ausserdem hab ich noch nie eine Inventar-DB gesehen, in dem das Feld Besitzer ein Autorenfeld war. Das mach doch keinen Sinn.

Axel

[mgeidl]

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

[koehlerbv]

Ich glaub', da hast Du was vollkommen mißverstanden.
1. Inventar-DB war ein Beispiel
2. Daß in der DB irgendeiner ausserhalb der DV-Abteilung Autorenrechte hat, wurde nicht mal erwähnt.
3. Mit hat tatsächlich mal jemand das beschriebene Verfahren als *den* Einfall verkaufen wollen, um nach Rezertifizierungen alle früheren Doks automatisch per AdminP umzustellen.
4. In etlichen Apps führe ich tatsächliche Personen *zusätzlich* in einem Leserfeld mit, ein periodischer Agent updated im Fall der Fälle (Rezertifizierung) das eigentliche Personenfeld, falls das Leserfeld nicht plötzlich leer sein sollte ...

Bye,
Bernhard

[Axel]

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

[Axel]

Ich glaub', da hast Du was vollkommen mißverstanden.
1. Inventar-DB war ein Beispiel
2. Daß in der DB irgendeiner ausserhalb der DV-Abteilung Autorenrechte hat, wurde nicht mal erwähnt.
3. Mit hat tatsächlich mal jemand das beschriebene Verfahren als *den* Einfall verkaufen wollen, um nach Rezertifizierungen alle früheren Doks automatisch per AdminP umzustellen.
4. In etlichen Apps führe ich tatsächliche Personen *zusätzlich* in einem Leserfeld mit, ein periodischer Agent updated im Fall der Fälle (Rezertifizierung) das eigentliche Personenfeld, falls das Leserfeld nicht plötzlich leer sein sollte ...

Bye,
Bernhard

zu 3. Ich möchte mal behaupten, derjenige hat den Sinn und Zweck der leserfelder nicht ganz kapiert.

zu 4. warum so aufwändig? Ich definiere mir eine Rolle und die kommt fest in ein Leserfeld. Die Rolle bekommt der DB-Administrator zugewiesen. Fertig. Die Zugriffssteuerung mache ich dann über ein 2. Leserfeld. So habe ich die Gewähr, dass immer jemand auf des Dokument zugreifen kann.

Axel

[koehlerbv]

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

[mgeidl]

Hat leider noch immer nicht funktioniert!

[koehlerbv]

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

[ata]

@Koehlerbv

... wegen 2 Konstanten eine ganze .lss verwenden - da würde ich die beiden Konstanten explicit einbinden - sollte auf einer anderen Maschine - aus welchem Grund auch immer - die Datei fehlen hast du beim neu kompilieren ein Problem...

... ich gebe Axel völlig recht, was die Verwendung der konsistenten ACL angeht. Auch ich verwende sehr häufig die konsistente ACL - nicht nur lokal - da ist sie unabdingbar, wenn ich Rollen verwende...

... die konsistente ACL stellt eines sicher - Änderungen in der ACL dürfen NUR auf dem Administrationsserver vorgenommen werden. Ist das nicht der Fall, werden die DB's nicht mehr repliziert...

... in so einem Fall muß die konsistente ACL deaktiviert werden und die ACL's gerade gezogen werden - dann die konsistente ACL wieder aktivieren...

ata

[koehlerbv]

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

[ata]

... die Rollen werden bei jedem Server-Zugriff überprüft, da beim Zugriff eine Sicherheitsüberprüfung zwingend ist - und die gibt es lokal nicht zwingend - eben nur mit der konsisten ACL...

... damit man mir nicht replizierend in der ACL rumpfuscht aktiviere ich die konsistente ACL - damit weden ACL-Änderungen nur auf dem Administrationsserver zugelassen - definitiv - ich hatte deswegen mit Admins beim Kunden schon diverse Kontakte, warum die Replikation nicht mehr funktioniert...

... ob das mit 5.08 funktioniert kann ich dir gerade nicht beantworten, dazu müsste ich in die Konowledge Base...

ata

[koehlerbv]

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

[ata]

... und man nimmt die konsistente ACL auf einem Server, um die ACL nur auf dem Admin-Server pfelgbar zu machen. Natürlich kann ei Mangaer die ACL auf einem anderen Server ändern - aber sie wird NICHT repliziert....

ata

[koehlerbv]

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

[ata]

@koehlerbv
... back to the roots - ich poste dir meine Einstellung der Kunden-DB morgen - in einem neuen Posting unter R5 Probleme - OK...

@Marietta
... sind die Autorenfelder in der Replik korrekt gesetzt - AdminP übernimmt auch die Aktualisierung der Leser und Autorenfelder...

ata

[mgeidl]

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

[Axel]

Hi,

musste mich gestern relativ früh ausklinken, aber es scheint so, dass du ein Stückchen weitergekommen bist.

Bekommst du eine Fehlermeldung oder passiert einfach gar nichts ?

Hast du auch mal versucht die Zeile etwas weiter vorzuziehen, beispielsweise nach dem CreateDocument ?

Axel