EDIT

Hallo Andreas,

wir haben damals alles, was nur als Admin nutzbar sein soll in das Admin Menü geschoben, eben auch die serversided Preferences (vorher hießen die auch Admin-Preferences).
Ich finde es eigentlich nicht so unintuitiv, aber das mag auch an meiner Entwicklersicht liegen.

Viele Grüße,
Katja

Hallo Katja,

in den meisten Fällen orientiert sich der Aufbau vom Menüs an funktionalen Zusammenhängen. Ein so starker Bezug eines Menüs zu einer Rolle ist unüblich weil für den User nicht hilfreich. Als Neuling in einer Anwendung würde man doch erwarten, dass weitere Settings da zu finden sind, wo sich auch andere Settings befinden. Es gibt ja auch die Rolle Usermanager, der darf nicht ohne weitere Permissions die server-sided Preferences ändern, insofern macht es auch kein Sinn Users+Groups zusammen mit den Server-sided Preferences in einem Menü zuhaben.

Ich schlage daher vor beide Prefernces Menu-Items in einem Menü unterzubringen also Window, General oder ein eigenes für Settings?

Viele Grüße
Andreas

Hallo Andreas,

am besten besprechen wir das nächste Woche alle zusammen, wenn auch Andreas M. wieder da ist. Da bisher eher keine Usermanager ohne Adminrechte existierten, war das bisher noch kein Problem, dass die serverseitigen Preferenzen im gleichen Menü waren, wie Users + Groups, aber wenn es diese Trennung in Projekten gibt, dann hast du sicher recht.

Viele Grüße,
Katja

Also ich finde das weiterhin gut, die Projektsettings dort zu haben, wo das Projekt administriert wird und die lokale UI dort, wo ich auch sonst lokal auf Daten arbeite.

Eclipse macht das übrigens auch ähnlich, dort gibt es Window-Preferences und Project-Properties. Die überschneiden sich durchaus und in ersterem werden einige defaults von letzterem gesetzt.

Der Fall, dass jemand User definiert Rechte hat, aber keine DB-Preferences-Setting Rechte mag ein Spezialfall sein. In diesem Fall sollte man die DB-Preferences-Rechte natürlich ausblenden. In der Regel wird sich das aber überschneiden.

Übrigens sollten wir über ein Recht nachdenken, die DB-Preferences zu setzen, ohne gleich vollständiger admin zu sein.

Andreas Müller wrote:

Also ich finde das weiterhin gut, die Projektsettings dort zu haben, wo das Projekt administriert wird und die lokale UI dort, wo ich auch sonst lokal auf Daten arbeite.
Gerade dieses Argument finde ich wenig stichhaltig, da ja alles was sich unter Window befindet zur "Editoren" führt, die Daten in der DB verändern, also eben genau nicht lokale Daten.

Eclipse macht das übrigens auch ähnlich, dort gibt es Window-Preferences und Project-Properties. Die überschneiden sich durchaus und in ersterem werden einige defaults von letzterem gesetzt.

Richtig, aber hier finde ich die Zurordnung stimmiger (siehe oben lokal vs nicht-lokal) muss aber auch sagen, dass ich zu meinen Anfangszeiten mit Eclipse immer wieder auf der Suche nach den Window->Preferences war. Intuitiv habe ich unter File und Edit gesucht. BTW: Bei Apple gibt es seit Jahren das Paradigma dass die Settings immer an ein und dem selben platz sein sollen, unter dem Apfelmenü.

Der Fall, dass jemand User definiert Rechte hat, aber keine DB-Preferences-Setting Rechte mag ein Spezialfall sein. In diesem Fall sollte man die DB-Preferences-Rechte natürlich ausblenden. In der Regel wird sich das aber überschneiden.

Zugegeben, dieser Fall tritt eher selten auf und ist insofern ein wenig konstruiert.

Übrigens sollten wir über ein Recht nachdenken, die DB-Preferences zu setzen, ohne gleich vollständiger admin zu sein.

Das gibt es schon: ROLE_PROJECT_MANAGER

Andreas Kohlbecker wrote:

Andreas Müller wrote:

Übrigens sollten wir über ein Recht nachdenken, die DB-Preferences zu setzen, ohne gleich vollständiger admin zu sein.

Das gibt es schon: ROLE_PROJECT_MANAGER

Sehr schön. Kannst du die auf https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/CdmAuthorisationAndAccessControl noch dokumentieren?

Außerdem: Gibt es einen Grund warum ROLE_MANAGE_CLIENT in remote definiert ist und alle anderen in hibernate.permission? Insbesondere ROLE_REMOTING ist ja eigentlich auch nur eine Webservice Absicherung. Ist es nicht besser, wenn wir die Rollen versuchen alle an einem Ort zu haben, auch wenn das evtl. nicht 100%ig die genaue Abhängigkeit von den Projekten widerspiegelt?

Andreas Kohlbecker wrote:

Andreas Müller wrote:

Also ich finde das weiterhin gut, die Projektsettings dort zu haben, wo das Projekt administriert wird und die lokale UI dort, wo ich auch sonst lokal auf Daten arbeite.
Gerade dieses Argument finde ich wenig stichhaltig, da ja alles was sich unter Window befindet zur "Editoren" führt, die Daten in der DB verändern, also eben genau nicht lokale Daten.

Eclipse macht das übrigens auch ähnlich, dort gibt es Window-Preferences und Project-Properties. Die überschneiden sich durchaus und in ersterem werden einige defaults von letzterem gesetzt.

Richtig, aber hier finde ich die Zurordnung stimmiger (siehe oben lokal vs nicht-lokal) muss aber auch sagen, dass ich zu meinen Anfangszeiten mit Eclipse immer wieder auf der Suche nach den Window->Preferences war. Intuitiv habe ich unter File und Edit gesucht. BTW: Bei Apple gibt es seit Jahren das Paradigma dass die Settings immer an ein und dem selben platz sein sollen, unter dem Apfelmenü.

Also dann müssten wir da alles komplett umstellen, also auch die anderen Sachen aus dem admin Menü. Ich sehe da gerade wirklich nicht die Notwendigkeit, da die Admin Prefs ja wirklich seltenst benutzt werden und wenn dann v.a. von Usern die sich auskennen. Zudem hat das jetzige Menü zumindest eine ganz gute innere Logik. Zudem ist das gesamte Menü derzeit noch sehr übersichtlich, so dass man sogar, wenn man die Admin-Prefs wo anders erwartet, diese schnell finden sollte. Das ist bei der Eclipse IDE mit vielen Menüs und Submenüs anders.
Aber wir können das natürlich gerne auch noch mal beim Usermeeting besprechen.

Andreas Müller wrote:

Andreas Kohlbecker wrote:

Andreas Müller wrote:

Übrigens sollten wir über ein Recht nachdenken, die DB-Preferences zu setzen, ohne gleich vollständiger admin zu sein.

Das gibt es schon: ROLE_PROJECT_MANAGER

Sehr schön. Kannst du die auf https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/CdmAuthorisationAndAccessControl noch dokumentieren?

Außerdem: Gibt es einen Grund warum ROLE_MANAGE_CLIENT in remote definiert ist und alle anderen in hibernate.permission? Insbesondere ROLE_REMOTING ist ja eigentlich auch nur eine Webservice Absicherung. Ist es nicht besser, wenn wir die Rollen versuchen alle an einem Ort zu haben, auch wenn das evtl. nicht 100%ig die genaue Abhängigkeit von den Projekten widerspiegelt?

Ich habe di doku zu den rollen ROLE_PROJECT_MANAGER und ROLE_MANAGE_CLIENT ergänzt. Aus der Beschreibung zu ROLE_MANAGE_CLIENT geht jetzt auch hervor warum diese Rolle nicht in hibernate.permission passt: "this role is only granted to machine clients only and never to real persons"

Andreas Müller wrote:

Andreas Kohlbecker wrote:

Andreas Müller wrote:

Also dann müssten wir da alles komplett umstellen, also auch die anderen Sachen aus dem admin Menü. Ich sehe da gerade wirklich nicht die Notwendigkeit, da die Admin Prefs ja wirklich seltenst benutzt werden und wenn dann v.a. von Usern die sich auskennen. Zudem hat das jetzige Menü zumindest eine ganz gute innere Logik. Zudem ist das gesamte Menü derzeit noch sehr übersichtlich, so dass man sogar, wenn man die Admin-Prefs wo anders erwartet, diese schnell finden sollte. Das ist bei der Eclipse IDE mit vielen Menüs und Submenüs anders.
Aber wir können das natürlich gerne auch noch mal beim Usermeeting besprechen.

Menüpunkte in Eclipse RCP zu verschieben ist doch sicherlich nicht so extrem aufwändig, oder? Du sagst ja selbst, dass das Menü noch sehr überschaubar ist, also nicht extrem viele Menüs und Unterpunkte von einer Änderung betroffen sein würden. Im Usermeeting würde ich keine Grundsatzdiskussion darüber führen wollen, wohin ein bestimmter Menüpunkt gehört. Ich denke es wäre besser zunächst ein klares Konzept zu haben und dies dann vorzustellen. Lass dieses Thema erst noch einige Zeit in unserm Kreis gären - hat ja keine Eile.

Ich meine nicht das verschieben, sondern die Änderung der Semantik. Wir würden ja das jetzige Konzept aufbrechen, dass alle Projektsettings im Admin Bereich zu finden sind, da muss man über alles neu nachdenken.
Ansonsten stimme ich überein, dass wir das erstmal weiter gären lassen. Vielleicht ergeben sich ja auch neue Aspekte wenn bald noch mehr Menüpunkte hinzukommen.