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 
Wir müssten mal euren Fall tabellarisch spezifizieren.
Hier mal ein Versuch / Anfang:
W1
W2
Augenmerk auf User C SollGanzWenigDürfen
IST-Zustand:
Ziel:
Frage:
Spiegelt das Ziel eure Anforderung wieder?
@synesty-Lukas im Prinzip korrekt ja.
Ergänzend vielleicht noch folgendes Szenario:
Workspace W1:
Projekt P1
Projekt P2
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:
oder
b) an einem Projekt zu sagen:
Bei
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
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
Zur Rechteverwaltung in Plenty sag ich besser nichts 
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 
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 
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
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.
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.
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.
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