"Eigene Einstellungen" anzeigen im Backend

[search1]

Hallo zusammen,

wir haben Serendipity als CMS laufen. Die geringste Berechtigungsstufe "intern" erlaubt dabei den Zugang zum internen Bereich. Bei diesen Nutzern gelingt es mir nicht, dass sie im Backend den Menüpunkt "Eigene Einstellungen" angezeigt bekommen. Diese Nutzer sollen ihr Passwort ändern können...
Bei der Gruppenverwaltung ist bei dieser Nutzergruppe nichts angehakt, außer: "personalConfiguration: Zugriff auf Persönliche Einstellungen". Bei den einzelnen Nutzern ist jeweils mit "ja" bestimmt: "Benutzer deaktivieren / Rechte entziehen? ". Aber hier steht in der Erklärung ausdrücklich, dass damit nicht die "Eigenen Einstellungen" entzogen werden.
Ereignisse oder Plugins wurden keine verboten.
Was mache ich falsch?

Schonmal DANKE!

[garvinhicking]

Hi!

Welche Serendipity-Version nutzt du, und welches Template?

Denn eigentlich ist es richtig, die User müssen nur "personalConfiguration" als Recht haben, dann sollten sie es sehen können. Was konkret sehen die User denn bei Dir im Backend (Screensho?)

Grüße,
Garvin

[search1]

Hi Garvin,

danke für Deine Hilfe.
Es handelt sich um das Serendipity, das yellowled programmiert hat: monte-muenchen.de !
Die Nutzergruppe sieht im Backend nur die Menüpunkte: "Startseite", "Zurück zum Blog" und "Abmelden". Es handelt sich um Serendipity 1.4.1 und PHP 5.2.9.

Liebe Grüße

[yellowled]

Es handelt sich um das Serendipity, das yellowled programmiert hat: monte-muenchen.de

*schmunzel* Es handelt sich um ein individuelles Template ohne Backend-Gestaltung. Das verwendete Backend-Template ist also das BP-admin.

Ich habe das gerade mal mit einem Testbenutzer ausprobiert -- in der Tat sieht so ein Benutzer nur die Backend-Links "Startseite", "Zurück zum Blog" und "Abmelden", obwohl "personalConfiguration" für diese Gruppe gesetzt ist.

YL

[garvinhicking]

Hi!

Evtl. mal das "normale" serendipity-Default einsetzen und gucken ob das was ändert?

Es könnte sein dass das mit dem "no_create" doch irgendwie abhängt, mir fehlt hier aber leider die Zeit eine Testumgebung derart einzurichten. Klappt es denn, wenn "Benutzer deaktivieren" nicht angestellt wird? Evtl. überschreibt diese Recht nämlich alle anderen Rechteabfragen und liefert somit immer "nein" egal welches Recht geprüft wird.

Grüße,
Garvin

[garvinhicking]

Hi!

....ja, so ist es.

Sobald "no_create" gesetzt wird, gibt Serendipity bei JEDEM Recht ein "Nein" zurück, um sicherzustellen dass ein Benutzer dann wirklich garnix darf.

Grüße,
Garvin

[yellowled]

Klappt es denn, wenn "Benutzer deaktivieren" nicht angestellt wird? Evtl. überschreibt diese Recht nämlich alle anderen Rechteabfragen und liefert somit immer "nein" egal welches Recht geprüft wird.

Bingo. Ich habe das gerade beim von mir angelegten Testbenutzer geändert -- damit sieht dieser dann auch seine "Eigene Einstellungen".

Oh je. Gibt es eine simple Lösung, diese Option für alle Benutzer, die dieser Gruppe angehören (oder für alle, bei denen die Option gesetzt ist?), über die DB zu ändern? Das System hat derzeit ca. 290 registrierte Nutzer -- keine Ahnung, wieviele dieser Gruppe angehören, aber es dürfte der Löwenanteil sein. Das möchte man nicht manuell ändern müssen ...

YL

[garvinhicking]

Hi!

Ich steck da gerade nich so drin, wofür wird das "no_create" bei euch denn benutzt? Normalerweise benutzt man das ja nur für Leute, die sich nur zum Kommentieren einloggen kommen dürfen.

Wenn ihr sicher seid, dass das Entfernen keine Nachteiligen Effekte haben wird:

DELETE FROM serendipity_config WHERE name = 'no_create';

oder:

UPDATE serendipity_config SET value = 'false' WHERE name = 'no_create';

Grüße,
Garvin

[yellowled]

Ich steck da gerade nich so drin, wofür wird das "no_create" bei euch denn benutzt? Normalerweise benutzt man das ja nur für Leute, die sich nur zum Kommentieren einloggen kommen dürfen.

Die Seite besteht zum großen Teil aus einem "internen" Bereich, der nur eingeloggten Nutzern angezeigt wird (via $is_logged_in).

Es gibt also eine (relativ große) Benutzergruppe, die sich zwar nicht zum kommentieren einloggen müsste (soweit ich das erinnere; ich betreue die Seite nicht mehr wirklich aktiv, das hat search1 übernommen), sondern um die entsprechenden Inhalte überhaupt angezeigt zu bekommen. Diese Gruppe sind aber reine "Besucher", keine Redakteure.

Mir war beim Anlegen der Berechtigungen schlicht nicht bewusst, dass no_create auch die eigenen Einstellungen "sperrt", ansonsten erinnere ich keinen ausdrücklichen Grund dafür, es zu zu setzen.

YL

[search1]

...kann auch die 260 von Hand umstellen. Was ich aber nicht gefunden habe, ist das Ausblenden der "Voreinstellungen für neue Einträge" bei dieser Benutzergruppe. Gibt es hier ein "Verbotenes Ereignis", das ich einstellen kann und nur nicht finde?
Schon mal danke

[yellowled]

...kann auch die 260 von Hand umstellen.

Muss ja aber nicht sein mit den entsprechenden SQL-Befehlen! (Meinjanur.)

Was ich aber nicht gefunden habe, ist das Ausblenden der "Voreinstellungen für neue Einträge" bei dieser Benutzergruppe. Gibt es hier ein "Verbotenes Ereignis", das ich einstellen kann und nur nicht finde?

Ich hab das jetzt dreimal gelesen und trotzdem keinen Schimmer, was gemeint sein könnte. Mag an der vorgerückten Stunde liegen. Ausblenden? Wozu? Verstehe ich nicht ...

YL

[search1]

Die Normalen 260 von 280 Nutzern sind nur zum Betrachten für den internen Bereich angemeldet. Diese sind überfordert, wenn sie in den Eigenen Einstellungen Voreinstellungen für neue Einträge vorfinden. Sie verstehen das nicht, da sie nur ihr Passwort ändern wollen und ja gar keine Einträge erstellen können. Um diese Verwirrung zu umgehen und alles so einfach wie möglich zu halten, sollen für diese Benutzergruppe von den Eigenen Einstellungen nur der erste Teil: "Persönliche Einstellungen" zu sehen sein.

[garvinhicking]

Hi!

Dann musst du den 20 Benutzern separat das "no_create" auf "false" stellen bzw entfernen, ja.

Grüße,
Garvin

[yellowled]

Dann musst du den 20 Benutzern separat das "no_create" auf "false" stellen bzw entfernen, ja.

Öh? Soweit ich das verstanden habe, ermöglich doch „no_create“ erst die Anzeige der „Eigenen Einstellungen“, innerhalb derer verschiedene Einstellungen angezeigt werden, welche die Benutzer hier überfordern?

Eine Einstellungsseite, auf der man nur das PW ändern kann, gibt es meines Wissens nicht.

YL

[search1]

Na ja, nur das Passwort muss nicht sein, aber "no_create" (Eigenen Einstellungen) besteht aus zwei Teilen: "Persönliche Einstellungen" und "Voreinstellungen für neue Einträge". Meine Frage war, ob nur der erste Teil, die "Persönlichen Einstellungen" angezeigt werden können, etwa durch die Definition eines "Verbotenes Ereignis" für diese größte Benutzergruppe.