Hallo zusammen,
ich stehe vor dem Problem das ich bei unseren Mailfiles die ACL aufräumen muss. Ziel ist es ausser dem Mailfileowner alle weiteren Personen die manuell der ACL hinzugefügt wurden, nach Access und Delegation zu "überführen". Hat von Euch schon mal jemand Erfahrung damit gemacht, in das entsprechende Profildokument zu schreiben bzw Tips, was dabei zu beachten ist? Falls ihr noch mehr Infos braucht sagt bescheid.
Viele Grüße,
Bernard
AFAIK ist das ein Agent, der beim Speichern ausgelöst wird, der die Einstellungen aus dem Profildokument in die ACL schreibt. Den müsste man irgendwie antriggern, oder notfalls nachbauen.
Die Frage ist aber, ob du dir das antun möchtest. Jeder User ist für seine eigene DB und deren Rechtestruktur verantwortlich. Es wird dem User ein Leitfaden in die Hand gegeben, der es ihnen ermöglicht, das nachzutragen. Und ab einem Stichtag X werden alle ACLs geputzt. Wer dann nicht aufgeräumt hat, der hat eben Pech.
Wenn du da Hand anlegst, wirst du aller Wahrscheinlichkeit nach auch den Kopf dafür hinhalten müssen, dass -mindestens- die ACLs korrekt ins Profildokument übernommen wurden und b) darfst du dich vermutlich auch mit Nachfragen rumschlagen, warum bspw. eine Person Editor mit Löschrechten ist, obwohl Leserechte auch reichen würden. Und dann erklär mal dem User, dass das schon immer so wahr...
Selbst wenn du dir einen Katalog auf die Seite legst: wie lange willst du den aufheben, um sämtliche jemals womöglich auftretenden Nachfragen zweifelsfrei beantworten zu können? Ich weiß nicht, ob das so eine weise Entscheidung ist...
Aber wie dem auch sei: schau dir mal die Maske an und auch die Agenten ... da war irgendwas, erinner ich mich dunkel.
Diese Frage ist QUATSCH...
WEIL: Die ACL ist der Ort, an der die Berechtigungen gespeichert sind. Das Kalenderprofil bietet nur ein Frontend für den Benutzer, um die ACL zu bearbeiten. Wenn der User selbst nur Editor ist, dann wird zur Pflege der ACL der Adminp "missbraucht", aber im Ende ist es IMMER die ACL die zieht. Ein "überführen" ist also gar nicht möglich.
Dass die ACL die Rechte steuert und kein Profildokument, das wird -glaube ich- nicht in Abrede gestellt.
Sofern ich das richtig verstanden habe, geht es nur darum, dass die für den User sicht- und bearbeitbare Einstellmöglichkeit dem entspricht, was in der ACL jetzt bereits steht und nachher auch wieder stehen soll und prinzipbedingt (wie du sagst: AdminP) auch wieder stehen wird.
Nein, was im Profile steht, ist völlig Banane. Im Profile finden sich ggf. Hinweise, was mal an den AdminP übergeben wurde. Nicht mehr, nicht weniger.
Bernhard
Ich muss Dich korrigieren Bernhard: beim öffnen des Kalenderprofils wird die ACL aktiv ausgelesen, und alle Einträge in der ACL, die einer über das Profil einstellbaren Berechtigungsstufe entsprechen (maximum dürfte editor mit Löschrecht sein), werden dann dort dargestellt. Aus diesem Grund kann auch folgendes passieren:
Der Benutzer A mit Editorrechten auf seine eigene Datenbank öffnet das Profil. Er gibt Benutzer B ein bestimmtes recht und schliesst das Profil mit ok. Um zu prüfen, ob er alles richtig gemacht hat, öffnet er direkt danach das Profil erneut... Und wundert sich: seine gerade gemachte Änderung ist verschwunden.
Warum ist das so: weil der user selbst nur Editor ist, wurde ein Adminp- Request für das Update der ACL erstellt, und der muss natürlich erst abgearbeitet werden. WÜRDE nun der Stand im Profil gecached, dann würde der User denken, die Berechtigung wäre vergeben und sich dann wundern, warum Benutzer B nicht zugreifen kann, obwohl er doch da drin steht...
Das Profil ist immer eine "Echtzeit" Abfrage...
Und sobald der Adminp seine Arbeit getan hat, sieht man das Ergebnis auch im Profil.
