Frage zur Einstellung "Leser-/Autorenfelder ändern" in ACL

[Norton]

Hallo zusammen,

ich habe eben mit Kollegen darüber nachgedacht, welchen Sinn es haben mag die Option "Leser- und Autorenfelder immer ändern" nicht zu setzen? Bisher habe ich hierzu noch keine Idee   gehabt, weswegen ich mit dem Gedanken spiele, dies auf allen Datenbanken unserer Server einzustellen.

Hat vielleicht einer von euch einen Hinweis, warum ich das nicht tun sollte?

Danke und Gruß
Thomas

[Peter Klett]

Zwei Denkansätze ...

... aus Adminsicht:

Datenbanken, in denen keine Leser- oder Autorenfelder vorhanden sind, brauchen vom adminp nicht angefasst zu werden (Entlastung des Servers)

... aus Entwicklersicht:

Wurden Masken so gebaut, dass Autorenfelder sichtbar sind und auch der Dokumentation dienen, verschwindet die Information über einen Autor eines bestimmten Zustandes beim Ausscheiden des Mitarbeiters, da der Username aus dem Autorenfeld entfernt wird. Das ist sicherlich eine wackelige Argumentation, wir hatten solch ein Problem mit der Änderung von Namensfeldern, was durch Änderung in "Leser- und Autorenfelder ändern" behoben werden konnte.

[koehlerbv]

Diese Argumentation ist nicht wacklig, Peter, sondern extrem wichtig: Informationen über Personen in Namensfeldern (Leser, Auroren, Names) können nur aufgehoben werden, wenn sie auch nochmals in Textfeldern gespeichert werden, sonst sind sie bei Löschungen futsch.

Keine Anpassung von Namesfeldern (ich erspare mir jetzt die Aufteilung in Leser/Autoren-Felder und "alle Namensfelder) würde aber den AdminP nicht ranlassen, wenn man Umbenennungen durchführt. Also brauchte man ein eigenes Verfahren. Auch doof.

Also braucht man eine Entscheidung, wann man sekundär gespeicherte Namensangaben nachführt, wenn man das braucht. Wenn man die zum Beispiel in einer Simple-Doof-mit-Notes-einfach-zu-machenden Datenbank den Antragsteller oder den Entscheider immer aufheben möchte und einen immer nur den Status bei der Antragserstellung interessiert, dann speichert man den eben nur zusätzlich in einem Textfeld, und nur das wird angezeigt.

Will man Umbenennungen via AdminP haben, Löschungs-Probleme aber vermeiden, dann wäre ja schon in Ansichten hilfreich, die den gespeicherten (pure text) Namen anzeigen im Falle, dass das Names Item - ooops- leer ist.

Will man weiter gehen, braucht es mehr Aufwand. Ich verwende den, kann also bei weiteren Fragen wieder Auskunft geben (so ich Zeit habe). Man kann sowas zu einem Standardprocedere ausbauen und dann in jeder Anwendung verwenden (der kluge Programmierer ist ja nur einmal fleissig und dann faul ;-).

Bernhard

[cg-home]

Hi Ihr,

genau dieses Thema beschäftigt mich auch gerade und ich wollte dazu auch schon eine Frage
reinstellen. Für Namensänderungen z.B.: bei Heirat oder wenn der Name falsch geschrieben
ist und der User es erst nach einem halben Jahr merkt (fragt mich nicht warum das erst so spät
bemerkt wird) ist es sehr sinnvoll das Autoren und Leserfelder automatisch angepasst werden
auch wegen Zugriffsproblemen.
Daher habe ich das schon vor langer Zeit in einigen DBs eingestellt
(Urlaube, Weiterbildung, Verträge, Verbesserungsvorschläge, CRM usw.)
In meinen DBs lasse ich aus diesen Feldern meist immer noch ein Textfeld mit dem Common-Name berechnen.
Stellenwese sind es natürlich auch Pflichtfelder. Wenn jetzt ein User die Firma verlässt werden diese
Namen einfach gelöscht. Ein ggf. neues berechnen des Dokumentes killt dann auch das Textfeld mit
dem CN-Namen. Dadurch kann es dann sein das Kategorien flöten gehen oder dass das Dokument nicht mehr
gespeichert werden kann, weil es ein Pflichtfeld ist.
Ich habe auch schon überlegt was ich dagegen tun könnte, bin aber bisher auf keinen grünen Zweig gekommen.

Am besten wäre es derzeit aus meiner Sicht, wenn die Änderungen der Namen nur durchgeführt werden
wenn es sich um eine Namensänderung handelt aber bei Löschungen keine Namens, Leser und Autorenfelder
geändert werden. Gibt es so eine Einstellung? Bitte sagt ja!!

Ich bin schon kurz davor mich dazu zu entscheiden, dass ich die Felder nicht mehr ändern lasse und bei
Namensänderungen selbst Hand anlege und Standardmäßig dafür entsprechende Ansichten und Agenten einbaue
die ich dann manuell los trete. Aber das gefällt mir auch nicht, da ich eher fault bin und ich Automatismen eigentlich mag.
Allerdings kommen derzeit Namensänderungen sehr selten vor 3-5 mal im Jahr bei uns.

@Bernhard

Will man weiter gehen, braucht es mehr Aufwand. Ich verwende den, kann also bei weiteren Fragen ieder Auskunft geben (so ich Zeit habe). Man kann sowas zu einem Standardprocedere ausbauen und dann in jeder Anwendung verwenden (der kluge Programmierer ist ja nur einmal fleissig und dann faul ;-).

Ich wäre auf jeden Fall an Deiner Standardprozedur interessiert, also wenn Du mal Zeit hast das zu erklären
wäre ich sehr dankbar dafür. Vielleicht wäre das sogar ein Best Practices Thema.

Gruß Christian

[Norton]

Sehr interessante Ansätze. Vielen Dank erst einmal. Ich werde das bei der nächsten Gelegenheit mit meinen Kollegen diskutieren. Erst einmal danke.

[Peter Klett]

@Bernhard: Zum Thema "wackelige Argumentation"

Ich fand die Argumentation deshalb wackelig, da ich Steuerung des Dokuments und Dokumentation der Handlungen immer trennen würde.

Beispiel: Ein Dokument durchläuft zwei Schritte bis zur Fertigstellung, die beteiligten Personen je Schritt sollen dokumentiert werden und die Dokumente immer lesen können.

Lösungsmöglichkeit: Für den Beteiligten je Schritt ein Leserfeld einbauen, das sorgt dafür, dass jeder Beteiligte das Dokument lesen kann, gleichzeitig erkennt man am Dokument, wer der Beteiligte war.

So weit, so gut.

Und dann kommt das, was NIE passiert: Plötzlich soll der Beteiligte des ersten Schrittes das Dokument nicht mehr lesen dürfen, wenn es den zweiten Schritt erreicht hat. Da kann ich die Datenbank praktisch wegwerfen und neu von vorne anfangen (bzw. strukturell umbauen und per Agent die alten Dokumente umbügeln). Besser ist doch, sich gleich alle Optionen offen zu lassen. In diesem Fall also die Beteiligten in Textfeldern speichern und ein separates Leserfeld ergänzen, in das die Beteiligten (und irgendwelche Admin- und Serverrollen) aufgenommen werden. Und das natürlich nicht so, dass das mit einem ToolsRefreshSelectedDocs zerstört wird (also das Leserfeld nicht berechnet, sondern berechnet beim Anlegen, und die Füllung z.B. per Script im Querysave).

Und wenn man das so baut, ist meine Argumentation "wackelig", weil sonst die ganze Anwendung "wackelig" ist ...

EDIT: Bei Autorenfeldern verbietet es sich sowieso. Auf ein freigegebenes Dokument darf m.E. kein Benutzer ein Autorenrecht haben, daher geht eine Dokumentation über Autorenfelder überhaupt nicht.