Empfohlene Zugriffsrechte in der Raum & Ressourcen DB

[Glombi]

Hallo
nach meinem Dafürhalten ist es am sinnvollsten, dem "normalen" Anwender Editorrecht zu geben.
Warum?
- Die Aktion "Reservierung löschen" ist nur für Editoren und höher sichtbar.
- Ein Bearbeiten ist nur für den Ersteller einer Reservierung möglich (das wird im QueryModeChange) abgefangen. Daher kann ein Editor erstmal keinen Schaden anrichten.

Wie haltet Ihr das?

Andreas

[CarstenH]

Dem "normalen" Nutzer gibt man sinnvollerweise Autoren-Rechte +Erstellen +Löschberechtigung.

Den Raumverwaltern kann man Editor-Rechte geben (ab Editor sind zusätzliche Aktions-Schaltflächen wie "Löschen" zu sehen die ich dem "normalen" Benutzern nicht geben möchte - sonst löscht er plötzlich fremde Reservierungen oder ändert auf andre Art und Weise Dokumente. Raumverwaltern unterstelle ich mal mehr Verantwortungsgefühl.

Editor ist das höchste Recht das man auf Dokumentebene überhaupt vergeben kann. Damit ist dieses Recht eigentlich immer Verwaltern der Daten vorbehalten die mit dieser Verantwortung auch umgehen können. Sämtliche Autorenfelder und diesbezüglichen Automatismen werden beim Editor unwirksam, Tricksen via QueryIrgendwas in Masken und DB-Scripten halte ich für sehr fragwürdig da etliche Hintertüren offen bleiben.

[Glombi]

Bei Autorrecht besteht das Problem, dass der User eine Reservierung, die er direkt in der R&R Datenbank gemacht, nicht mehr löschen kann.
Denn die Aktion zum Löschen sehen nur Editoren.

Andreas

[CarstenH]

Das ist korrekt - allerdings kann man mit wenigen Handgriffen die Hide-When-Formel der Shared Action ändern und auf den Autor prüfen, zzgl. der zeilenweisen Hide-When-Prüfung in den Ansichtseigenschaften. Alternativ blendet man die Löschaktion in der Ansicht "Meine Reservierungen" permanent ein, das wäre noch einfacher.

Die Alternative mit Editor sieht düster aus: jeder kann alle (!!!) Reservierungen löschen wie er lustig ist. Hab mir den Löschagenten grad mal angeschaut, wie vermutet prüft der scheinbar keinerlei Verwaltungsfelder der zugehörigen Raum- und Ressourcen-Dokumente. Wenn man das einbauen würde wäre der Editor sicher auch machbar, die Änderungen an der Hide-When-Formel der Aktionsschaltfläche sind aber it erheblich weniger Aufwand machbar.

Anmerkung: Hab auch grad nochmal vorsichtshalber in die KB geschaut und wurde dort bestätigt, Autor ist das empfohlene Recht.

[Glombi]

Wir reden aber von der R6 Schablone oder? Denn da sind jede Menge Abfragen, bevor man löschen kann.

Eine Design Anpassung an Standards ist unglücklich finde ich.

Andreas

[CarstenH]

Jupp, wir reden von der 6er R&R (sind ja auch im 6er Forumsbereich daher ging ich davon auch aus *g*).

Ich gebe dir auf jeden Fall Recht was deine Bedenken bezüglich Anpassungen an Standardtemplates betrifft. Ich gehöre auch eher zu den konservativen Verfechtern der Notesfraktion die nur dann Anpassungen vornehmen wenn der Nutzen (Funktion + Usability) den Aufwand (erneutes Anpassen nach Updates) und Ärger (kein Support, keine Hotfixes etc) übersteigt.

Im vorliegenden Fall muß ich aber leider feststellen, daß die R&R beim geschilderten Problem mit der heißen Nadel gestrickt wurde - oder zumindest lieblos (weil unvollständig) umgesetzt wurde. Die Abfragen vergessen alle schlichtweg auf die Verwaltungsfelder zuzugreifen - lediglich der Dokumentautor wird abgefragt (für die Info-Mail) und ob man Editor ist (sehr sinnige Abfrage).

In jedem Anfängerkurs bringen wir Trainer den künftigen Programmierern bei daß Autor (aus verständlichem Grund) das normale Recht und Editor das Verwalterrecht bei Anwendungen sein sollte.

Man hat jetzt die Wahl zwischen zu vielen Rechten und potentiellem Ärger wenn jemand diese (absichtlich oder versehentlich) auch benutzt - oder zu wenig Rechten und damit verbundenem zusätzlichem Aufwand durch Raumverwalter etc. Das erinnert mich ein wenig an alte Zeiten wo man den Nutzern zum Aktivieren des OoO mehr als nur Editor-Rechte in seiner Mail-DB geben mußte und damit verbunden auch gleich das Recht viel Mist zu bauen.

Man kann das jetzt sicher noch endlos ausführen - es bleiben letztendlich nur 3 Varianten:

a) [kleinere] Design-Anpassungen um wenigstens die gröbsten GAUs mit Reservierungen durch Nerds zu verhindern;
b) dem Normaluser gehört der Autor, den Verwaltern der Editor - damit sind Fehllöschungen nur durch Verwalter möglich, von denen gibts aber nur eine Handvoll und die lassen sich einweisen. Außerdem setzt i.d.R. der Posten eines Verwalters einen gewissen IQ voraus (meiner Meinung nach)
c) alle bekommen den Editor - dann ists nur eine Frage des IQ's der Nutzer ob und wann du Probleme bekommst.

Ich persönlich tendiere zu b) oder bei exzessiver Nutzung [leider] sogar zu a)

[MartinG]

Ich bin ja auch kein grosser Freund von Anpassungen, aber eine Hide-When Formel zu ändern und halt auch entsprechend zu dokumentieren halte ich in diesem Fall eigentlich für die beste Lösung.

Wobei ich sagen muss, das von unseren Usern keiner über die Resourcendatenbank eine Reservierung löscht...

[Glombi]

Ein Editor kann keine Reservierungen anderer Leute löschen, daher sehe ich eigentlich keinen Grund, Editorrechte nicht zu vergeben.

Andreas

[CarstenH]

Leider kann ein Editor mit Löschrechten eben beliebige Reservierungen löschen. Genau darüber unterhalten wir uns ja die ganze Zeit.

PS: da niemand unfehlbar ist hab ichs gerade nochmal getestet - und es geht wirklich. es kommt 1 Abfrage ob man die gewählte Reservierung wirklich löschen möchte - bestätigt und das wars.

[Glombi]

Leider kann ein Editor mit Löschrechten eben beliebige Reservierungen löschen. Genau darüber unterhalten wir uns ja die ganze Zeit.

PS: da niemand unfehlbar ist hab ichs gerade nochmal getestet - und es geht wirklich. es kommt 1 Abfrage ob man die gewählte Reservierung wirklich löschen möchte - bestätigt und das wars.

Daher meine Frage nach Notes 6. 
Mit der Notes 6 R&R Datenbank darf ein Editor keine Dokumente löschen - siehe Screenshot.

Andreas

[CarstenH]

Seltsam - ich bin weder Autor noch Besitzer der Test-Reservierung gewesen. Welche Version genau setzt du ein? Scheinbar gabs eine Änderung am Template die ich nicht habe. Das wäre ja erfreulich wenn die das Problem endlich mal gefixt hätten.

[Glombi]

Ich habe das Template der Version 6.5.3 mit LP deutsch.

Wenn man Managerrecht hat, darf man löschen. Editoren dürfen nicht.

Andreas

[CarstenH]

In dem Fall hast du natürlich Recht und Editor wäre der korrekte Level. Ich werde meine R&R-DB's auch mal auf einen neueren Stand bringen müssen, scheint sich ja was getan zu haben. Dann gelten meine vorherigen Anmerkungen nur für die älteren Versionen - mal in die Fixlist schauen ob sich das genaue Release der Erweiterungen ermitteln läßt (falls wieder ein Problem damit bei einem Kunden auftaucht).

Danke nochmal - auch wenns eigentlich dein Topic war - ich finde die Diskussion hat sich dennoch gelohnt.