Fehler in den Berechtigungen für Beitragskategorien

LukasHH

Gestern habe ich einen Fehler in den Berechtigungen für Beitragskategorien gefunden.

Grundlage bildet meine Anleitung https://it-conserv.de/blog/berechtig…ein-verein.html

Ich habe eine eigene Benutzergruppe, dessen Benutzer im Frontend für Ihre Beitragskategorie selbst Beiträge erstellen, bearbeiten und veröffentlichen dürfen. Die Benutzergruppe befindet sich unter "Registered" und die globalen Berechtigungen sind auf "vererbt" eingestellt. Die spezielle Berechtigung zum erstellen, bearbeiten und veröffentlichen sind für diese Gruppe in dessen Beitragskategorie auf "erlaubt" eingestellt.

Wenn ein User dieser Gruppe einen neuen Beitrag erstellen möchte, dann kann stehen ihm jedoch nicht die Felder für die Veröffentlichung zur Verfügung.
Wenn der User dieser Gruppe einen bestehenden Beitrag bearbeiten möchte, dann stehen ihm die Felder für die Veröffentlichung zur Verfügung.

Meine Recherche hat ergeben, dass beim neuen Beitrag die ausgewählte Beitragskategorie nicht erkannt wird und der User somit auch nicht die Berechtigung erhält.
Ich habe hierzu schon ein Issue aufgemacht https://issues.joomla.org/tracker/joomla-cms/32117

Könnt Ihr den Fehler nachvollziehen?

In der view.html.php von forms liefert die Abfrage der catid keinen Wert, was auch der Grund sein dürfte, dass die Berechtigungen für die Kategorie nicht ermittelt werden können.

PHP

$catid = $this->state->params->get('catid');

Wenn ich die Kategorie wechsel oder aktiv auswähle, dann wird sie in $this erkannt, aber nicht weiter verarbeitet.

Mit $app->input konnte ich die auch nicht empfangen, da bei der Auswahl der Kategorie scheinbar noch kein Input gesendet wurde.

PHP

$app->input->get('catid', 0, 'INT');

j!-n

Zitat

Die Benutzergruppe befindet sich unter "Registered" und die globalen Berechtigungen sind auf "vererbt" eingestellt.

Aus Neugier, und um Logikfehler auszuschließen, und dem Verständnis halber: in welcher Untergruppe von Registered befinden sich die User? Als Basis ist der Publisher für die beschriebene Gruppe imho am Geeignetsten. Es ist immer ratsamer, eigenen Gruppen Rechte zu nehmen, als weniger berechtigte Gruppen aufzubohren.

LukasHH

Hallo Chris,

die Benutzergruppe (in meinem Fall "Fachberater") ist extra nicht unter Publisher, sondern unter "Registered". Wenn ich die "globale" Einstellungen wie "Publisher" (bearbeiten und/oder Status bearbeiten) auf "erlaubt" einstelle, dann sind die Berechtigungen vorhanden. Dann gelten sie aber für alle Kategorien, was hier nicht gewünscht ist.

In der Kategorie hat die Benutzergruppe alle Berechtigungen auf "erlaubt".

christine2

Hallo Peer,

Zitat von LukasHH

Hallo Chris,

die Benutzergruppe (in meinem Fall "Fachberater") ist extra nicht unter Publisher, sondern unter "Registered". Wenn ich die "globale" Einstellungen wie "Publisher" (bearbeiten und/oder Status bearbeiten) auf "erlaubt" einstelle, dann sind die Berechtigungen vorhanden. Dann gelten sie aber für alle Kategorien, was hier nicht gewünscht ist.
In der Kategorie hat die Benutzergruppe alle Berechtigungen auf "erlaubt".

Vorweg: Mit ACL habe ich so meine Mühe, da ich "zum Glück" solche Purzelbäume nicht verwende/brauche.

Hier: https://www.web-consultant.at/joomla-cms/joo…trationsbereich

kann man das nicht so machen wie unter Schritt 5?

Liebe Grüße

Christine

LukasHH

Zitat von christine2

kann man das nicht so machen wie unter Schritt 5?

Hallo Christine,

das wäre auch eine Variante, wobei ich diese nicht schön finde. Erst erlaube ich alles und nehme danach wieder weg. Zumal das "verweigert zusätzlich unschöne Nebeneffekte habe.

Bei meiner Variante habe ich mehrere verschiedene Benutzergruppe (Vorstand, Fachberater, Festausschuss). Wenn ein User zeitgleich "Vorstand" und "Fachberater" ist, dann funktioniert die im Schitt 5 genannte Variante nicht mehr. Das "verweigert" setzt sich hierbei durch und der User hätte keine Rechte mehr.

Was ich eben noch gesehen habe:
Die Berechtigung wird ja in den $params => [access-change] geschrieben. Ermittelt und gesetzt wird es im Model forms.php

PHP

// New item.
    $catId = (int) $this->getState('article.catid'); // Hier steckt das Problem

    if ($catId)
    {
        $value->params->set('access-change', $user->authorise('core.edit.state', 'com_content.category.' . $catId));
        $value->catid = $catId;
    }
    else
    {
        $value->params->set('access-change', $user->authorise('core.edit.state', 'com_content'));
    }

Alles anzeigen

An dieser Stelle müsste man die in der Form ausgewählte Kategorie ermitteln können.

Zum Test habe ich hier und in der view.html.php die catId manuell festgesetzt und dann werden die Berechtigungen gezogen.

Keine Bange - das mache ich alles in meinem lokalen Test-System

christine2

Zitat von LukasHH

das wäre auch eine Variante, wobei ich diese nicht schön finde. Erst erlaube ich alles und nehme danach wieder weg. Zumal das "verweigert zusätzlich unschöne Nebeneffekte habe.

Jo, diesen Einwand habe ich auch erwartet & finde diese Variante auch nicht schön. Zuerst erlaubst mir alles und nimmste mir dann wieder weg Aber weiß leider keine andere .....

Dann teste schön weiter - keine Ahnung von diesen php Eingriffen.

Liebe Grüße

Christine

LukasHH

Ich bin jetzt ein kleines Stück weiter gekommen - aber ist noch nicht die Lösung. Bin mir auch nicht sicher, ob das der richtige Ansatz ist.

Datei: /component/com_content/views/form/view.html.php

PHP

public function display($tpl = null)
{
...
if (empty($this->item->id))
{
    $catid = $this->state->params->get('catid');

    if(empty($catid)){
        $catid = (int) $this->form->getValue('catid');    //Wenn keine catid vorhanden ist, hole sie aus dem Formular
    }

    if ($this->state->params->get('enable_category') == 1 && $catid)
    {
        $authorised = $user->authorise('core.create', 'com_content.category.' . $catid);
    }
    else
    {
        $authorised = $user->authorise('core.create', 'com_content') || count($user->getAuthorisedCategories('com_content', 'core.create'));
    }
}

Alles anzeigen

Datei: /component/com_content/models/form.php

PHP

... Zeile 120
// New item.
$catId = (int) $this->getState('article.catid');

//****************************

if(empty($catId))           // Wenn catId nicht vorhanden ist, dann hole die gewählte aus der Session
{        
    $session = JFactory::getSession()->get('registry')->get('com_content');
    if(!empty($session))
    {
        $catId = $session->edit->article->data['catid'];
    }
}
//*****************************

if ($catId)
{
    $value->params->set('access-change', $user->authorise('core.edit.state', 'com_content.category.' . $catId));
    $value->catid = $catId;
}
else
{
    $value->params->set('access-change', $user->authorise('core.edit.state', 'com_content'));
}
...

Alles anzeigen

Mit diesen Änderungen wird die ausgewählte catID geholt, wenn keine vorhanden ist. Die Felder werden jetzt auch dementsprechend angezeigt. Allerdings ist mir dabei aufgefallen, dass sie auf "readonly" stehen.

Harmageddon

Das ist meines Wissens ein bekanntes Problem, da man bevor die Kategorie gewählt wird nicht wissen kann, welche Rechte dafür bestehen. Siehe z.B. https://github.com/joomla/joomla-cms/issues/17812

Wenn du hingegen für den "Artikel erstellen"-Menüpunkt die Kategorie festlegst, sollte es gehen. Müsste ich aber nochmal genauer nachschauen.

LukasHH

Ah - diesen Issue habe ich nicht gefunden. Aber so wie dort darin geschrieben wurde, hatte das ja mal funktioniert. Wahrscheinlich, weil irgendwo an anderer Fehler vorlag und diese gefixt wurde.

Bei ein paar einzelnen Kategorien wäre das eine Möglichkeit, dass man für jede Kategorie einen Menüpunkt anlegt. Ist aus meiner Sicht nur ein Workaround und keine schöne Lösung. Ich denke da nur an größere Sportvereine mit mehreren Sparten.

Mein Lösungsansatz geht ja dahin:

Sobald in der Kategorieauswahl eine neue Kategorie ausgewählt wird, wird diese ID abgefragt, bevor die Ermittlung der Berechtigung erfolgt. Dadurch, dass die Seite bei der Auswahl neu geladen wird, funktioniert dieser Ansatz. Nur gibt es irgendwo noch andere "Stellschrauben", die ich noch nicht gefunden habe.

Sieger66

Zitat von LukasHH

Könnt Ihr den Fehler nachvollziehen?

Ja, der Fehler ist schon länger vorhanden.

Ich hatte z.B. das dort geschilderte Problem:

Joomla Benutzerrechte für Frontend Bearbeitung

einfach mal ohne die Installation irgend einer Erweiterung wie SP Builder nachgestellt um zu sehen ob das Problem möglicherweise vom Joomal-Core kommt.

Ergebnis identisch wie bei dir, wobei ich festgestellt hatte das die Erstellung und Veröffentlichung von Beiträgen im Backend problemlos möglich ist für die gleichen Benutzergruppen falls man diesen den Backendzugang ermöglicht.

Das geschilderte Problem also im Backend zumindest damals nicht vorhanden war.

Ich wollte eigentlich selbst schon ein Issue öffnen, wollte es aber erst in Joomla! 4 mal testen bzw. nachstellen ob das Problem dort auch noch so vorhanden ist. Ich hatte aber leider zuwenig Zeit dazu.

Harmageddon

Zitat von Sieger66

Ergebnis identisch wie bei dir, wobei ich festgestellt hatte das die Erstellung und Veröffentlichung von Beiträgen im Backend problemlos möglich ist für die gleichen Benutzergruppen falls man diesen den Backendzugang ermöglicht.
Das geschilderte Problem also im Backend zumindest damals nicht vorhanden war.

Das kann ich auf einer 3.9.24 nicht reproduzieren. Da ist im Backend auch der Status gesperrt, solange man den Artikel noch nicht in der Kategorie abgespeichert hat, auf die der Benutzer Zugriff hat.

Zitat von LukasHH

Sobald in der Kategorieauswahl eine neue Kategorie ausgewählt wird, wird diese ID abgefragt, bevor die Ermittlung der Berechtigung erfolgt. Dadurch, dass die Seite bei der Auswahl neu geladen wird, funktioniert dieser Ansatz. Nur gibt es irgendwo noch andere "Stellschrauben", die ich noch nicht gefunden habe.

Das ist auch ein Lösungsansatz, der in dem Ticket genannt wird (überprüfen, welche Rechte man für die aktuelle Kategorie hat). Das müsste dann aber wahrscheinlich über AJAX laufen. Wo wird bei dir denn die Seite neu geladen? Wenn du die Kategorieauswahl im Frontend änderst? Das ist bei mir nicht der Fall.

Deine obige Lösung (Post #7) würde in das gleiche Problem laufen, wenn der Benutzer in mehreren Kategorien Beiträge erstellen, aber nur in einer den Status bearbeiten darf. Also entweder man lässt das wie aktuell statisch, sodass man einmal zwischenspeichern muss, damit die Kategorie feststeht, oder man lädt die Info per AJAX nach.

Zitat von Sieger66

Ich wollte eigentlich selbst schon ein Issue öffnen, wollte es aber erst in Joomla! 4 mal testen bzw. nachstellen ob das Problem dort auch noch so vorhanden ist. Ich hatte aber leider zuwenig Zeit dazu.

Hab es gerade getestet - es sieht aus, als wäre das in J!4 ähnlich. Könnte dort aber mit Workflows eventuell nochmal komplizierter werden, das weiß ich gerade spontan nicht.

Edit:

Zitat von LukasHH

Aber so wie dort darin geschrieben wurde, hatte das ja mal funktioniert. Wahrscheinlich, weil irgendwo an anderer Fehler vorlag und diese gefixt wurde.

Das würde mich ehrlich gesagt wundern. Aber solange niemand sagen kann, wann das mal funktioniert haben soll (und wie) halte ich das erst mal für Spekulation.

Sieger66

Zitat von Harmageddon

Das kann ich auf einer 3.9.24 nicht reproduzieren. Da ist im Backend auch der Status gesperrt, solange man den Artikel noch nicht in der Kategorie abgespeichert hat, auf die der Benutzer Zugriff hat.

Ja, das ist durchaus auch möglich, eventuell erinnere ich mich auch falsch daran, weil es schon vor längerem war. Sorry.

LukasHH

Ich werde das in J4 auch nochmal testen. Ohje - die Workflows - damit muss ich mich auch noch beschäftigen.

Zitat von Harmageddon

würde in das gleiche Problem laufen, wenn der Benutzer in mehreren Kategorien Beiträge erstellen, aber nur in einer den Status bearbeiten darf.

Wenn man eine Kategorie auswählt, in der die Berechtigung nicht vergeben ist, dann sollten die Felder weg genommen werden. Sobald man eine Kategorie wählt, in der die Berechtigungen erlaubt ist, sollten die Felder angezeigt werden. So wäre das ja richtig.

Zitat von Harmageddon

Wo wird bei dir denn die Seite neu geladen?

Ja - im Frontend. Das wird durch das JS-Funktion "categoryHasChanged" ausgelöst.

Harmageddon

Mittlerweile bin ich etwas verwirrt. Reden wir über J3 oder J4? In Version 4 hast du Recht, da müsste man den entsprechenden Check in die Methode ArticleModel::getForm (administrator/components/com_content/src/Model/ArticleModel.php) einbauen. Das müsste dann auch mit dem Nachladen funktionieren. In Version 3 wird da bei mir nichts neu geladen bei der Kategorieauswahl. categoryHasChanged finde ich dort auch nur in der Custom-Fields-Komponente.

Sorry für die sporadischen Antworten meinerseits hier. Habe aktuell unter der Woche relativ wenig Zeit und will vor einer Antwort aber das Problem erst ausführlich selbst bei mir nachstellen, damit ich dir keinen Unsinn erzähle.

LukasHH

Ursprünglich ging es um J3. Als ich damals meine Anleitung dazu geschrieben hatte, ging das in J3. Nach irgendeinem Update danach ging es nicht mehr. Ist mir selbst aber nicht weiter aufgefallen. Da J4 bald kommt, sollte man den Fokus auf J4 setzen. Wenn man damit das Problem in den letzten Versionen von J3 auch mit erledigen kann, könnte man das dann ggf. mit aufnehmen.

christine2

Hallo,

Gibt hier wohl 2 PRs:

Joomla 3: https://issues.joomla.org/tracker/joomla-cms/32470

Joomla 4: https://issues.joomla.org/tracker/joomla-cms/32468

Liebe Grüße

Christine