ACL-Administrationsserver - Adminp

[Günther Rupitz]

Der Adminprozess greift eine Datenbank für eine Benutzerumbennennung/Löschung ja nur dann an wenn in der ACL auch ein Administrationsserver eingetragen ist.

Nach Durchsicht meiner Altlasten hat aber ca. 1/3 unserer Datenbanken keinen Administrationsserver eingetragen - gut hole ich nach.

Kann ich aber irgendwie (Policys?) sicherstellen dass jede NSF einen Adminserver bekommt - bzw macht das überhaut Sinn?
Mir geht es primär mal darum dass ein Benutzer aus einer ACL verschwindet wenn er gelöscht wird - Namensfelder usw. interessieren mich hier mal nicht.

[Klafu]

Hallo,

Zum Thema Admin Server:
Policys kann man nur auf Personen anwenden. Mein Tip: Geh über den Admin Client auf
Files > wähl den entsprechenden Ordner aus (z.B. Mail) > Rechtsklick > Zugriffskontrollliste ->Manage.

Das zieht dann für die DBs die im Ordner Mail liegen.

Chris

[koehlerbv]

Würde man das - wie auch immer - automatisieren, könnte dies ja auch ganz fix verheerende Folgen nach sich ziehen. Ausserdem: Welche Server sollte denn per Default dort angetragen werden? Auch da gibt es ja immer "feine Nuancen" 

Bernhard

[Günther Rupitz]

naja, man könnte ja den server auf dem eine neue datenbank angelegt wird automatisch als adminserver eintragen.
natürlich nicht wenn eine replik auf einen server gezogen wird.

klafu: bessere methode um bestehende datenbanken zu überarbeiten wäre aus meiner sicht z.b. die verwendung von acl-viewer von openntf, dort bekommt man ja den ist-stand ja schön aufbereitet.

meine fragen waren aber eher prinzipielle:

1. ist es sinnvoll das jede datenbank einen adminserver eingetragen hat?
2. wenn nein, wie stellt ihr sicher dass ihr keine leichen in den acls habt?

[koehlerbv]

Zu 1) Das kommt auf die jeweilige DB an und ist pauschal nicht zu beantworten. Mindestens genau so wichtig ist ja der Eintrag, was der AdminP mit den unterschiedlichen Names-Items anstellen soll (oder nicht)
Zu 2) aclEZ von Ytria und ein eigenes, spezifisches Teil, was sich bei neuen oder (fraglich) geänderten ACLs bei den lieben Admins meldet.

Bernhard

[Günther Rupitz]

Zu 1) Das kommt auf die jeweilige DB an und ist pauschal nicht zu beantworten. Mindestens genau so wichtig ist ja der Eintrag, was der AdminP mit den unterschiedlichen Names-Items anstellen soll (oder nicht)

Sogar wichtiger in meinen Augen. Allerdings habe ich fast keinen Anwendungsfall wo ich die Funktion in der Form in einer Eigenentwicklung
nutzen kann. So ist es bei mir meist so dass ich die Names-Felder eines Workflow-Dokumentes das abgeschlossen ist nicht mehr ändern will, bei einem das noch in bearbeitung ist jedoch schon. Nur Adminp unterscheidet hier ja nicht, also muss ich solche Änderungen fast immer durch einen Programm machen.

Zu 2) aclEZ von Ytria und ein eigenes, spezifisches Teil, was sich bei neuen oder (fraglich) geänderten ACLs bei den lieben Admins meldet.

Ok, das Teil habe ich mir noch nie angesehen. Wenn es so eine Art Suchen-Ersetzen kann wäre es vielleicht recht nützlich.

[Driri]

Nur Adminp unterscheidet hier ja nicht, also muss ich solche Änderungen fast immer durch einen Programm machen.

Kommt darauf an, wie die Anwendung aufgebaut ist. Wenn man das von Anfang an berücksichtigt, kann man die Felder z.B. als Autorenfeld oder Namensfeld aufbauen.

Damit könnte man also z.B. dafür sorgen, daß Namen zur Anzeige in Namensfeldern und Namen für die Verarbeitung im Workflow / für die Rechtesteuerung in Autorenfeldern stecken.

Dafür gibt es ja dann in der ACL die Unterscheidung, welche Namensfelder der Adminp bearbeiten soll.

[koehlerbv]

Welche Itemtypen verwendet werden, erfordert tatsächlich von Anfang an eine sorgsame Planung und ist so meist auch einfach möglich.
Ein sehr einfaches Verfahren ist ein Text- und ein Namensfeld (hierunter fasse ich jetzt mal Authors, Readers und Names zusammen). Das Namensfeld speichert den Namen, wie er Notes bekannt ist (gesetzt beim Erstellen, Ändern und / oder per Agent), das Textfeld übernimmt jeweils das Namensfeld, so es derzeit anders als Namensfeld und dieses aber nicht leer ist.
Für die Anzeige in Ansichten wird der auszugebende Wert berechnet: Wenn Namensfeld nicht leer, dann Namensfeld, sonst Textfeld. Aktionen gehen immer auf das Namensfeld - wenn es nicht leer ist, sonst ist die Operation nicht möglich.

So ist es bei mir meist so dass ich die Names-Felder eines Workflow-Dokumentes das abgeschlossen ist nicht mehr ändern will, bei einem das noch in bearbeitung ist jedoch schon.

Das kann aber zu komischen Effekten führen:
- Workflow läuft, User wird gelöscht - das Dokument hängt in der Luft. Wenn zum Monatsende mal mehr Leute gehen ...
- Workflow ist beendet, User wird umbenannt. Nach einiger Zeit kommen schon die ersten Fragen: Wer war denn das? Auch personenbezogene Auswertungen sind so nicht möglich (wieviel Tage Urlaub hat die jetzt verheiratete XY schon genommen?).

Bernhard

[Günther Rupitz]

Welche Itemtypen verwendet werden, erfordert tatsächlich von Anfang an eine sorgsame Planung und ist so meist auch einfach möglich.
Ein sehr einfaches Verfahren ist ein Text- und ein Namensfeld (hierunter fasse ich jetzt mal Authors, Readers und Names zusammen). Das Namensfeld speichert den Namen, wie er Notes bekannt ist (gesetzt beim Erstellen, Ändern und / oder per Agent), das Textfeld übernimmt jeweils das Namensfeld, so es derzeit anders als Namensfeld und dieses aber nicht leer ist.
Für die Anzeige in Ansichten wird der auszugebende Wert berechnet: Wenn Namensfeld nicht leer, dann Namensfeld, sonst Textfeld. Aktionen gehen immer auf das Namensfeld - wenn es nicht leer ist, sonst ist die Operation nicht möglich.

uahhhh. Namen in Textfeldern, da stellts mir schon ein bisserl die Haare auf. Aber ich weiss schon, im Notes muss man viel zu oft irgendwelche Hinkelzüge machen.  Aber ein möglicher Ansatz - Danke.

- Workflow läuft, User wird gelöscht - das Dokument hängt in der Luft. Wenn zum Monatsende mal mehr Leute gehen ...

Aber hier hast du ja schon einmal eine Schwachstelle beim Adminp - der unterscheidet ja bei Feldern nicht zwischen einer Userlöschung/Umbennenung, der fährt ja in beiden Fällen gleich drüber, was ich sehr unpraktisch finde.

- Workflow ist beendet, User wird umbenannt. Nach einiger Zeit kommen schon die ersten Fragen: Wer war denn das? Auch personenbezogene Auswertungen sind so nicht möglich (wieviel Tage Urlaub hat die jetzt verheiratete XY schon genommen?).

Da hast du recht, ja.

Eine viel schönere Lösung wäre es meiner Ansicht ja wenn es einen Agent-Trigger für die Adminp-Userveränderungen (Umbenennen/Löschen/..) geben würde und ich in dann die relevanten Felder in den Dokumenten selbst neue berechnen könnte. Das muss ich derzeit ja auch schon so machen wenn eine Person durch eine andere abgelöst wird und offene Dokumente/Tasks übernommen werden müssen. Dafür habe ich ja gar keinen Admin Prozess.

[koehlerbv]

Namen in Textfeldern, da stellts mir schon ein bisserl die Haare auf. Aber ich weiss schon, im Notes muss man viel zu oft irgendwelche Hinkelzüge machen.

Wie kommst Du denn darauf?

Und warum sollte der AdminP zwischen Löschungen und Umbennenungen unterscheiden? Der ist doch nicht da, um faule oder unfähige Programmierer zu unterstützen, sondern die Integrität des Gesamtsystems sicherzustellen.

Bernhard

[Günther Rupitz]

Wie kommst Du denn darauf?

Meine persönliche Einstellung ist dass ein Name in ein Namensfeld gehört, genau so wie eine Zahl auch in ein Zahlenfeld soll.

Und warum sollte der AdminP zwischen Löschungen und Umbennenungen unterscheiden? Der ist doch nicht da, um faule oder unfähige Programmierer zu unterstützen, sondern die Integrität des Gesamtsystems sicherzustellen.

Ich schreibe zb. in ein Feld den Namen der letzten Person die das Dokument editiert hat rein. Wie in deinem Bespiel genannt will ich dass eine Umbenennung angewendet wird, eine Löschung jedoch nicht, da ich den Editor ja wissen will auch wenn die Person das Unternehmen verlassen hat.
Der Umweg wie du Ihn über das Textfeld beschreibst funktioniert, jedoch muss ich bei jeder Abfrage des Wertes beide Felder abfragen -> Aufwändig.

Sauberer wäre es meines Erachtens wie beschrieben mit einem Trigger mit eigenem Code einmal über alle Dokumente drüberzuarbeiten um die Änderungen durchzuführen. Hier ist klarerweise der Entwickler der Anwendung gefragt für jeden Dokumenttyp einen entsprechenden Code zu schreiben.

[koehlerbv]

Meine persönliche Einstellung ist dass ein Name in ein Namensfeld gehört, genau so wie eine Zahl auch in ein Zahlenfeld soll.

Das eine hat mit dem anderen nichts, aber auch gar nichts zu tun.

Namen sind Text. Der Itemtyp bestimmt, wie Notes mit dem Inhalt umgeht (Autor, Leser, Darstellung im Frontend gegenüber Speicherung im Backend).

Das Beispiel mit den bisherigen Editoren ist meines Erachtens ein schlechtes. Hierbei handelt es sich ja um historische Werte. Wenn Du nach dem Abiturzeugnis der jetzigen Bundeskanzlerin suchst, kannst Du auch nicht auf eine "Umbenennung" hoffen - das findest Du unter "Angela Kasner".

Das von mir geschilderte Verfahren stellt eine sehr, sehr simple Umgangsform dar, ich hatte auch extra darauf hingewiesen.

Zum Trigger: Den Trigger gibt es, Du findest ihn in der AdminP. Das ein unmittelbares Signal an Deine DB durchgereicht wird, wäre aus verschiedenen Gründen kontraproduktiv (das Verfahren ist detailliert in der AdminHelp beschrieben) und unmöglich.

Bernhard

[Günther Rupitz]

Das eine hat mit dem anderen nichts, aber auch gar nichts zu tun.
Namen sind Text. Der Itemtyp bestimmt, wie Notes mit dem Inhalt umgeht (Autor, Leser, Darstellung im Frontend gegenüber Speicherung im Backend).

Ja, du hast natürlich Recht, Namen sind auch nur Text.
Nur mein Stil ist es eben dass ich einen Namen in einem Namensfeld vorfinden möchte - persönliche Einstellung.

Das Beispiel mit den bisherigen Editoren ist meines Erachtens ein schlechtes. Hierbei handelt es sich ja um historische Werte. Wenn Du nach dem Abiturzeugnis der jetzigen Bundeskanzlerin suchst, kannst Du auch nicht auf eine "Umbenennung" hoffen - das findest Du unter "Angela Kasner".

Genausogut können wir auch dein Beispiel mit dem Urlaub nehmen.
Ich wollte damit aber nur verdeutlichen dass es abhängig vom Dokumenttyp/Status des Dokuments/Worflowschritt halt in einem Fall notwendig ist eine Löschung/Umbenennung durchzuführen und im anderen nicht. Die Verwendung des Views "$AdminP" geht ja in diese Richtung zu differenzieren.

Zum Trigger: Den Trigger gibt es, Du findest ihn in der AdminP. Das ein unmittelbares Signal an Deine DB durchgereicht wird, wäre aus verschiedenen Gründen kontraproduktiv (das Verfahren ist detailliert in der AdminHelp beschrieben) und unmöglich.

Mit Trigger habe ich jetzt einen gemeint auf den ich in meiner Datenbank reagieren kann (also wie du es beschreibst "durchgereicht" wird).

[koehlerbv]

Nur mein Stil ist es eben dass ich einen Namen in einem Namensfeld vorfinden möchte - persönliche Einstellung.

Aber genau mit dieser Einstellung schaffst Du Dir ja die von Dir beschriebenen Probleme. Ich würde es daher eher "Marotte" nennen.

Genausogut können wir auch dein Beispiel mit dem Urlaub nehmen.
Ich wollte damit aber nur verdeutlichen dass es abhängig vom Dokumenttyp/Status des Dokuments/Worflowschritt halt in einem Fall notwendig ist eine Löschung/Umbenennung durchzuführen und im anderen nicht. Die Verwendung des Views "$AdminP" geht ja in diese Richtung zu differenzieren.

Nein, den Urlaub können wir nicht als Beispiel nehmen, denn hier geht es um ein Konto. Und eine Heirat macht niemals aus einer Person zwei (von schlechten Witzen abgesehen).

Was die Abhängigkeit vom Workflow-Status angeht: Genau das ist Sache des Programmierers, und der AdminP hilft dabei sogar. Dein Trigger ist die (erfolgreiche!) Umbenennung, und genau ab dann ist es Deine Sache, was passiert. Der AdminP hat alles richtig vorbereitet. Was unsereins sich da ausgedacht hat, kann der AdminP weder wissen - noch juckt es ihn irgendwie.

Bernhard

[Günther Rupitz]

Was die Abhängigkeit vom Workflow-Status angeht: Genau das ist Sache des Programmierers, und der AdminP hilft dabei sogar. Dein Trigger ist die (erfolgreiche!) Umbenennung, und genau ab dann ist es Deine Sache, was passiert. Der AdminP hat alles richtig vorbereitet. Was unsereins sich da ausgedacht hat, kann der AdminP weder wissen - noch juckt es ihn irgendwie.

Ja, du hast recht, es ist Sache des Programmierers das zu machen, das kann der Adminp auch gar nicht wissen wann was geändert werden soll.
Ich würde mir nur wünschen wenn es Namensfeldern irgendwie bestimmbar wäre ob eine Umbenennung/Löschung bei einem bestimmten Dokument/Feld greifen soll oder nicht. Mir ist schon klar dass es diverse Workarounds (wie dem 2. Feld als Textfeld) gibt um das Problem zu lösen. Ist das denn so schlimm mal danach zu fragen?

[koehlerbv]

Nein, natürlich ist das nicht schlimm, sondern macht ganz im Gegenteil den Sinn von AtNotes aus: Meinungsaustausch. Und dabei lernt jeder dazu, auch die Antwortenden 

Ich würde mir nur wünschen wenn es Namensfeldern irgendwie bestimmbar wäre ob eine Umbenennung/Löschung bei einem bestimmten Dokument/Feld greifen soll oder nicht.

Das verstehe ich nicht. Wenn ich den AdminP aussen vor lassen will bei einem "Namensfeld", dann verwende ich eben ein Textfeld.

Ich verwende zum Beispiel auch Notes Names, die im Rahmen eines Workflows von einem Text- in ein Names-Item wandern (können) - und vice versa.
Das Programmieren ist unter dem Strich nur reines Handwerk, man kann es - sehr übertrieben gesagt - einem Affen beibringen. Der Grips steckt in der Architektur 

Bernhard

[Günther Rupitz]

Das verstehe ich nicht. Wenn ich den AdminP aussen vor lassen will bei einem "Namensfeld", dann verwende ich eben ein Textfeld.

Damit bringst du dich aber um die Eingabemöglichkeiten/Darstellung in der Maske, gut das kann man natürlich auch umgehen.

Ich verwende zum Beispiel auch Notes Names, die im Rahmen eines Workflows von einem Text- in ein Names-Item wandern (können) - und vice versa.

Das muss dann aber ein Feld sein dass du rein im Backend verwendest, sonnst wird dir der Feldtyp automatisch überschrieben sobald man das im Frontend speichert ?!?

Über diese Möglichkeit muss ich mal nachdenken ....

Ich sehe auf jeden Fall dass ich mich mit diesem Thema bisher zu wenig auseinandergesetzt habe.
Eine Art Best-Practice zu dem Thema wäre super.

Das Programmieren ist unter dem Strich nur reines Handwerk, man kann es - sehr übertrieben gesagt - einem Affen beibringen. Der Grips steckt in der Architektur 

Nicht umsonnst gibts den Begriff Code-Monkey.
Nur ein bisserl beleidigt fühl ich mich jetzt schon wo du das so im zusammenhang erwähnst

[koehlerbv]

Ich verwende zum Beispiel auch Notes Names, die im Rahmen eines Workflows von einem Text- in ein Names-Item wandern (können) - und vice versa.

Workflow-relevante Items verwende ich ausschliesslich im Backend, die haben auch nie eine Entsprechung in Frontend-Elementen. Da gibt es nur was computed for display angezeigt und ggf. Hilfsfelder für die Auswahl von Personen (reine Eintagsfliegen, die beim Speichern schon wieder dahinscheiden).

Beispiel Urlaubsdatenbank: Da darf der User bei der Erstellung vier Felder manipulieren, dazu gibt es 11 cfd-Felder. Im Dokument stecken aber runde 50 Items, die für das "eigentliche Geschäft" zuständig sind.

Bernhard