ACL Workaround

[TMC]

Ich habe hier eine DB in R5, bei der haben alle User Editor-Rechte - dies soll auch so aus anderen Gründen nicht geändert werden (dies zu erklären würde jetzt wohl zu weit führen).

Anyway, in dieser DB erzeuge ich eine neue Maske. Ich möchte es nur Usern, die die Rolle [ABC] haben, gestatten, die Dokumente mit dieser Maske (also FIELD = "MASKE ABC") zu bearbeiten.
Lesen darf jeder, somit fallen Leserfelder aus.

Klar, jetzt könnte ich in den Events 'PostOpen' und 'Querymodechange' entsprechend die Rolle abfragen und dann den Edit-Modus verbieten oder nicht.

Dies erscheint mir etwas umständlich. Gibt es da noch eine einfachere Möglichkeit, Usern, die eigentlich DB-global Rechte für das Ändern von Dokumenten haben, nicht die Möglichkeit zu geben, Doks mit Maske XYZ zu ändern?
Oder bleibt mir hier nur ein 'PostOpen' und 'Querymodechange' übrig?

Im Prinzip fehlt mir ein Feld vom Typ "Editor" (nicht: Autor). Aber dies ist ja (verständlicherweise) gegen jede Logik der ACL.

[Glombi]

In so einem Fall verwende ich immer kontrollierte Abschnitte. Die ziehe ich dann über alle Felder der Maske.
Man muss aber bedenken, dass die Dokumente von außen geändert werden können. Aber das ist ja auch mit dem Verbieten des Bearbeitenmodus so.
Und die wenigsten User wissen, wie man so ein Dokument manipuliert.

Andreas

[Glombi]

Was auch noch ginge, wären 2 Masken und dann mit Maskenformeln in den Ansichten zu arbeiten.
Eine Maske hat nur berechnete Felder und diese Maske wird dann in den Ansichtsformeln für die Maskenformel herangezogen, falls der User nicht die Rolle hat.
Das ist aber wesentlich aufwändiger als einen Abschnitt zu erstellen. Es bietet sich aber an, wenn man bestimmte Infos gar nicht oder anders anzeigen will.

[TMC]

Danke für Deine Tipps/Erfahrungen, Andreas.

Hmm, mal zusammenfassend haben wir schonmal 3 Alternativen
a) Sperrung der Rollen über QuerySave und PostOpen
b) kontrollierte Abschnitte
c) mit 2 Masken arbeiten

Zwischenfazit für mich:
Da ist es wohl hier am einfachsten und schnellsten umzusetzen, wenn man mit QuerySave und PostOpen agiert.

QuerySave / PostOpen kann imho einen Nachteil haben, wenn man dort schon umfangreiche andere Codes platziert hat. Aber bei sauber strukturierten Codes sollte dies kein Problem darstellen, diese Abfragen zu integrieren.
100% traue ich aber QuerySave / PostOpen aber nicht. Man muss da wirklich strikt auch das uidoc auf Nothing setzen. Wehe es ist noch ein anderes Dok im Fokus, dann kann ein User u.U. doch in den Edit-Modus wechseln.

[koehlerbv]

100% traue ich aber QuerySave / PostOpen aber nicht. Man muss da wirklich strikt auch das uidoc auf Nothing setzen. Wehe es ist noch ein anderes Dok im Fokus, dann kann ein User u.U. doch in den Edit-Modus wechseln

Äh, QueryModeChange und PostOpen, oder ? Und damit sollte es keine Probleme geben. Focuswechsel - was soll da passieren ? Die Events wirken auf das betreffende Dokument, egal, was der User zwischendurch treibt.

Ich habe noch eine weitere Variante im Angebot (auch wenn ich zusätzlich mit den Events oder Teilmasken deale, jedoch nicht mir kontrollierten Abschnitten - ist mir zu suspekt oder zu aufwändig):
Doppelte Felder. Eines zum Editieren, eines Computed For Display. Dazu ein Computed For Display Field, welches dir Rolle(n) auswertet und eine Einstellung trifft für die Hide-whens: Darf User oder darf User nicht.

Es kommt hier immer auf den Zusammenhang und dem damit verbundenen Aufwand an.

Bernhard

[Semeaphoros]

Die Bemerkung zum Focus von Bernhard wollte ich auch machen, Matthias, hast Du das schon mal erlebt, dass ein Dokument, das den Fokus nicht hat, indirekt in den Edit-Modus gesetzt wurde und dabei die Events nicht gefeuert wurden? Das wäre definitiv ein Bug, denn das sind UI Events, und systemweit (nicht nur applikationsweit) kann nun mal nur ein Fenster und damit nur ein Dokument den Focus haben.

[TMC]

Bernhard, danke für die Korrektur, soll natürlich "QueryModeChange und PostOpen" heissen :-)

Ich habe - nicht reproduzierbar - schon mal Probleme gehabt. User hatte irgendwie auch Mailfile geöffnet, hat da einen Link zur DB geöffnet, "ein wenig rumgeklickt", und da war auf einmal das Dok im Edit Mode.
Leider nicht ganz reproduzierbar gewesen. War auch keine App von mir, muss ich zu meiner Entschuldigung sagen, und die Events waren ellenlang.

Doppelte Felder sind in der Tat auch noch eine Alternative!

Mit dem Zusammenhang hast Du Recht, ich denke ich werde jetzt bei "QueryModeChange und PostOpen" hängen bleiben und dies in diesem Fall so umsetzen, da hier am praktikabelesten.

Danke Bernhard und Andreas für Eure Erfahrungen!

Matthias

[Glombi]

Abschnitte oder doppelte Felder sind dann angebracht, wenn später die Anforderung kommt: Hatte ich es bereits gesagt? Der User soll nur dieses eine Feld da bearbeiten! Nein? Sorry, aber es ist doch bestimmt nicht aufwändig  

[TMC]

@Jens (habe das erst danach gelesen, 17 Sekunden waren zum Schreiben zu wenig  )

Siehe oben meinen letztes Posting. Selber konnte ich es nicht reproduzieren. Client war 5.08 oder 5.011. User hatte angeblich da dann das Dok im Editmodus.
Nicht auszuschließen ist allerderdings ein fehlerhafter QueryModeChange/PostOpen - Code.
War für mich etwas beunruhigend.

[Semeaphoros]

Also das würd ich auch meinen, entweder war der Code falsch, oder fast noch wahrscheinlicher, ein wild in der Gegend rumklickender Enduser, der halt auch mal daneben doppelklickt und dann wie in Trance das nach hinten geschobene Fenster wieder hervorholt ...

oder bei eingebetteten Links noch fast wahrscheinlicher: diejenigen, die einfach alles mit einem Doppelklick bedienen, auch die EinKlickLinks. Was passiert da, wenn man den Link verfehlt und daneben doppelklickt? Kleines Flickern am Bildschirm und dann wird eben nochmal am richtigen Ort gedoppelklickt. Der Link geht auf, daber das Urdokument ist unterdessen ebenfalls im E-Mode

[TMC]

ein wild in der Gegend rumklickender Enduser, der halt auch mal daneben doppelklickt und dann wie in Trance das nach hinten geschobene Fenster wieder hervorholt ...
diejenigen, die einfach alles mit einem Doppelklick bedienen, auch die EinKlickLinks. Was passiert da, wenn man den Link verfehlt und daneben doppelklickt? Kleines Flickern am Bildschirm und dann wird eben nochmal am richtigen Ort gedoppelklickt. Der Link geht auf, daber das Urdokument ist unterdessen ebenfalls im E-Mode

Nightmare-User   Hat am Wochenende zuviel Speed und XTC eingenommen und will am Montag wieder die Arbeit vom Freitag einholen weil er da gepennt hat.

Entweder der Personalchef schickt ihn in einen Coffeshop nach Holland damit er wieder runterkommt, oder man klemmt am besten Notes ab.
Da gibt es doch API-Methoden, um zu messen, wie oft / Sekunde jemand die Maustaste klickt? Vielleicht sollte man das einbauen und dann bei > X den Zugang sperren  

[Semeaphoros]

Nicht nur die, es gibt auch solche, die einfach nicht wissen, was sie tun, schon fast krankhaft irgendwo drauflos klicken, ohne es selber wirklich zu merken.