DMS.CheckPermission(s) aus Python nutzen

Python/ecmind_blue_client
1

Hallo zusammen,

ich habe wie mit einigen von Euch besprochen versucht, mich des Themas von DMS.CheckPermission bzw DMS.CheckPermissions abzunehmen. Daraus haben sich für mich diverse Fragen ergeben. Selbst gebraucht hatte ich die Funktionen nur wenig bisher, deshalb bin ich für alle Hinweise dankbar. Dem Handbuch entnehme ich indirekt, dass DMS.CheckPermission eine sache mehr macht als DMS.CheckPermissions (dafür aber nur für ein Objekt): Das Prüfen von Ablagenobjekten und inaktiven Varianten. Sehe ich das richtig?

Falls das keiner direkt braucht, hätte ich diese Sonderlocke deshalb weggelassen und alles via DMS.CheckPermissions gemacht. Ich habe meinen Prototyp temporär hier hinterlegt (Stand 11.02.2022):

Wie an den Tests zu sehen ist, kann damit bereits die Berechtigung von Objekten erfragt werden:

test_type_id = 262144
test_object_ids = 

check_permissions_result = check_permissions.check_permissions(
    client=Client('localhost:4000:1', [...]), 
    objects={262144: [38, 43, 54]}
)

Weiterhin ist es möglich zu prüfen, wie die Rechte beim Verschieben wären:

check_permissions_result = check_permissions.check_permissions(
    client=self.client, 
    objects={262144: [38]},
    folder_id=546,
    register_id=546,
    register_type_id=99
)

Allerdings gefallen mir daran gleich mehrere Dinge noch nicht so richtig:

  • Ist es sinnvoll, dieses zuerst gezeigte Prüfen der Rechte und das zu zweit gezeigte Prüfen der Verschieben-Rechte so in eine Funktion zu packen, nur weil es von der DMS-API so gemacht wurde?
  • Ist die Übergabe der Objekte als Dict of Ints & List of Ints, also als Dictionary von Type-IDs und Listen von Objekt-IDs selbsterklärend genug und in guter Darreichungsform? Oder wäre viel sinnvoller, wenn man hier (auch) interne Namen hätte, was dann aber immer umgerechnet werden müsste. Dies wäre bei einzelnen Aufrufen sicher komfortabler, bei massenhafter Verwendung würde es hohe Kosten verschleiern.
  • Ich habe auch den Rückgabewert an den Eingabewert angelehnt, nur das dies dann ein Dict of Ints & Dict of Ints & Access zurückgibt.
    • Beispielrückgabe im Ist-Zustand: {262144: {38: RWXDU, 43: RWXDU, 54: RWXDU}}
    • Alternativ könnte ich mir vorstellen, nur ein Dict mit den Objekt-IDs als Keys und den Access-Rechten als Werten zurückzugeben (oder braucht es die Aufteilung nach Typ-IDs noch)?
    • Das wäre sonst nur noch so: {38: RWXDU, 43: RWXDU, 54: RWXDU}
2

Hallo @rk,

Zu deinen Fragen:

  1. Ist es sinnvoll, dieses zuerst gezeigte Prüfen der Rechte und das zu zweit gezeigte Prüfen der Verschieben-Rechte so in eine Funktion zu packen, nur weil es von der DMS-API so gemacht wurde?

An sich finde ich es auch eher ärgerlich mit zwei Methoden, aber der folgende Satz in der Server-API bei Check Permissions scheint auch eine Einschränkung zu beschreiben:

Da es bei diesem Job sehr auf Performance ankommt, werden keine Ablagenobjekte, keine inaktiven
Varianten und keine Freigaben berücksichtigt.

Daher wäre ich dann doch eher für zwei Methoden auch wenn sich diese ziemlich ähneln.

  1. Ist die Übergabe der Objekte als Dict of Ints & List of Ints, also als Dictionary von Type-IDs und Listen von Objekt-IDs selbsterklärend genug und in guter Darreichungsform? Oder wäre viel sinnvoller, wenn man hier (auch) interne Namen hätte, was dann aber immer umgerechnet werden müsste. Dies wäre bei einzelnen Aufrufen sicher komfortabler, bei massenhafter Verwendung würde es hohe Kosten verschleiern.

Ich würde es so lassen. Vielleicht sollten wir eine weiter Methode implementieren, die das Mapping von InternerName zu ID zurück gibt und cached.

  1. Ich habe auch den Rückgabewert an den Eingabewert angelehnt, nur das dies dann ein Dict of Ints & Dict of Ints & Access zurückgibt.

Ich würde es ohne die Aufteilung auf Typ-IDs zurückgeben.

3

Das hatte ich mit dem ersten Spiegelstrich/Punkt nicht gemeint. Dafür beantwortet Dein Satz den ersten Absatz:

Der erste Spiegelstrich…

… bezieht sich auf die Tatsache, dass enaio hier zwei „etwas“ unterschiedliche Dinge mit Überladung in eine Funktion packt. Darunter leidet die Selbsterklärungskraft der Funktionsnamen, finde ich. Einmal holt man sich die Objektrechte, im anderen Fall die „Erlaubnis“, das Objekt zu verschieben.

4

Hallo @rk

ich finde die Funktionen sehen doch schon sehr gut aus. Ich denke es sollte auch verständlich sein, wie diese funktionieren.

Eine Funktionalität würde mir noch fehlen - zumindest habe ich sie nicht entdeckt.
Es wäre gut, wenn man der Funktion einen Benutzer(Benutzername / Benutzer-ID) mitgeben könnte, für den man die Rechte prüfen will. Im Prinzip sollte dadurch der Job-Kontextwechsel schon inbegriffen sein.

5

Hallo zusammen, aus den Anregungen und den dazwischenliegenden Gesprächen habe ich Folgendes mitgenommen und implementiert:

  • Die Funktion check_permission hat neu den Eingangsparamter context_user, mit dem wie von @danielstraub angeregt der User gewechselt werden kann.
  • Weiterhin gibt es neu den Parameter special_cases (ein blöderer Name ist mir nicht eingefallen), welcher auch die Ablagenobjekte, inaktiven Varianten und Freigaben beachtet.
    • Wenn special_cases = True ist, nutzt die Funktion die API-Implementation DMS.CheckPermission anstelle von DMS.CheckPermissions.
    • Auch bei nur einer Übergabe und special_cases = False wird die (wohl schnellere) DMS.CheckPermissions-Funktion genutzt.
    • Werden beim special_cases = True mehrere Objekt-IDs übergeben, wird durch die neue Funktion der DMS.CheckPermission-Aufruf in Schleife ausgeführt, sodass man dies nicht in jedem Fall wieder zu Fuss implementieren müsste.
  • Wie auch von @uw befürwortet, habe ich die Ergebnisliste nun verflacht und es wird nur mehr ein Dictionary über Object-IDs und deren Rechte geliefert. Also z. B. {38: RWXDU, 43: RWXDU, 54: RWXDU}

Eine Frage hätte ich jetzt noch: Ich würde diese effektiv eine Funktion nur ungern in ein eigenes Modul packen. Seht Ihr das

  • als Kernfunktion, sprich als Teil von ecmind_blue_client oder
  • passt es eventuell zu ecmind_blue_client_manage mit seinen Funktionen wie get_users, get_sessions, get_system_roles etc. oder
  • doch lieber etwas Eigenes?
6

Ich würde sagen im ecmind_blue_client_manage wäre die Funktion gut angesiedelt. Dieses Modul übernimmt man sowieso in sein Projekt, sobald man etwas mit Usern/Rechten machen will.

7

Ich finde ecmind_blue_client_manage auch einen guten Ort.

8

Hallo zusammen, und danke für Euer Feedback. Entsprechend habe ich den Entwurf in die neue, auf eine ganze Minor-Version gerundete Version von ecmind_blue_client_manage übernommen:

Dort gibt es nun wie erwartet die Funktion manage.check_permission(...) und die Access-Klasse. Das bisherige Entwicklungsprojekt habe ich archiviert.