Rechte des öffentlichen Benutzer sollten sich nur auf anonyme Session beziehen.
-
@Marcel In dem oben geschilderten Fall nicht ganz! Es geht ja darum, dass ich bei Terminen festlegen kann, dass diese nur für angemeldete Benutzer sichtbar sind. Der öffentliche Benutzer sieht sie also nicht. Wir lösen das so, in dem wir einen Kalender "interne Termine" verwenden, der dementsprechend nicht für den öffentlichen User freigegeben ist.
-
@Andy wunderbar schon wieder was gelernt, die Einstellung hatte ich gar nicht auf dem Schirm, da ich dies auf Kalenderebene lösen würde.
-
@Marcel Richtig ... ich auch.
Die Funktion führt sogar leider gelegentlich zu unerwünschten Effekten. Das Häkchen wird manchmal unbedacht gesetzt und dann wundert man sich, dass Termine nicht auf der Homepage erscheinen. Für mich könnte das ersatzlos weg. -
@Marcel auf Kalenderebene skaliert das nicht. Bei uns sind die Kalender nach Kreis erstellt worden. Und egal wie ich das dreh und wende es läuft wegen diesem Feature immer auf zwei Kalender raus. Einen internen und einen öffentlichen. Bei 12 öffentlichen nochmal 12 interne... ne lieber nicht.
Ich wäre ja auch zufrieden, wenn die Rechte des öffentlichen Nutzers 1:1 übernommen werden, aber leider ist es ein Mix. Rechte des öffentlichen Nutzers werden als angemeldeter Nutzer neu ausgewertet. Und auf einmal sieht man Termine die man nicht sehen sollte.
-
@jonny So ist an diese Stelle derzeit das Konzept der CT. Angemeldet ist angemeldet. Der Support hat dir das ja auch bestätigt und das Häkchen sagt ja auch genau das. Du hast hier ja nun diesen Feature-Wunsch erstellt und mit den entsprechenden Votings wird dein Wunsch ja dann ggf. umgesetzt.
-
Das war mir bisher nicht so bewusst und logisch ist es schon mal gar nicht.
Bisher war ich der Meinung, das Rechtekonzept von CT sieht so aus:
Status -> Gruppentyp -> Gruppe -> UserIn Wirklichkeit scheint es aber eher nach dem System
Öffentlicher Nutzer -> Status -> Gruppentyp -> Gruppe -> User
aufgebaut zu sein.Das ist für mich anhand des User-Interface weder erkennbar und logisch nachvollziehbar. Da sich der öffentliche Nutzer auf der untersten Ebene befindet, wirkt es für mich so, dass sich die Rechte auf nur darauf beziehen und nicht die Rechtevergabe mit den größten Auswirkungen ist.
Hier sollte also nachgebessert werden und entweder das Userinterface an die Realität angepasst oder noch besser sich die Rechte wirklich nur auf anonyme Sitzungen beziehen.
Ich sehe in dem Haken bei der Terminerstellung ein wichtiges Feature. So kann man dem Nutzer sagen, dass er bei einem Team-Treffen, das nicht auf der Homepage etc. erscheinen soll, einfach den Haken setzen soll (Wenn man den Text besser formuliert, kommt er da wahrscheinlich sogar selbst drauf), statt dass er überlegen muss, in welchen Kalender er es schreiben soll.
Abgesehen davon, dass so nur die Liste der Kalender länger und damit unübersichtlicher wird. -
@hallo144 Wieso? Ist doch alles richtig. Oder stehe ich auf dem Schlauch? Der öffentliche User ist nicht angemeldet und sieht die entsprechend gekennzeichneten Termine nicht. Bin ich angemeldet (mit welchem Status auch immer), dann sehe ich die Termine, die nur mit Anmeldung zu sehen sein sollen. Was ist daran falsch?
Bisher war ich der Meinung, das Rechtekonzept von CT sieht so aus:
Status -> Gruppentyp -> Gruppe -> UserSo ist es doch auch. Wobei auf der untersten Ebene unterschieden wird zwischen an- und abgemeldet.
-
@Andy sagte in Rechte des öffentlichen Benutzer sollten sich nur auf anonyme Session beziehen.:
Bin ich angemeldet (mit welchem Status auch immer), dann sehe ich die Termine, die nur mit Anmeldung zu sehen sein sollen. Was ist daran falsch?
Allerdings auch Kalender, die man eigentlich nicht sehen sollte und vorallem auch die dort die öffentlich nicht sichtbaren Termine, auf die man eigentlich keinen Zugriff hat.
Bei "nur für angemeldete Benutzer sichtbar" gehe ich davon aus, dass das nur die Leute sehen, die auch Zugriff für den Kalender haben und man nicht plötzlich über einen anderen Benutzer (genau das ist der "öffentliche Benutzer" im UI) auch Zugriff auf diese Kalender bekommt.
Gleiches Verhalten trifft ja wahrscheinlich auf alle Bereiche des öffentlichen Nutzers zu und die können durchaus sensitiver sein.
Und Zugriff auf UI ist was anderes als ID-guessing über API. Das sollte dann ja auch geblockt werden, wenn jemand viele nicht vergebene IDs aufruft. -
@hallo144 Darum heißt der Benutzer ja auch "öffentlich" und es bei dem Häkchen "angemeldet". Zugegeben ... in der Hilfe wird eindeutig zu wenig oder gar nicht darauf eingegangen. Irgendwie hat es in den letzten Jahren aber auch keine großen Fragen dazu hier im Forum gegeben. Das mag auch daran liegen, dass (zumindest vor 5 Jahren) der Kalender "interne Termine" automatisch in der Standardinstallation vorhanden und es somit jedem Admin irgendwie einleuchtend war, diesen Kalender für spezielle Termine zu verwenden.
Grundsätzlich ist es in den CT aber ja so, dass persönliche Berechtigungen vorrangig sind. Gebe ich Max Mustermann vollen Zugriff auf alle Personen, dann ist es egal, was die Gruppen oder Gruppentypen beinhalten, in denen Mustermann Teilnehmer, Mitarbeiter oder Leiter ist.
Der öffentliche Benutzer ist eben genau so eine Person ... diese ist aber öffentlich und somit hat jeder User mindestens die Berechtigungen, die ich der Öffentlichkeit gebe.
Das würde vielleicht deutlicher, wenn man den öffentlichen User nicht bei den Benutzern ansiedeln, sondern einen Reiter "Öffentlichkeit" vor dem Status implementieren würde:
Das wäre sicherlich ein guter Feature-Wunsch zur Verdeutlichung dieses speziellen Benutzers.
-
Das mit den additiven Berechtigungen ist mir schon klar, aber das die Rechte eines anderen Nutzers übernommen werden (genau so sieht es zur Zeit aus), geht einfach mal gar nicht.
Das müsste zumindest an Ort und Stelle auffällig dokumentiert werden.Da irgendwas zu ändern (wie auch immer) ist für mich kein Feature-Request, sondern ein Sicherheitsrisiko und damit ein Fehler.
Abgesehen davon, sehe ich in der jetzigen Lösung mit "Öffentlicher Nutzer" als Master einige Nachteile:
- jeder potentielle Nutzer braucht Schreibzugriff auf diesen Kalender und hat damit einen mehr in seiner Liste, von denen er den richtigen wählen muss.
- er kann dort alle Termine ändern, nicht nur seine eigenen (bzw. die seines Arbeitsbereiches)
- es müssen zwei Kalender abonniert werden (ical am Handy), um alle Termine zu sehen. Zusätzlich bekommt man so einen Haufen Termine rein, die einen nicht interessieren.
Wir haben es zur Zeit so gelöst, dass es für jeden Arbeitsbereich einen Kalender gibt und so etwas wie Team-Treffen dort als "Nicht öffentlich sichtbar" eingetragen werden. Das ist für jeden Nutzer einleuchtend und funktioniert relativ fehlerfrei. Und leicht zu administrieren ist es auch.
Da wir den Status "unbekannt" kaum Nutzen, ist es uns zur Zeit egal, dass da einiges ungewöhnlich gelöst ist, aber falls doch müsste ich entweder für jeden Bereich einen zweiten Kalender anlegen (aufwendig und ggf. teuer) oder mit oben genannten Nachteilen leben.
Warum nicht einfach den "Öffentlichen Nutzer" als Nutzer ohne Status, Gruppenzugehörigkeit und Anmeldemöglichkeit betrachten? Das finde ich einleuchtender, flexibler und alles bisherige kann man auch weiter so abbilden. Und sogar automatisch umstellen, indem einfach alle Status die Rechte des öffentlichen Nutzers bekommen.