UMGT - weiß nicht ob ich alles verstanden hab

Hier finden sich Fragen und Ergänzung zur Dokumentation. // All questions and discussions about the documentation.
Antworten
dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 18.02.2014, 22:35:41



edit: achtung! erst bis zum letzten Post lesen. hab einige ansichten geändert


Hallo,

ich blicke leider noch nicht ganz durch beim umgt. z.b. bei appProxy und AppProxyType weiß ich noch nicht was da gemeint sein soll und wie man das nun verwenden kann. und der unterschied zu permission ist mir auch nach lesen aller beiträge von christian zu dem thema noch nicht ganz klar.

wenn ich in die EXAMPLE_umgt_objects.ini schaue steht da z.b. über AppProxy
;
; Defines an application proxy object. This is an object that
; represents an user's application object, the current user
; has access to.

;
; As of release 1.15 this object specifies the quality of access
; the user is granted. This is read, write, link, and delete.
; Read access can be defined implicitly, by creating a proxy
; object or explicitly, in case you are creating a proxy object
; for each object to distinguish by the proxy object's read
; property.
;
und über AppProxyType
; Defines an application proxy object. This is an object that
; represents an user's application object, the current user
; has access to.
die fettgedruckten zeilen sind doch exakt gleich, oder? das verwirrt mich ein bisschen. :D
und dann ist es noch verwirrend, dass die domainobjects nicht appProxy und AppProxyType heißen sondern VisibilityDefinition und VisibilityDefinitionType.

Aber ich versuch erstmal mal zu erzählen wie ich das so verstehe. vielleicht befinde ich mich ja doch so in der richtigen richtung.

angenommen ich hab nun ne seite mit usern. und diese seite hat nen newsbereich. nun soll der newsbereich nicht von jeden editierbar sein. und für mache auch nicht sicht bar.
also z.b. user A darf nur sehen, user B editieren und user C gar nichts.
also sollte ich dann wohl in appProxyType einen datensatz 'news' anlegen.
in appProxy würde ich dann also wohl die datensätze readNews mit readPermission auf 1 und editNews mit editPermission und readPermission auf 1. und dann müsste ich für beides ne relation zu News und zu den Nutzern A (readNews) und B (editNews) herstellen. user C würde dadurch gar keine rechte haben.
richtig soweit?
ich glaub ja fast ja. wenn ich das so aufschreibe klingt es für mich inzwischen auch logisch. meine verwirrung hat schon jetzt leicht abgenommen :lol: (wenn ich falsch liege bin ich aber umso mehr verwirrt)

und in der umsetzung sieht das dann so aus, dass ich einfach bei jedem template abfrage, ob der user die richtige permission hat. geht das dann einfach über die taglibs umgt:importdesign und umgt:template?
oder sollte die abfrage im documentcontroller sein? wenn ja muss mein controller dann vom UmgtBaseController erben oder einfach vom basedocumentcontroller? oder ein ganz anderer/speziellerer?

und nun die master-frage: wo kommt nun die andere permission ins spiel, die nicht in der appProxy-tabelle ist? funktioniert doch auch ohne. und rollen scheine ich auch keine zu brauchen und die sind ja auch nichtmal mit dem appProxy-object verbunden.
das mit der application hab ich auch noch nicht ganz durchblickt. das umgt hat automatisch die ID 1 dort. und weiter? wo kann ich die dann wirklich nutzen?

ich versuche mal ein bischen zu erzählen, was ich in meinem projekt u.a. machen möchte, weil ich nicht so recht weiß, ob ich den umgt so wie er ist dabei nutzen kann oder evtl erweitern muss.
die seite wird zum teil teile haben die für jeden nutzer gleich aussehen (wenn er sie sehen darf) und zum teil wird es seiten geben, die abhängig vom nutzer sind. letzteres ist z.b. ne ToDo-liste.
die kann jeder nutzer anlegen, bearbeiten usw. Er kann sie aber auch mich anderen Teilen und dabei festlegen ob sie bearbeitet oder nur gesehen werden darf.
wäre diese ToDo-Liste dann auch ein AppProxyType? wenn ja müsste ich bei der zuweisung vom user zum Objekt ja noch ne unterscheidung machen zwischen Besitzer und Beobachter/einfacher nutzer, oder? ich mach dann neue relations-tabelle von user zu appProxyType die ich aber besitzer2appProxyType nenne?
oder was ich grad gesehen habe und mir vorher nicht aufgefallen ist: es gibt auch ne linkPermission. da nur der besitzer einer liste sie auch teilen darf (das verstehe ich mal unter link) kann der besitzer ja diese linkPermission haben.
aber am ehesten denke ich ist die lösung aber, dass ich ein neues feld bei appProxyType anlege für den besitzer des objekts. denn ansonsten weiß ich ja gar nicht wessen liste ein user sehen darf. ich könnte natürlich auch das feld weg lassen und dann die objekte immer "todoListeUserA" usw nennen. aber die möglichkeit gefällt mir glaube ich weniger weil dann zwei informationen in einem feld sind.

oder bin ich sowieso ganz auf dem falschen dampfer?

irgendwie fehlen mir einfach konkrete anwendungsbeispiele für das umgt. und die doku hilft auch nicht so wirklich.
mir kam die letzten tage dazu oft die idee dass es wirklich hilfreich wäre, wenn in der sandbox das umgt so richtig zum einsatz kommt. im moment ist es ja so, dass man nach installation des umgt da zwar nutzer ect hinzufügen kann, aber gar keine auswirkungen sieht. die einzige auswirkung hat man wenn man mal ne gruppe administratoren anlegt. dann sieht man den admin-link, wenn man sich als solcher einloggt. hat aber auch ohne eingeloggt zu sein schon zugriff auf den admin-bereich.
wie wäre es mit einer erweiterten sandbox? die sollte mit nem sql-dump ausgeliefert werden, wodurch dann in der datenbank ne liste an beispielnutzern/gruppen/rollen usw angelegt wird. der nutzer kann sich dann als die verschiedenen nutzer anmelden (alle haben dass sehr sichere passwort 'passwort') und sehen wie sich die sandbox verändert. z.b. könnte ein user den news-bereich nicht sehen, ein anderer könnte news anlegen.
interessant wären vielleicht auch die abbildung von rechten innerhalb einer gruppe, falls das möglich ist. damit meine ich, dass quasi ein administrator pro gruppe sein könnte, der user zu der gruppe hinzufügen oder entfernen kann aber auf andere gruppen keinen zugriff hat.

und jetzt bin ich mal gespannt ober jemand es schafft meinem verständnis weiterzuhelfen.

lg
dingsda
Zuletzt geändert von dingsda am 19.02.2014, 21:47:18, insgesamt 1-mal geändert.

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 19.02.2014, 00:43:22

viewtopic.php?f=7&t=578&p=5333&hilit=in ... uppe#p5333
hier wurde gesagt:
dr.e. hat geschrieben:
ma2604121 hat geschrieben:Weiterhin sollen Benutzer zu Gruppen zusammengefasst werden können. In dieser Gruppe soll es dann eine Art "Administrator" geben, welcher wiederum die Gruppe administriert (Benutzer in Gruppe aufnehmen bzw. ausschließen). Innerhalb einer Gruppe sollen die Daten der Gruppenmitglieder zusammengefasst und ebenfalls auswertbar sein. [..]
Auch hier hilft dir das usermanagement-Modul.
soetwas brauche ich auch und weiß immer noch nicht, wie ich das nun umsetzten kann.
ich denke ich müsste dann bei den rollen immer genauer die rolle definieren als nur "administrator". dann gäbe es wohl "administrator-gruppeA", "administrator-gruppeB", "mitglied-GruppeA", "mitglied-GruppeB" usw
oder übersehe ich da was?

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 19.02.2014, 18:01:02

dingsda hat geschrieben: wäre diese ToDo-Liste dann auch ein AppProxyType? wenn ja müsste ich bei der zuweisung vom user zum Objekt ja noch ne unterscheidung machen zwischen Besitzer und Beobachter/einfacher nutzer, oder? ich mach dann neue relations-tabelle von user zu appProxyType die ich aber besitzer2appProxyType nenne?
ich hab grad erst gesehen, dass es ja keine verbindung von user/gruppe direkt zum appProxyType gibt sondern nur von user/gruppe zu appProxy. ist auch irgendwie logisch, dass es erst über die sichtbarkeitsberechtigungen geht und dann zum objekt weiter.
dingsda hat geschrieben: aber am ehesten denke ich ist die lösung aber, dass ich ein neues feld bei appProxyType anlege für den besitzer des objekts. denn ansonsten weiß ich ja gar nicht wessen liste ein user sehen darf. ich könnte natürlich auch das feld weg lassen und dann die objekte immer "todoListeUserA" usw nennen. aber die möglichkeit gefällt mir glaube ich weniger weil dann zwei informationen in einem feld sind.
es müsste ja eigentlich schon reichen, wenn ich den Index von AppObjectName von Unique auf Index ändere. über den PK ist es ja dann schon eindeutig. dann kann ich mehrmals z.b. TodoListe drinstehen haben, aber jedes Objekt ist mit anderen Datensätzen der Tabelle TodoListe assoziiert.
genauso beim AppProxy. dort steht mehrmals readToDoListe, aber jede sichtbarkeitsdefinition bezieht sich auf ein anderes AppProxyType.
glaub das dürfte so klappen :)

edit: wenn der user dann z.b. eine Todoliste erstellt, wird also in der tabelle AppProxy die datensätze seheToDoListe, ÄndereTodoListe, TeileTodoListe erstellt und mit dem User verknüppft und mit nem neu erstellten Datensatz ToDoListe in AppProxy. möchte der user dann, dass auch userB die liste sehen kann, dann wird der datensatz seheToDoListe, der auch mit dem User verknüpft ist noch mit userB verknüpft. userB kann dann die liste selbt nicht mit anderen teilen, weil er ja nicht die sichtbarkeitsberechtigung teileTodoListe für diese liste hat.

ähnlich wäre es ja dann auch mit den rollen. da kann auch mehrmal die rolle GroupAdmin drin sein. aber einmal ist die rolle dann mit GruppeA assoziiert und einmal mit GruppeB usw.
eine assoziation von einer gruppe zu einer rolle brauche ich nicht, daher gibts da keine verwirrung wie rum das nun ist.

langsam lichtet sich der nebel :mrgreen:

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 19.02.2014, 21:43:59

ich hab das mit dem appProxyType und AppProxy wohl doch falsch verstanden.
jwlighting hat geschrieben: AppProxyType / Objekttyp: Art eines Objektes, z.B. News-Artikel, Produkt, ...
AppProxy / Objekt: konkretes Objekt:, z.B. News mit ID #42 oder Produkt mit ID #21
was jwlighting hier geschrieben hat klingt auch logischer als meins.

dann sähe es wohl in meinem beispiel mit der todo-liste so aus, das in der tabelle AppProxyType die spalte AppObjectName auch als unique bleiben kann und ToDoListe nur einmal auftaucht. in AppProxy wird dann die ID der ToDoListe des Users eingetragen mit den entsprechenden berechtigungen. ergibt auch sinn.
dann hätte ich wohl eine tabelle TodoListe, wo die Listen aller User eingetragen sinn. und der Primary-Key aus dieser Liste entspricht dann dem AppObjectId aus der AppProxy-tabelle?

edit:
mh... jetzt frage ich mich doch wie man das wieder auf das beispiel news aus meinem ersten post übertragen kann. das was jwlighting darunter versteht fänd ich etwas komisch.
AppProxy / Objekt: konkretes Objekt:, z.B. News mit ID #42
und für jede neue news gibt es nen neuen eintrag in der tabelle für den dann erstmal die berechtigungen wieder an die richtigen user verteilt werden? wär etwas komisch.
besser könnte ich es mir so vorstellen, wenn es z.b. mehrere arten von news gäbe. dann steht in der tabelle AppProxyType News drin. es gibt dann noch ne tabelle News die enthält die datensätze wetternews, politiknews, wirtschaftsnews usw.
soll dann einem user bearbeitender zugriff für die wetternews gegeben werden, dann wird in appProxy der primary-key des datesatzes von wetternews geschrieben mit der editPermission auf 1.

das erklärt dann vielleicht auch die tabelle permissions. wurde ein user der permission editNews assoziiert hat aber keine visibilityPermission für wetternews kann er logischer weise alle news außer den wetternews bearbeiten

edit 2:
wobei man das wohl aber auch wieder ohne die permissions erreichen kann. glaub die news sind da grad ein schlechtes beispiel. christian hatte hier irgendwo ein anderes beispiel gebracht mit fillialleitern und so. werd das mal raussuchen und nochmal genau studieren

edit 3:
ich hab grad überlegt, ob die visibility-permission-kombi bei der hierarchie innerhalb von gruppen helfen kann.
ein user hat die rolle admin und darüber die permission removeUserFromGroup, hat aber nur für gruppe A eine visibility-definition für write. dann kann er nur in gruppe A user entfernen und in gruppe B, C und D wo er nur eine visibility-definition für read hat kann er das nicht.
in dem fall wären die gruppen selbst nochmal proxy-objekte vom typ group
dadurch vermeide ich zumindest, dass ich bei den rollen adminGruppeA, adminGruppeB habe usw...
allerdings funktioniert das nicht immer.
beispiel:
es gibt die rollen juniorAdmin und seniorAdmin. juniorAdmin darf benutzer sperren. seniorAdmin darf benutzer sperren und entfernen. in beiden fällen bräuchte man die visibility-definition write für eine gruppe um seine funktion in dieser gruppe auszuführen. wenn allerding ein user seniorAdmin in GruppeA ist und JuniorAdmin in gruppeB sein soll könnte man das nicht über die visibility eindeutig unterscheiden zu was es gehört.
die berechtigungen so abzubilden geht also nur unter bestimmten bedingungen.

edit 4:
hab ja ganz übersehen, dass es noch deletePermission gibt. dann könnte man das vielleicht doch in diesem fall über die visibility-Definitionen lösen indem der user für die eine gruppe deletePermission bekommt und für die andere WritePermission. allerdings wär das schon etwas komisch... die permission sollte sich ja eigentlich auf das Objekt beziehen. also wenn die gruppe ein proxy-objekt ist dann sollte ich mit der deletePermission die gruppe löschen können. zumindest würde ich mir das darunter vorstellen. oder man betrachtet sie als sammelobjekt für die darin enthaltenen user.
bei den wetternews ist das ja eigentlich auch nur ein sammelobjekt für die darin enthaltenen richtigen wetterdaten. und meine todoliste ist auch nur eine sammlung für die einzellnen punkte die abgearbeitet werden sollen.

langsam wirds doch wieder verwirrend :lol:

edit 5:
auch wenn das hier langsam wie ein selbstgespräch aussieht. wer sich beteiligen möchte kann das jederzeit gerne machen :D

Benutzeravatar
dr.e.
Administrator
Beiträge: 4536
Registriert: 04.11.2007, 16:13:53

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dr.e. » 20.02.2014, 15:27:30

Sorry, war die letzten beiden Tage unterwegs. Schaue mir den Thread heute an.
Viele Grüße,
Christian

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 20.02.2014, 16:01:10

kein problem. lass dir zeit.
es hat mir schon geholfen überhaupt darüber zuschreiben. verstehe dinge meist erst dann, wenn ich meine gedanken dazu ausformuliere. daher soviele posts und edits

Benutzeravatar
dr.e.
Administrator
Beiträge: 4536
Registriert: 04.11.2007, 16:13:53

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dr.e. » 21.02.2014, 11:12:49

Hallo dingsda,

entschuldige bitte, dass ich so spät antworte. Ich habe mir unterwegs auf dem Handy echt schwer getan, den kompletten Beitrag zu überblicken.

Ich versuche mal chronologisch zu deinen Punkten zu antworten:
EXAMPLE_umgt_objects.ini
Die Doku hierzu ist in der Tat falsch. Zu den Sichtbarkeitsberechtigungen gilt zunächst http://adventure-php-framework.org/Seit ... chtigungen und http://adventure-php-framework.org/Seit ... chtigungen.

Magst du im Tracker dazu einen bug eröffnen? Danke!
und dann ist es noch verwirrend, dass die domainobjects nicht appProxy und AppProxyType heißen sondern VisibilityDefinition und VisibilityDefinitionType.
Software-Design-technisch verhalten sich die beiden Objekt-Typen wie Stellvertreter (Proxy) zu Objekten deiner Applikation. Insofern wurde für die Schema-Definition "AppProxy" (steht für Application Proxy Object) gewählt. Ich gene zu, die andere Benennung der Domänen-Objekte ist dann sicher nicht ganz einfach nachzuvollziehen.
angenommen ich hab nun ne seite mit usern. und diese seite hat nen newsbereich. nun soll der newsbereich nicht von jeden editierbar sein. und für mache auch nicht sicht bar.
also z.b. user A darf nur sehen, user B editieren und user C gar nichts.
Das Konzept des UMGT sieht eine Trennung zwischen Sichtbarkeits- und Funktions-Berechtigung vor. Soll ein Benutzer einen Eintrag zwar sehen, aber nicht bearbeiten können, so hat er - entweder direkt oder über eine Gruppe - einen Eintrag in den Sichtbarkeitsberechtigungen (lesen), jedoch keinen Eintrag in den Berechtigungen (z.B. ändere News). Sichtbarkeits- und Funktions-Berechtigung lassen sich getrennt voneinander jedoch auch so nutzen, dass du deinen Anwendungsfall nur mit Sichtbarkeits- oder nur mit Funktions-Berechtigungen umsetzt. Hier hatten wir in einer der Threads eine ausführliche Diskussion, da sich die beiden Bereiche teilweise - oder für manche Anwendungsfälle größtenteils - überschneiden.
also sollte ich dann wohl in appProxyType einen datensatz 'news' anlegen.
in appProxy würde ich dann also wohl die datensätze readNews mit readPermission auf 1 und editNews mit editPermission und readPermission auf 1. und dann müsste ich für beides ne relation zu News und zu den Nutzern A (readNews) und B (editNews) herstellen. user C würde dadurch gar keine rechte haben.
richtig soweit?
Das kannst du genau so machen. Was du beschreibst ist die Anwendung der Sichtbarkeits-Berechtigungen für die Regelung des Zugriffs (sehen) und der möglichen Operationen (ändern) auf ein Objekt.

Hast du in deiner Applikation einen News-Eintrag mit der ID 1, so legst du ein oder mehrere Datensätze für den Proxy im UMGT an und weist diesen eine Gruppe oder eine oder mehrere Benutzer zu und gibst dem Proxy die entsprechenden Berechtigungen.
und in der umsetzung sieht das dann so aus, dass ich einfach bei jedem template abfrage, ob der user die richtige permission hat. geht das dann einfach über die taglibs umgt:importdesign und umgt:template?
oder sollte die abfrage im documentcontroller sein? wenn ja muss mein controller dann vom UmgtBaseController erben oder einfach vom basedocumentcontroller? oder ein ganz anderer/speziellerer?
Du kannst alle genannten Optionen nutzen. Manchmal ist die eine Option besser, manchmal die andere. Mit dem UMGT werden ein paar Standard-Tags mitgeliefert, die das für dich erledigen (<umgt:* />-Tags). Sollten diese nicht ausreichen, kannst du das auch oder zusätzlich im Controller abfragen.
und nun die master-frage: wo kommt nun die andere permission ins spiel, die nicht in der appProxy-tabelle ist? funktioniert doch auch ohne. und rollen scheine ich auch keine zu brauchen und die sind ja auch nichtmal mit dem appProxy-object verbunden.
das mit der application hab ich auch noch nicht ganz durchblickt. das umgt hat automatisch die ID 1 dort. und weiter? wo kann ich die dann wirklich nutzen?
Die "andere" Permission - Rollen und Funktions-Berechtigungen - kommen dann ins Spiel, wenn dir z.B. ein einfaches writePermission=1 nicht mehr ausreicht und du definieren möchtest, was genau der Benutzer am Objekt verändern darf. Es könnte beispielsweise sein, dass ein Benutzer in einem News-Eintrag lediglich den Text, nicht aber den Titel ändern darf. In diesem Fall kannst du einen Proxy mit writePermission=1 anlegen und dem benutzer zuordnen und gleichzeitig noch eine Permission anlegen, die sagt ob der Benutzer den Titel bei News ändern darf. In deinem Fall sehe ich das jedoch erstmal noch nicht als notwendig an.
wäre diese ToDo-Liste dann auch ein AppProxyType? wenn ja müsste ich bei der zuweisung vom user zum Objekt ja noch ne unterscheidung machen zwischen Besitzer und Beobachter/einfacher nutzer, oder? ich mach dann neue relations-tabelle von user zu appProxyType die ich aber besitzer2appProxyType nenne?
Für mich klingt das klassisch nach Sichtbarkeitsberechtigungen. Das beobachten von Themen würde ich mit einer eigenen Beziehung zwischen User und Themen realisieren. Damit lässt sich das sehr einfach abfragen. Die Beziehung könnte beispielsweise "UserWhatchesTopic" heißen und von User zu Topic zeigen.
oder was ich grad gesehen habe und mir vorher nicht aufgefallen ist: es gibt auch ne linkPermission. da nur der besitzer einer liste sie auch teilen darf (das verstehe ich mal unter link) kann der besitzer ja diese linkPermission haben.
Die linkPermission ist eher auf Daten-Satz-Ebene zu sehen und definiert ob ein Benutzer eine Beziehung von einem Objekt zum anderen herstellen darf.
aber am ehesten denke ich ist die lösung aber, dass ich ein neues feld bei appProxyType anlege für den besitzer des objekts. denn ansonsten weiß ich ja gar nicht wessen liste ein user sehen darf. ich könnte natürlich auch das feld weg lassen und dann die objekte immer "todoListeUserA" usw nennen. aber die möglichkeit gefällt mir glaube ich weniger weil dann zwei informationen in einem feld sind.
Zur Definition eines Besitzers eines Objekts bietet sich die Verwendung einer Beziehungen an. Den AppProxy zu erweitern ist auch eine Lösung, allerdings nicht so wartungsfreundlich und performant wie eine Beziehung.
wie wäre es mit einer erweiterten sandbox? die sollte mit nem sql-dump ausgeliefert werden, wodurch dann in der datenbank ne liste an beispielnutzern/gruppen/rollen usw angelegt wird. der nutzer kann sich dann als die verschiedenen nutzer anmelden (alle haben dass sehr sichere passwort 'passwort') und sehen wie sich die sandbox verändert. z.b. könnte ein user den news-bereich nicht sehen, ein anderer könnte news anlegen.
Klar doch! Magst du mal einen Eintrag im Tracker anlegen?
interessant wären vielleicht auch die abbildung von rechten innerhalb einer gruppe, falls das möglich ist. damit meine ich, dass quasi ein administrator pro gruppe sein könnte, der user zu der gruppe hinzufügen oder entfernen kann aber auf andere gruppen keinen zugriff hat.
Das wäre dann eine Erweiterung des UMGT-Admin-Backends in Richtung "data-driven security". Sofern wir das nicht unbedingt brauchen, würde ich gerne davon Abstand nehmen, da unglaublich komplex umzusetzen, wenn es eine generische Lösung sein soll.

Soviel zum ersten Post! :)
Viele Grüße,
Christian

Benutzeravatar
dr.e.
Administrator
Beiträge: 4536
Registriert: 04.11.2007, 16:13:53

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dr.e. » 21.02.2014, 11:34:12

Hallo dingsda,

hier meine Antworten zu deinen weiteren Fragen:
ich hab grad erst gesehen, dass es ja keine verbindung von user/gruppe direkt zum appProxyType gibt sondern nur von user/gruppe zu appProxy. ist auch irgendwie logisch, dass es erst über die sichtbarkeitsberechtigungen geht und dann zum objekt weiter.
Korrekt. Der Typ dient "nur" zur einfacheren Abfrage von Objekten für die der Benutzer eine Berechtigung besitzt. Die "eigentliche" Berechtigng wird auf dem Proxy vergeben.
es müsste ja eigentlich schon reichen, wenn ich den Index von AppObjectName von Unique auf Index ändere. über den PK ist es ja dann schon eindeutig. dann kann ich mehrmals z.b. TodoListe drinstehen haben, aber jedes Objekt ist mit anderen Datensätzen der Tabelle TodoListe assoziiert.
genauso beim AppProxy. dort steht mehrmals readToDoListe, aber jede sichtbarkeitsdefinition bezieht sich auf ein anderes AppProxyType.
glaub das dürfte so klappen :)
AppObjectName sollte im Type heute schon auf Unique in der GUI geprüft werden. Im Datenbank-Setup bin ich mir nicht sicher. Im Prinzip ist der Typ jedoch eineindeutig, in der Proxy-Tabelle stehen dann mehrere Einträge für einen Typ.
edit: wenn der user dann z.b. eine Todoliste erstellt, wird also in der tabelle AppProxy die datensätze seheToDoListe, ÄndereTodoListe, TeileTodoListe erstellt und mit dem User verknüppft und mit nem neu erstellten Datensatz ToDoListe in AppProxy. möchte der user dann, dass auch userB die liste sehen kann, dann wird der datensatz seheToDoListe, der auch mit dem User verknüpft ist noch mit userB verknüpft. userB kann dann die liste selbt nicht mit anderen teilen, weil er ja nicht die sichtbarkeitsberechtigung teileTodoListe für diese liste hat.
Korrekt. Empfehlung ist hier über gruppen zu arbeiten, dann musst du nicht jedesmal den Benutzer direkt zuweisen. Das zahlt sich insbesondere bei der Anlage von neuen Benutzern aus.
ähnlich wäre es ja dann auch mit den rollen. da kann auch mehrmal die rolle GroupAdmin drin sein. aber einmal ist die rolle dann mit GruppeA assoziiert und einmal mit GruppeB usw.
eine assoziation von einer gruppe zu einer rolle brauche ich nicht, daher gibts da keine verwirrung wie rum das nun ist.
Rollen kannst du auch einer Gruppe zuweisen. Auch hier ist der Grund die einfachere Verwaltung. Du kannst das natürlich auch auf Basis von Benutzern implementieren - beides ist korrekt und sinnvoll.

Hoffe das hilft dir schon mal weiter.

Welche Fragen sind aus deiner Sicht aus deinem dritten Post noch offen? Vielleicht gehen wir diese nun konkret an, dann lichtet sich die Verwirrung sicher bald. :)
Viele Grüße,
Christian

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 24.02.2014, 14:32:17

Hallo,
danke für deine Antwort.
entschuldige bitte, dass ich so spät antworte. Ich habe mir unterwegs auf dem Handy echt schwer getan, den kompletten Beitrag zu überblicken.
das kann ich gut verstehen. ich hatte noch überlegt alles zu löschen um einen neuen beitrag zu erstellen, der wirklich kurz das beschreibt, wo ich noch probleme habe. aber dann kam ich nicht mehr dazu.

deshalb wurde ich glaube ich auch an mancher stelle etwas missverstanden.
ähnlich wäre es ja dann auch mit den rollen. da kann auch mehrmal die rolle GroupAdmin drin sein. aber einmal ist die rolle dann mit GruppeA assoziiert und einmal mit GruppeB usw.
eine assoziation von einer gruppe zu einer rolle brauche ich nicht, daher gibts da keine verwirrung wie rum das nun ist.
Rollen kannst du auch einer Gruppe zuweisen. Auch hier ist der Grund die einfachere Verwaltung. Du kannst das natürlich auch auf Basis von Benutzern implementieren - beides ist korrekt und sinnvoll.
Mir ging es hier eigentlich darum, den wirkungsbereich einer Rolle zu beschränken. also der GroupAdmin von Gruppe A kann natürlich nur administrative aufgaben ausführen, die die gruppe A betreffen, z.b. neue mitglieder hinzufügen usw. Er hat dann natürlich keine berechtigungen für Gruppe B.
also so wie ich es auch hier beschrieben habe:
interessant wären vielleicht auch die abbildung von rechten innerhalb einer gruppe, falls das möglich ist. damit meine ich, dass quasi ein administrator pro gruppe sein könnte, der user zu der gruppe hinzufügen oder entfernen kann aber auf andere gruppen keinen zugriff hat.
Das wäre dann eine Erweiterung des UMGT-Admin-Backends in Richtung "data-driven security". Sofern wir das nicht unbedingt brauchen, würde ich gerne davon Abstand nehmen, da unglaublich komplex umzusetzen, wenn es eine generische Lösung sein soll.
mit "UMGT-Admin-Backends" meinst du das graphische interface für das umgt, oder?
wenn das was ich mir vorstelle vom umgt nicht voll unterstützt wird ist das natürlich kein grund am apf etwas zu ändern.
Für mich klingt das klassisch nach Sichtbarkeitsberechtigungen. Das beobachten von Themen würde ich mit einer eigenen Beziehung zwischen User und Themen realisieren. Damit lässt sich das sehr einfach abfragen. Die Beziehung könnte beispielsweise "UserWhatchesTopic" heißen und von User zu Topic zeigen.
Widersprichst du dir hier nicht irgendwie? oder meinst du mit "beziehung" das hinzufügen des topics zu appProxy-tabelle und als appProxyType dann "UserWhatchesTopic"?
allerdings hatte ich das wort "beobachter" auch nur als abgrenzung zum besitzer gemeint. es geht hier nicht darum, dass ein User A aktiv entscheidet ob er ein thema von User B beobachten möchte. sondern er ist "beobachter" eines themas von User B weil user B entschieden hat ihm zugriff zu gewähren. "beobachter" ist hier wohl aber sehr missverständlich. mir fällt aber gar keine wort dafür ein.
Zur Definition eines Besitzers eines Objekts bietet sich die Verwendung einer Beziehungen an. Den AppProxy zu erweitern ist auch eine Lösung, allerdings nicht so wartungsfreundlich und performant wie eine Beziehung.
einfach ne beziehung zu verwenden hab ich auch schon überlegt. aber ich dachte eigentlich, dass genau dafür dass AppProxy da ist, damit man nicht die beziehung von user/gruppe direkt zu einem objekt hat sondern über den stellvertreter geht.
oder was ich grad gesehen habe und mir vorher nicht aufgefallen ist: es gibt auch ne linkPermission. da nur der besitzer einer liste sie auch teilen darf (das verstehe ich mal unter link) kann der besitzer ja diese linkPermission haben.
Die linkPermission ist eher auf Daten-Satz-Ebene zu sehen und definiert ob ein Benutzer eine Beziehung von einem Objekt zum anderen herstellen darf.
ist es nicht genau das was man bei teilen machen würde? wenn ein besitzer einer todoliste entscheidet, dass ein anderer user sie auch sehen können soll, das wird eine beziehung vom appProxy mit der ID seiner todo-liste zu dem anderen user erstellt. oder wie darf man die linkPermission sonst verstehen?
Welche Fragen sind aus deiner Sicht aus deinem dritten Post noch offen? Vielleicht gehen wir diese nun konkret an, dann lichtet sich die Verwirrung sicher bald. :)
es wär jetzt glaube ich schwer direkt auf meinen letzten beitrag einzugehen, weil ich auch da wieder dinge geschrieben hab die ich schon wieder ganz anders sehe.
ich werde aber nochmal später darauf zurückkommen, wenn ich irgendwo schwierigkeiten in meinem konzept sehe, wenn ich denn mal mein konzept zuende gedacht hab.

lg
dingsda

Benutzeravatar
dr.e.
Administrator
Beiträge: 4536
Registriert: 04.11.2007, 16:13:53

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dr.e. » 25.02.2014, 00:11:41

Hallo dingsda,
Mir ging es hier eigentlich darum, den wirkungsbereich einer Rolle zu beschränken. also der GroupAdmin von Gruppe A kann natürlich nur administrative aufgaben ausführen, die die gruppe A betreffen, z.b. neue mitglieder hinzufügen usw. Er hat dann natürlich keine berechtigungen für Gruppe B.
OK, verstanden. Das ist dann vermutlich jedoch eher Aufgabe der Applikation das zu regeln denn Teil der UMGT-Funktion. Ich persönlich habe noch keinen Anwendungsfall dafür gehabt. Ein klassischer Anwendungsfall - den ich kenne und oft schon eingesetzt habe - sind personaisierte Admin-Rollen. Das lässt sich jedoch recht einfach durch zuweisen einer entsprechenden Rolle mit entsprechenden Permissions realisieren.
mit "UMGT-Admin-Backends" meinst du das graphische interface für das umgt, oder?
Korrekt.
wenn das was ich mir vorstelle vom umgt nicht voll unterstützt wird ist das natürlich kein grund am apf etwas zu ändern.
Da stimme ich dir nicht ganz zu. Sinnvolle Feature-Erweiterungen werden immer gerne genommen. :) Das Thema ist allerdings nicht ganz so einfach. :D
Widersprichst du dir hier nicht irgendwie? oder meinst du mit "beziehung" das hinzufügen des topics zu appProxy-tabelle und als appProxyType dann "UserWhatchesTopic"?
Sichtbarkeitsberechtigungen definieren die Berechtigung LinkPermission, die - sofern für einen Benutzer oder eine Gruppe definiert - berechtigen sollen eine Beziehung zum entsprechenden Objekt anlegen zu dürfen. Mit Beziehung ist hier die Beziehung zwischen einem Objekten deiner Anwendung gemeint - also beispielsweise einem Thema und einem Beobachter. Es geht weniger um das Anlegen von technisch notwendigen Einträgen im UMGT.
allerdings hatte ich das wort "beobachter" auch nur als abgrenzung zum besitzer gemeint. es geht hier nicht darum, dass ein User A aktiv entscheidet ob er ein thema von User B beobachten möchte. sondern er ist "beobachter" eines themas von User B weil user B entschieden hat ihm zugriff zu gewähren. "beobachter" ist hier wohl aber sehr missverständlich. mir fällt aber gar keine wort dafür ein.
OK, jetzt wird es klarer. In diesem Fall ist hat B "einfach nur" Zugriffsrechte. Dies kannst du mit Sichtbarkeitsberechtigungen ohne weiteres abbilden.
einfach ne beziehung zu verwenden hab ich auch schon überlegt. aber ich dachte eigentlich, dass genau dafür dass AppProxy da ist, damit man nicht die beziehung von user/gruppe direkt zu einem objekt hat sondern über den stellvertreter geht.
Das Konzept des AppProxy hilft dir Berechtigungen der Objekte deiner Anwendung zu definieren. Um deine Anwendung mit dem UMGT zu verbinden und letzteres nicht jedes Mal anpassen zu müssen nutzt du Stellvertreter im UMGT und in deiner Anwendung arbeitest du auf den Objekten direkt. Das ersetzt also nicht die Datenmodellierung deiner Anwendung - in diesem Fall die Klassifizierung von Inhalten über diverse Beziehungen.
ist es nicht genau das was man bei teilen machen würde? wenn ein besitzer einer todoliste entscheidet, dass ein anderer user sie auch sehen können soll, das wird eine beziehung vom appProxy mit der ID seiner todo-liste zu dem anderen user erstellt. oder wie darf man die linkPermission sonst verstehen?
Wie zuvor bereits angesprochen ist ein AppProxy kein Teil deiner Anwendung und ersetzt nicht eine Beziehung zur Klassifizierung von Inhalten derselben. Die LinkPermission soll lediglich ermöglichen zu steuern, ob du als Benutzer eine TODO-Liste (in diesem Fall also ein AppProxy auf eine TODO-Liste) diese teilen/beobachten/wasauchimmer darfst. Technisch gesprochen bedeutet das: darfst du als angemelder Benutzer Beziehungen im Daten-Modell deiner Anwendung zu diesem Objekt anlegen. Konkret kannst du das für alles mögliche verwenden.

Hoffe das hilft dir wieder ein Stück weiter! :)

Vorschlag: magst du mal dein Datenmodell posten, dann können wir vielleicht konkret an den für dich schwierigen Stellen nach einer Lösung suchen. An abstrakten Beispielen können wir natürlich einiges besprechen, ich denke es hilft dir jedoch mehr, wenn wir auf akute Problemstellungen eingehen.
Viele Grüße,
Christian

dingsda
Beiträge: 49
Registriert: 03.02.2014, 04:00:36

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dingsda » 25.02.2014, 11:41:21

denke schon, dass es mir bischen geholfen hat. muss über alles mal genauer nachdenken.
dr.e. hat geschrieben:Vorschlag: magst du mal dein Datenmodell posten, dann können wir vielleicht konkret an den für dich schwierigen Stellen nach einer Lösung suchen. An abstrakten Beispielen können wir natürlich einiges besprechen, ich denke es hilft dir jedoch mehr, wenn wir auf akute Problemstellungen eingehen.
das werd ich demnächst machen. allerdings bin ich jetzt erstmal paar tage verreist.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4536
Registriert: 04.11.2007, 16:13:53

Re: UMGT - weiß nicht ob ich alles verstanden hab

Beitrag von dr.e. » 25.02.2014, 19:39:52

Dann viel Spass! :)
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast