Verschiedene Benutzerrechte (Gruppen / Zugriffsebenen)

Ja, kann man. Nützlich in dem Zusammenhang ist diese Anleitung. Was man aber definitiv nicht machen soll, ist vorhandene Gruppen zu löschen. Das fällt dir irgendwann auf die Füsse.

Wer an den Berechtigungen rumschraubt, sollte erst genau wissen, wie der Zusammenhang zwischen

- Benutzer

- Benutzergruppen

- Zugriffsebenen

funktioniert.

Ich kann mich an eine Kundenseite, die liess sich partout weder Backuppen, noch Updaten. Laufen tat sie zwar, aber Joomla liess sich nicht aktualisieren, Erweiterungen nur teilweise. Der Kunde hatte an den Berechtigungen herumgeschraubt und Gruppen gelöscht. Dadurch funktionierte die gesamte Vererberei von Rechten nicht mehr.

Mein Rat: Gruppen, Zugriffsebenen und deren Konfiguration sein lassen, und bei Bedarf eigene Gruppen und Zugriffsebenen erstellen, und die Rechte entsprechend gewähren.

Nur so hat man die Möglichkeit, Fehler zu suchen und auch zu beheben. Alles andere ist in meinen Augen fahrlässig. Und dann natürlich noch: Kein Backup, kein Mitleid

Die Gruppen und Zugriffsebenen aus dem Core würde ich niemals löschen oder ändern. Sie dienen Dir immer als Fallback, wenn mal irgendwas nicht so funktioniert, wie es sollte.

Viele Anleitungen, wie die in #2 genannte, bauen auf die bestehenden Gruppen und Zugriffsebenen auf. Veränderst oder löscht Du diese, kann das zu Fehlfunktionen führen.

Sorry, aber außer die "Public" Zugriffsebene ist jede Core-Usergruppe/Ebene wie eine eigen erstellte. Da gibts codetechnisch absolut keinen Unterschied und man kann diese ändern/löschen oder neue anlegen. Wichtig ist nur, dass man am Ende die Zuweisung in den Einstellungen aktuell hält und schaut, dass man sich nicht aussperrt.

Zitat von bembelimen

Sorry, aber außer die "Public" Zugriffsebene ist jede Core-Usergruppe/Ebene wie eine eigen erstellte. Da gibts codetechnisch absolut keinen Unterschied und man kann diese ändern/löschen oder neue anlegen. Wichtig ist nur, dass man am Ende die Zuweisung in den Einstellungen aktuell hält und schaut, dass man sich nicht aussperrt.

Hör doch einfach auf die Profis ohne das Ganze jetzt in Frage zu stellen. Es ist eine berechtigte Empfehlung an die du dich halten kannst oder nicht.

Es wäre nicht das erste Mal, dass im Nachhinein, genau hier wieder, ein neues Thema aufgemacht wird um die dann, durch ignorierte Warnungen auftretenden Probleme, zu beheben.

Zitat

Hör doch einfach auf die Profis

Selten so gelacht

Zitat von firstlady

Selten so gelacht

Eh klar. Mein Rat bezog sich ausschliesslich auf die Otto Normalverbraucher, die ohne Not und ohne eventuelle Konsequenzen zu bedenken, fröhlich rangehen und Gruppen, die sie für unnötig halten, löschen. Dass hier bembelimen als 'Un-Profi' bezeichnet wird, ja, hat auch meinen Sonntagabend gerettet.

Was so ein ein Zitat zur Heiterkeit beitragen kann ist schon echt witzig .

Aber mal im Ernst, es war eigentlich an marcusfuerth und die Allgemeinheit gerichtet mit dem Hinweis auf das was im Zitat steht .

Naja, bembelimen wird`s schon verkraften.

Das ist ein ganz normales Verhalten bei der Vererbung. Die untergeordnete Gruppe erbt alle Rechte der übergeordneten. Es geht hier immer von wenig nach mehr.

Author erbt alle Rechte von Registered

Editor erbt alle Rechte von Author

Publisher erbt alle Rechte von Editor

Somit hat die Gruppe Publisher automatisch die Rechte von Registered, Author und Editor.

Wenn die zu viele Rechte haben, dann eine oder mehrere Ebenen höher und explizit erlauben, was sie dürfen. Meine Empfehlung: niemals "verweigert" einsetzen, da ein "verweigert" nicht mehr aufgehoben werden kann.

Die hier genannten Gruppen haben "globale" Einstellungen, die sich auf alle Beiträge auswirken. Aus diesem Grund habe ich wie in der Anleitung #2 extra darauf verzichtet und eigene Gruppen unterhalb von "Registered" angelegt.

Wenn Du bei Deiner Gruppe "verweigerst" einstellst, dann gilt das nur für die Gruppe. Aber dennoch würde ich das versuchen zu vermeiden.

Wenn Du Berechtigungen in der globalen Konfiguration (System - Konfiguration - Beiträge) veränderst, dann wirkt sich auf alle Beiträge aus.

Wenn die Gruppe nur bestimmte Beiträge ändern, freigeben, ... sollen, dann müsstest Du diese einer Kategorie zuordnen. Dann kannst Du die Einstellungen direkt bei der Kategorie vornehmen. Dort dann z.B. der Gruppe erlauben.

Zitat von marcusfuerth

Die Gruppe soll tatsächlich nur neue Beiträge anlegen, bearbeiten und löschen können.

a) Ich würde wie in der Anleitung beschrieben die Gruppe unterhalb von Registered anlegen. Dann eine Beitragskategorie in der die Beiträge zugeordnet werden. In der Beitragskategorie unter Berechtigungen wählst Du die Gruppe aus und stellst alles auf erlaubt, was sie dürfen.

b) Dann legst Du eine Zugriffsebene (wie in der Anleitung beschrieben) "Beiträge erstellen" an. Dieser werden mind. die Gruppen "Super Users", "Administrator" und Deine angelegte Gruppe zugeordnet.

c) Dann legst Du einen Menüpunkt "Neuer Beitrag" an und weist diesem Menüpunkt die Zugriffsebene "Beiträge erstellen" zu.

d) jetzt legst Du einen User an und weist ihm nur die Gruppe zu, die Du unter a) angelegt hast und meldest Dich mit ihm im Frontend an.

erwartetes Ergebnis:
Den Menüpunkt sehen nur Mitglieder Deiner angelegten Gruppe, sowie Mitglieder der Gruppe "Administrator" und "Super Users". Alle anderen sehen den Menüpunkt nicht. Hier können sie nun Beiträge erstellen, haben aber zur Auswahl nur die in a) angelegte Kategorie. Ebenso können sie auch nur die Beträge dieser Kategorie bearbeiten, löschen, freigeben. Je nachdem welche Berechtigungen Du in b) erlaubt hast.

Ist ein User jedoch in Deiner angelegten Gruppe und zusätzlich "Author" oder "Publisher", dann haben sie durch die anderen Gruppen weit aus mehr Rechte.

Du musst das bei der Kategorie einstellen. "Status bearbeiten" => erlaubt.

wenn Du mit dem User im Frontend angemeldet bist und einen neuen Beitrag erstellen möchtest - hast Du den Reiter "Veröffentlichen"?

Hast Du ggf. Workflows aktiviert, dass es durch einen Workflow verhindert wird?