Um das mit Beiträgen machen zu können, müsstest Du für jeden User eine eigene Gruppe und eine eigene Beitragskategorie anlegen.
Ich denke Du könntest das viel einfacher machen, wenn Du ein Custom Field (Editor) für Benutzer anlegst. Dann können sie die Skills in Ihrem User-Profil schreiben. Dann musst Du nicht separate Gruppen oder so anlegen. Auslesen lassen sich die Custom Fields ebenfalls.
Ich glaube das Konzept ist noch nicht so wirklich durchdacht oder wir verstehen es nicht. Solange wir es nicht verstanden haben, ist es auch schwierig eine Idee oder Empfehlung abzugeben.
Jeder User kann selbst entscheiden innerhalb welchem Zeitfenster (Stunden, Tag, Monat oder Jahr) er sein Kontingent an Artikeln aufgebraucht hat.
Das heißt - wenn ich 20 Artikel (Beiträge) einstellen möchte, dann lege ich das Kontingent auf Stunde fest. Soviel schaffe ich eh nicht in einer Stunde. Aber wenn die Stunde rum ist, dann beginnt ein neues Kontingent, wo ich wieder 10 erstellen kann.
Frage wäre nur, wo soll der User das selbst festlegen können?
Das nächste wäre:
Beiträge sind einer Kategorie zugeordnet und keiner Gruppe. Man kann einer Gruppe die Berechtigung geben, dass sie nur Beiträge in einer bestimmten Kategorie erstellen / bearbeiten darf. Aber das ist ganz was anderes.
Man könnte über die DB auslesen, welcher User welchen Beitrag erstellt hat und dazu das Erstellungsdatum. Ob das alles zusammen zum gewünschten Ziel führt wage ich derzeit noch zu bezweifeln.
Wenn ich mich recht erinnere muss man bei sigplus den Pfad ausgehend vom "images" Verzeichnis angeben.
{gallery}folder/subfolder{/gallery}Es gibt aber auch ein Button-Plugin mit dem man es auswählen und weitere Einstellungen separat vornehmen kann.
https://hunyadi.info.hu/sigplus/
Also Joomla 3.9 ist nicht wirklich aktuell. Da sind mir mittlerweile bei der Version 3.10.8
An Deiner Stelle würde ich gleich auf Joomla 4.1 wechseln, da es ab dieser Version den Task-Sheduler gibt.
https://www.joomla.de/news/joo…ringen-joomla-4-1-und-4-2
Bei meiner entsprechenden Gruppe habe ich Status bearbeiten von "vererbt / nicht erlaubt" auf erlaubt gesetzt. Nun funktioniert es.
Wenn Du dort "vererbt" eingestellt hast und rechts daneben "vererbt / nicht erlaubt" steht, dann wird das nicht ausreichen. Dann ist in einer Gruppe darüber schon etwas auf "nicht erlaubt" eingestellt. Das sollte man versuchen immer zu vermeiden, weil das "nicht erlaubt" immer Vorrang hat.
Unter "System - Konfiguration - Beiträge - Berechtigungen" stellst Du das "global" ein. Das wirkt sich auf alle Beiträge aus, was Du ja nicht wolltest. Deswegen belasse es dort bei Deiner Gruppe auf vererbt und erlaube in der Kategorie.
Das ist ein Zeichen dafür dass der Beitrag nicht auf "Veröffentlicht" steht. Du hast den Tab "Veröffentlichen" und da muss der Status des Beitrag auch auf veröffentlicht gestellt werden.
Siehe Screenshot #20
Wenn das so bei Dir aussieht und Du auf das Schloß klicken musst, dann ist der Beitrag von dem User noch gesperrt. Das heißt er hat diesen noch in Bearbeitung. Du siehst auch welcher User, wenn Du mit der Maus darüber gehst.
Das sollte eigentlich nicht mehr sein, wenn im Frontend die Bearbeitung "sauber" verlassen wurde durch Speichern oder Abbrechen.
Wenn Du was anderes hast, dann mache mal Screenshots, damit man das mal sehen kann.
Seltsam ist, dass ich den Reiter Veröffentlichen sehen kann aber der Beitrag immer freigegeben werden muss....
Vielleicht habe ich Dich auch missverstanden.
Wenn er einen neuen Beitrag anlegt und veröffentlicht, dann ist er gleich zu sehen oder?
Wenn ein bestehender Beitrag geändert wird, dann ist die Änderung auch gleich zu sehen oder?
Der Beitrag ist lediglich für andere gesperrt und Du musst diesen im Backend erst wieder freigeben, damit er von anderen Bearbeitet werden kann?
Wenn das letztere der Fall ist, dann wird er im Frontend vermutlich nicht richtig geschlossen. Nach der Änderung mit "Speichern & Schließen" oder "Abbrechen" die Bearbeitung abschließen, dann sollte der auch freigegeben sein.
für mich sieht es so aus, als wäre dem neuen User kein Editor zugewiesen (JCE?).
Zusätzlich würde ich auch mal in der Komponente vom JCE schauen. Da gibt es den Punkt Profile. Die Benutzergruppe in der der User ist muss dort einem Profil zugewiesen sein und das Profil muss aktiviert sein.
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?
Du musst das bei der Kategorie einstellen. "Status bearbeiten" => erlaubt.
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.
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.
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.
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.
Bei den meisten Beispielen ist es reines CSS. Das kommt dann in die user.css
Hier hast Du einige Beispiele, die sich damit umsetzen lassen:
https://www.littlesnippets.net/categories/image-cards
Wenn Du es so löst, wie in meiner Anleitung, dann kannst Du der Gruppe die Berechtigung "Status bearbeiten" erlauben. Dann sollten die auch den Beitrag veröffentlichen dürfen.
https://it-conserv.de/blog/ber…ngen-fuer-ein-verein.html
Wenn Du Felder in Subforms hast, dann habe ich hier etwas dazu geschrieben:
Hast Du mal einen Link zu der Seite?
Ich bin nur gleich erst einmal unterwegs - kann daher erst später schauen. Es sollte vor jedem Intro-Artikel auf jeden Fall ein DIV mit der Klasse "columns-4" existieren. Es kann auch an der responsiven Darstellung liegen, dass sie untereinander angezeigt werden.
