Berechtigungen auf Projekte

Hallo Synesty-Team,

wäre es denkbar, dass man Berechtigungen auf Projektebene vergeben kann ?
Quasi Analog zu den Workspaces - nur halt für Projekte ?

Das würde uns die Absicherung kritischer Flows vereinfachen.

Über eine Einschätzung wäre ich dankbar.

LG

Hallo @eRocket-Michael_Schilling,

hört sich auf Anhieb erstmal gar nicht so schlecht an. Aber wie genau stellst du dir das vor oder was ist der aktuelle Usecase? Nicht, dass wir intern etwas entwickeln, was gar nicht dein Problem löst.

Um unsere erste Vorstellung zu erläutern. Du möchtest einzelne Projekte in einem Workspace einzelnen Benutzern zu weisen, sodass sie die beinhalteten Flow bearbeiten können?
Dazu dann wahrscheinlich auch die entsprechenden Berechtigung wie: lesen, bearbeiten, löschen.

Viele Grüße
Lukas

Hallo @synesty-Lukas ,

genau. Aktuell werden für die Berechtigungen ja Rollen erstellt und dann einzelnen Benutzern in den Workspaces entsprechend die Rollen zugewiesen. Unsere Vorstellung war, diese Rollenzuweisung auch auf Projektebene anzuwenden wenn möglich. Mit der aktuellen Lösung müssen wir entsprechend abzugrenzende Flows in eigenen Workspaces erstellen und verwalten. Da sich diese aber auch Ressourcen (Verbindungen, Datastores, Mappingsets) teilen können muss das immer doppelt gepflegt werden.

VG,
Florian

Hallo @synesty-Lukas,

kannst du eine Aussage treffen ob das etwas ist das ihr ermöglichen möchtet und ggf. eine grobe Einschätzung in welchem Zeitrahmen das umsetzbar wäre?

VG,
Florian

Hallo @eRocket-Florian_Menzel,

welche Nutzer würde das denn betreffen, die als einziges den Zugriff auf kritische Flows brauchen? Reden wir hier von Owner/Co-Owner?

Versprechen können wir aktuell leider noch nichts.

Viele Grüße
Lukas

Es geht erstmal weniger um einzelne Kollegen, als darum Mitarbeitern aus verschiedenen Teams entsprechende Befugnisse geben zu können bzw. neue oder temporäre Kollegen abzusichern.

VG,
Florian

Sorry, der Satz verwirrt uns leider irgendwie :wink:

Wir müssten mal euren Fall tabellarisch spezifizieren.
Hier mal ein Versuch / Anfang:

User

  • A
  • B
  • C (SollGanzWenigDürfen)

Rollen

  • R1 (darf alles)
  • R2 (nur lesen)

Workspaces

  • W1
  • W2

Zuweisung:

  • W1

    • A (R1 darf alles)
    • B (R1 darf alles)
    • C (R2 nur lesen)
  • W2

    • A (R1 darf alles)
    • C (R2 nur lesen)

Augenmerk auf User C SollGanzWenigDürfen

IST-Zustand:

  • C ist in beiden Workspaces W1 und W2 drin
  • und darf dort aktuell nur Lesen (R2)
  • ABER: R2 (nur Lesen) ist für ein paar Projekte in W1 zu streng.

Ziel:

  • d.h. in W1-Projekt1 soll er auch noch „Flow Ausführen“ dürfen (aber in allen anderen Projekten in W1 weiterhin nur Lesen).

Frage:
Spiegelt das Ziel eure Anforderung wieder?

@synesty-Lukas im Prinzip korrekt ja.

Ergänzend vielleicht noch folgendes Szenario:

Workspace W1:

Projekt P1

  • User A (darf alles)
  • User B (darf alles)
  • User C (nur lesen)

Projekt P2

  • User A (darf alles)
  • User B (nur lesen)
  • User C (nur lesen)

Ok danke für die Ergänzung.

Eine kleine Anmerkung:
Ein User kann auf Projekt-Ebene aber nur überhaupt ausgewählt werden, wenn er bereits auf höherer Workspace-Ebene zugewiesen ist.
Wird er z.B. auf Workspace Ebene entfernt, wird er auch automatisch auf Projekt-Ebene entfernt.

Einwände?

So ist es am sinnvollsten, ja !

Wir nehmen das mal mit auf die Wunschliste und erstellen als ersten Schritt intern ein Ticket.

Leider können wir im Moment nicht abschätzen wann wir das weiter angehen können. Das Thema ist im Core angesiedelt und viele Abhängigkeiten.

Aber eine weitere Frage die wir uns in den ersten Gesprächen gestellt haben ist:

Was wäre praktikabler:

a) an einem Projekt zu sagen:

  • User B darf (Projekt lesen, Flows lesen)

oder

b) an einem Projekt zu sagen:

  • User B hat Rolle „nur Lesen“, die die Berechtigungen „Projekt lesen und Flows lesen“ hat

Bei

  • a) würde man die Berechtigungen direkt vergeben. Da müsste man es für jeden User separat machen. Bei wenigen Nutzern evtl. praktischer. je mehr Nutzer mit gleichen Berechtigungen aufwändiger und redundanter.
  • bei b) würde man dem Benutzer also Rollen zuordnen. Rollen wären wiederverwendbar.
  • b) wäre wiederverwendbarer, aber man müsste für jede Abweichung / Variation eine neue Rolle erstellen. Im worst-case hat man genau so viele „Hilfsrollen“, wie Nutzer.

Beide Ansätze haben ihre Vor- und Nachteile und unterschiedlichen Pflegeaufwand.
Das sind gerade unsere Fragezeichen.

Ich würde hier zu Ansatz b) tendieren, weil die Rechtevergabe an Rollen ja auch der aktuelle Standard im Workspace ist. Für unsere Belange wäre es auch vollkommen ausreichend die bereits existierenden Rollen zu verwenden, nur eben eine Ebene tiefer.

VG,
Florian

1 „Gefällt mir“

Danke.

Gibt es eigentlich Meinungen von anderen, die mit der Rechteverwaltung in anderen Systemen Erfahrungen gemacht haben? ( vielleicht @samenhaus-admin , @shopmind , @gustavfriedeheim )

Ja, fände ich sehr gut! Ich dachte sogar kurz, du würdest hier auf einen Featurewunsch von mir antworten. Aber ich hatte keinen gestellt :wink:

Zur Rechteverwaltung in Plenty sag ich besser nichts :speak_no_evil:

Ja, genau das würden wir benötigen. Bei uns entwickelt niemand außer ich in Synesty, aber es gibt immer wieder Flows, auf die Kollegen zugreifen müssen. Typischerweise sollen die dort nichts bearbeiten dürfen, oder wenn, dann nur Variablen im Flow. Dazu noch Flow ausführen und Eventlog anzeigen.

Das wäre der typischste Use-Case in unserem Fall. Bisher musste ich den Kollegen dann Vollzugriff geben, und sie drauf schwören lassen dass sie nichts anfassen :grin:

Uns würde Option A vollkommen ausreichen, typischer Weise soll jeder Kollege auf einen oder wenige Flows Zugriff haben. Und der nächste Kollege genauso, aber mit anderen Flows.

Aber das kann sich auch ändern, im Zuge größtmöglicher Flexibilität machen Rollen sicher mehr Sinn. Das bisschen Mehraufwand das mir dadurch entstehen würde, würde ich akzeptieren :ok_hand:

Führt dann wahrscheinlich zum erwähnten „eine Rolle pro Nutzer“, aber das ist ja egal. Wenn je doch noch ein zweiter Kollege dazu kommt, muss ich nur die Rolle vergeben. Ja, macht Rollen!

Sehr guter Featurewunsch auf jeden Fall, unterstütze ich vollkommen!

Grüße Daniel

1 „Gefällt mir“

Junge Junge, allein bei dem Gedanken daran krieg ich schon wieder Ausschlag. Ich hoffe, dass die das Thema endlich mal in den Griff kriegen dieses Jahr.

Danke für das Feedback. Ja es werden Rollen werden. Wir spezifizieren das auch gerade so, dass es voraussichtlich für alle Dinge innerhalb eines Workspaces gehen wird (Projekte, Mappingsets, Datastores… also alles was in einer Rolle steckt). Projekte alleine reicht vermutlich nicht. Im ersten Wurf werden es vermutlich nur Projekte, der Rest danach. Aber noch sind wir am planen.

Weitere Frage in die Runde:

Mal etwas weiter gedacht: Was ist euch wichtig beim Thema „den Überblick behalten“ - also „herauszufinden, wer darf was“?

Anzeige im „Ding“ (Projekt, Flow, usw) wer darauf Zugriff hat, und umgekehrt am Nutzer und der Rolle, worauf die Zugriff hat, wäre perfekt mMn.

Ersteres gerne auch zugeklappt hinter einem Button. Und ausgegraut wenn ich der einzige mit Zugriff bin.

2 „Gefällt mir“

Ich bin zwar etwas später zu der Party, aber kann mich hier auch anschließen. Im Moment habe ich für reine Anwendernutzer immer URL-Trigger benutzt, die die Anwender über ein kleines Formular auf einer Wordpress-Seite aufrufen.
Wenn ich die Anwendung von der Modifikation auch direkt in Synesty trennen kann, wäre eigentlich hinfällig.

Wenn ein Nutzer keine Leserechte für ein Projekt hat, dann sieht er das garnicht erst in seiner Liste, richtig? So kann man dem Anwender ja auch das Leben erleichtern, dass er nicht jedesmal aus Dutzenden Projekte das eine für ihn relevante raussuchen muss.

1 „Gefällt mir“

Kann ich nur bestätigen. Aber die letzte Version geht in die richtige Richtung.

Grundsätzlich gibt es bei Euch nicht so viele Anwender, welche in das System müssen. Trotzdem halte ich Rollen für absolut wichtig. Vor allem bei Accounts die wirklich mit mehreren Entwicklern und Nutzern arbeiten.

Bei den Nutzern sollte zusätzlich noch eingestellt werden können in welchen Bereich und / oder welche Flows, Datastores usw. diese arbeiten dürfen, bzw. was sie sehen. Dies kann auch bei den Rollen definiert werden und wird an die zugeordneten Nutzer vererbt, bzw. kann durch die Nutzereinstellungen überschreiben werden.

Die Unterscheidung zwischen Flows / Daten / Mappingsets / Verbindungsdaten sehen, Daten bearbeiten, Struktur ändern und löschen wäre eine Auswahlmöglichkeit.

1 „Gefällt mir“

Ich könnte mir das als Tabelle vorstellen:

Berechtigung Sichtbar Bearbeiten Löschen Struktur Log
z.B. Nutzer A oder Rolle 1
Projekt A x x o o x
Flow A-1 x x o x x
Flow A-2 x o o o o
Flow B-1 x x x x x
Datastore A x x o o
Mappingset A x o o
Verbindung C x o x

Eventuell auch aufklappbar, je nach Projekt bzw. Bereich.

Gruß Dirk

1 „Gefällt mir“