Adminmenü für PM-Modul

[GerhardSt]

Hallo, es wurde hier der Wunsch gepostet ein Adminmenü für das PM-Modul zu erstellen.
Was gehört eurer Meinung da alles rein?
Ich habe im Moment eigentlich nur eins gefunden, das währe eine Einstellmöglichkeit für die PM-Begrenzung.

Wer hat soetwas in der Art schon gemacht und würde dies für das PM-Modul coden?

[JoergK]

Also, IMHO gehört alles, was administrativ (vor)einstellbar ist, sollte über ein Adminmenü einstellbar sein. Somit bräuchte man nicht mehr in irgendwelche Dateien direkt eingreifen und diese (jedesmal) neu hochladen.

Also am optimalsten alles aus der config.php, ausgenommen der Spracheauswahl am Ende:

• HTML erlauben? Ja/Nein
• BB-Code erlauben? Ja/Nein
• Dürfen ungelesene Nachrichteh gelöscht werden? Ja/Nein
• Standard-Icon für den Betreff: [Auswahlliste]
• Refresh-Zeit für die Nachrichtenliste: [Eingabefeld] (in Sekunden)
• Icon Verzeichnis: [Eingabefeld]
• Smilie Verzeichnis: [Eingabefeld]
• Bilder Verzeichnis: [Eingabefeld]
• Smilie 1 (bis 9): [Eingabefeld] (Smilie-Code) [Eingabefeld] (Smilie-Name/Text) [Eingabefeld] (Dateiname)
  {Für den Dateinamen evtl. ne Auswahlliste}
• Smilies im Messanger verwenden? Ja/Nein
• Breite des PopUp-Fensters [Eingabefeld] (in Pixel)
• Rahmen um PopUp? Ja/Nein
• Breite des Nachrichten-PopUp: [Eingabefeld] (in Pixel)
• Höhe des Nachrichten-PopUp: [Eingabefeld] (in Pixel)

Dann natürlich auch noch die neuen Parameter aus der inboxsize-conf.php:

• Max. Anzahl PMs im Posteingang: [Eingabefeld] (Für "normale" User)
• Max. Anzahl PMs im Postausgang: [Eingabefeld] (Für "normale" User)
• Spezialuser = Usergruppe: [Auswahlliste]
• Max. Anzahl PMs im Posteingang: [Eingabefeld] (Für "spezielle" User)
• Max. Anzahl PMs im Postausgang: [Eingabefeld] (Für "spezielle" User)

Dann schmeiss ich noch zusätzlich das in den Raum:

• Rechte Blöcke anzeigen? Ja/Nein

Mal seh'n, was die anderen noch für Ideen haben. 

Wenn die Entscheidung gefallen ist, ob es ein Adminmenü geben und was letztlich darin alles einstellbar sein soll, bin ich bereit, das Teil zu coden.

[Future]

Moin,

Vielleicht sollte man auch noch den Willkommens Text über Admin Menü Editierbar mchen. So müsste man nicht mehr in die Datei eingreifen. Desweiteren sollte man den "Standard Willkommens Nachricht versender" auch aus der (ich glaube Benutzer Config) rüberholen in das Admin Menü des PM Moduls. Vielleicht sollte man auch noch auswählen können ob das für Admins (nicht SuperAdmins) auch zählt.

Kurz zusammen gefasst.

• Sende Willkommensnachricht? JA/NEIN
• Wilkommens Text TEXTAREA
• Standard Sprache für Willkommensnachricht [Auswahlliste]
• Willkommens Nachricht versender [Auswahlliste]
• Zählt die Begrenzung auch für Admins? JA/NEIN

[David555]

Ich würde dann noch vorschlagen:

• PM- Limit Ja/Nein
• Wie viel PM- Nachrichten auf einer Seite

Die 60 Sekunden in den Einstellungen im Admin- Bereich vielleicht dann hier reinpacken.
Also das:

Private Nachrichten der Benutzer regelmässig abfragen:

[GerhardSt]

Hi, hier hat sich ja einiges angesammelt!

Erst einmal ein danke an JoergK, das du dich bereit erklärt hast das Adminmenü zu coden

Noch ein kleiner Hinweis zur PM-Begrenzung den man vielleicht nicht übersehen sollte, man könnte für jede Benutzergruppe eine extra Begrenzung wählen. Ich weiß zwar nicht ob das wer braucht, aber man sollte das im Adminmenü berücksichtigen.

Für einige Funktionen die hier angeführt sind, müssen wir das PM-Modul noch ein wenig umcoden, da diese Funktionen noch nicht vorgesehen waren.
z.B.     * PM-Limit Ja/Nein
    * Wie viel PM-Nachrichten auf einer Seite (dazu müssten wir noch eine Umblätterfunktion einbauen)
    * Zählt die Begrenzung auch für Admins? JA/NEIN

Ein paar Funktionen sind zum Teil schon in anderen Adminmenüs vorhanden, z.B.
   * Sende Willkommensnachricht? JA/NEIN
   * Standard Sprache für Willkommensnachricht [Auswahlliste]
   * Willkommens Nachricht versender [Auswahlliste]
Bei diesen stellt sich die Frage, ob wir diese nicht dort lassen wo sie jetzt sind oder dort total rausnehmen. Den doppelte Einstellmöglichkeiten sorgen sicher nur für Fehler.

[wiederalleine]

Nettes Hallo an Euch ....

... kann Euch leider nicht bei der Umsetzung helfen, aber vielleicht interessiert Euch die Anregung, per Adminmenü PN`s, die beispielsweise älter als xx Tage sind, durch einen Superadmin löschen zu können.

Viele Grüße

Peter

[Future]

Ein paar Funktionen sind zum Teil schon in anderen Adminmenüs vorhanden, z.B.
   * Sende Willkommensnachricht? JA/NEIN
   * Standard Sprache für Willkommensnachricht [Auswahlliste]
   * Willkommens Nachricht versender [Auswahlliste]
Bei diesen stellt sich die Frage, ob wir diese nicht dort lassen wo sie jetzt sind oder dort total rausnehmen. Den doppelte Einstellmöglichkeiten sorgen sicher nur für Fehler.

Würde ic hdann aber eher aus der BenutzerConfig rausnehmen und ins Admin PM reinpacken, damit man nicht an 2 verschiedenen stellen sachen fürs PM einstellen kann. Aus der Benutzerconfig sollte man es dann natürlich rausnehmen.

[JoergK]

• Sende Willkommensnachricht? JA/NEIN
• Standard Sprache für Willkommensnachricht [Auswahlliste]
• Willkommens Nachricht versender [Auswahlliste]

Die 60 Sekunden in den Einstellungen im Admin- Bereich vielleicht dann hier reinpacken.
Also das:

Private Nachrichten der Benutzer regelmässig abfragen:

Bei diesen stellt sich die Frage, ob wir diese nicht dort lassen wo sie jetzt sind oder dort total rausnehmen. Den doppelte Einstellmöglichkeiten sorgen sicher nur für Fehler.

Also ich wäre dafür, diese Einstellungen in der Benutzerkonfig bzw. den Site-Settings zu belassen und zwar aus zwei Gründen:

• Diese Einstellungen konfigurieren nicht das PM-Modul selbst, sondern dessen Nutzung.
• Je mehr Dateien (hier /admin/userconfig.php, /admin/settings.php, /modules/User_Registration/index.php, /modules/Your_Accont/config.php und /config.php) ausserhalb des eigentlichen PM-Moduls verändert werden, desto aufwendiger und schwieriger wird's für die Nutzer des Extention-Moduls, dies zu implementieren. Zusätzlich ist zu berücksichtigen, dass bei möglichen Updates die genannten Dateien immer wieder neu angepast werden müssten, was IMHO einen unnötigen Aufwand für uns und/oder die Nutzer bedeuten würde.

• Wilkommens Text TEXTAREA

Das wäre wiederum ein Eingriff ein Modul ausserhalb des PM-Moduls (/modules/User_Registration/language/hello-*.php). Desweiteren ist hier zu berücksichtigen, dass es mehrere Sprachdateien gibt, die alle zur Bearbeitung aufgegriffen werden müssten. Wenn überhaupt, dann wäre eine seperate Extension der Benutzerkonfig der bessere Weg.

Noch ein kleiner Hinweis zur PM-Begrenzung den man vielleicht nicht übersehen sollte, man könnte für jede Benutzergruppe eine extra Begrenzung wählen. Ich weiß zwar nicht ob das wer braucht, aber man sollte das im Adminmenü berücksichtigen.

Woher soll man denn im Vorfeld wissen, wieviele Gruppen es gibt? Es ist sicherlich möglich, beim Aufruf der Konfig die aktuell existierenden Gruppen aus der DB auszulesen und entsprechende Eingabemöglichkeiten zu generieren. Auch eine, bei jeder neuen Gruppe, vergrösserte config.php zu erzeugen ist nicht wirklich das Problem. Beim Anlegen einer neuen Gruppe muss der jeweilige Admin dann "nur" dran denken, im Anschluss die PM-Konfig aufzurufen und ein neues/zusätzliches Limit anzulegen. Hier könnte man natürlich einen Hinweis in die Gruppenkonfig einbauen, was allerdings wieder eine Änderung an "Fremddateien" (/admin/groups.php und /admin/language/lang-*.php) zur Folge hätte.

Für einige Funktionen die hier angeführt sind, müssen wir das PM-Modul noch ein wenig umcoden, da diese Funktionen noch nicht vorgesehen waren.
z.B.     * PM-Limit Ja/Nein

Hier würde ich folgende Auswertung vorschlagen:

• Wenn der Wert = 0, dann kein Limit
• Wenn der Wert > 0, dann ist der Wert das Limit

Somit bräuchte man keine zusätzliche Konfig-Einstellung dafür. 

    * Zählt die Begrenzung auch für Admins? JA/NEIN

Das sollte das kleinte Prob in der Umsetzung sein, oder? 
Wäre zu entscheiden, ob's nur den GOD-Admin betrifft [if (radminsuper == 1)] oder alle Admins [if (MX_IS_ADMIN)].

    * Wie viel PM-Nachrichten auf einer Seite (dazu müssten wir noch eine Umblätterfunktion einbauen)

Das ist wohl etwas aufwendiger, aber natürlich nicht unmöglich. Bin allerding der Ansicht, wenn ich mir die bisherigen Limits von mehreren 100 PM so ansehe, dass das auf jeden Fall umgesetzt werden sollte. Eine Vorlage zu einer seitenweise Auflistung ist ja im Modul Members_List zu finden.

... aber vielleicht interessiert Euch die Anregung, per Adminmenü PN`s, die beispielsweise älter als xx Tage sind, durch einen Superadmin löschen zu können.

Dazu sind ja die Limits da. Wenn die erreicht sind, muss der User halt selbst entscheiden, welche PMs er löscht, um weitere neue speichern zu können. Ne Löschung per Superadmin würde IMHO möglicherweise soger einen unzulässigen Eingriff in die Privatsphäre des betroffenen Users darstellen.



Noch eins zu den Limits im Allgemeinen:
Irgendwo sollte es ein (hard-coded) globales maximales Limit geben (z.B. 500, 1000 ?). Weil irgendwann wird die Datenbank "gesprengt" und die Schreie "Meine DB funzt nicht mehr - was soll ich machen?" werden uns verstärkt "verfolgen". 
Desweiteren würde ich die Limits für Ein- und Ausgang nicht separieren sondern nur deren Summe begrenzen. In wie weit sich das auf den bisherigen Code auswirken würde, müsste Gerhard mal prüfen. 

[GerhardSt]

Noch eins zu den Limits im Allgemeinen:
Irgendwo sollte es ein (hard-coded) globales maximales Limit geben (z.B. 500, 1000 ?). Weil irgendwann wird die Datenbank "gesprengt" und die Schreie "Meine DB funzt nicht mehr - was soll ich machen?" werden uns verstärkt "verfolgen". 
Desweiteren würde ich die Limits für Ein- und Ausgang nicht separieren sondern nur deren Summe begrenzen. In wie weit sich das auf den bisherigen Code auswirken würde, müsste Gerhard mal prüfen. 

Danke JoergK!
Ich habe gerade mal versucht die Änderungen 0 = unbegrenzt einzubauen, mehr dazu hier!
Um deine vorgeschlagenen Änderungen umzusetzen, müsste man nur ein paar Zeilen in der index.php und in der buddy.php ändern.
Nur brauchen wir das wirklich?
Wer so hohe Begrenzungen eingibt, finde ich ist selber Schuld, wenn die Datenbank streikt.
Zu deinem Vorschlag die Limits nur als Summe zu begrenzen, ist zwar super für die, die keinen Postausgang brauchen. Aber gibts dann nicht Probleme mit der Überlastung für den Eingang?
Und was machen wir dann mit unserem Zähler?

[JoergK]

Wer so hohe Begrenzungen eingibt, finde ich ist selber Schuld, wenn die Datenbank streikt.

Hast natürlich in soweit Recht, als das der jeweilige Admin wissen sollte, was er (sich an)tut. 

Zu deinem Vorschlag die Limits nur als Summe zu begrenzen, ist zwar super für die, die keinen Postausgang brauchen. Aber gibts dann nicht Probleme mit der Überlastung für den Eingang?
Und was machen wir dann mit unserem Zähler?

Wieso sollte der Posteingang überlastet werden? Wenn z.B. in der Summe max. 200 PMs gespeichert werden können, und jemand hat 100 PMs im Postausgang, dann passen halt nur noch max. 100 in den Posteingang.

Zum Zähler kann ich nix sagen, da ich die PM-Erweiterung (noch) nicht zum Testen eingespielt habe.

Im Nachhinein betrachtet sind getrennte Einstellungen wohl doch der bessere Weg, denn es steht ansonsten zu befürchten, dass viele Enduser es nicht checken.

[GerhardSt]

Wieso sollte der Posteingang überlastet werden? Wenn z.B. in der Summe max. 200 PMs gespeichert werden können, und jemand hat 100 PMs im Postausgang, dann passen halt nur noch max. 100 in den Posteingang.

Ich dachte nur, sind ja immerhin zwei getrennte Tabellen. Aber da ich noch nie mit der Datenbank Probleme hatte, kenne ich mich da noch nicht so recht aus.

[GerhardSt]

Hi JoergK,
ich hätte da noch einen wichtigen Punkt, der meiner Meinung auch ins Adminmenü gehört.
Eine Überprüfung ob alle Tabellen bzw. Zeilen in der Datenbank vorhanden sind und falls nicht das man diese vielleicht gleich erstellen kann.

[JoergK]

ich hätte da noch einen wichtigen Punkt, der meiner Meinung auch ins Adminmenü gehört.
Eine Überprüfung ob alle Tabellen bzw. Zeilen in der Datenbank vorhanden sind und falls nicht das man diese vielleicht gleich erstellen kann.

Gute Idee , wobei man das vielleicht besser als install.php dem Paket beilegt. Denn wenn einmal alle Tabellen angelegt sind, ist es (eigentlich) unnötig, bei jedem Aufruf des PM-Adminmenüs eine Überprüfung durchzuführen und somit zusätzliche DB-Abfragen und Serverlasten zu erzeugen. 

[GerhardSt]

Hi JoergK,

Woher soll man denn im Vorfeld wissen, wieviele Gruppen es gibt? Es ist sicherlich möglich, beim Aufruf der Konfig die aktuell existierenden Gruppen aus der DB auszulesen und entsprechende Eingabemöglichkeiten zu generieren. Auch eine, bei jeder neuen Gruppe, vergrösserte config.php zu erzeugen ist nicht wirklich das Problem. Beim Anlegen einer neuen Gruppe muss der jeweilige Admin dann "nur" dran denken, im Anschluss die PM-Konfig aufzurufen und ein neues/zusätzliches Limit anzulegen. Hier könnte man natürlich einen Hinweis in die Gruppenkonfig einbauen, was allerdings wieder eine Änderung an "Fremddateien" (/admin/groups.php und /admin/language/lang-*.php) zur Folge hätte.

Was hällst du von dem Vorschlag, ein Feld für Sonstige oder Neue-Gruppen ins Adminmenü einzufügen. Müsste eigentlich kein Problem sein, da im Moment ja auch nur die Gruppe die in der if-Schleife ist eine andere Begrenzung hat, für alle anderen gilt die andere.

Zu der Datenbanküberlastung: Man könnte, ein Hinweisfeld dazu ins Adminmenü einbauen und wer das nicht beachtet, kann sich nachher auch nicht beschweren.

[JoergK]

Was hällst du von dem Vorschlag, ein Feld für Sonstige oder Neue-Gruppen ins Adminmenü einzufügen. Müsste eigentlich kein Problem sein, da im Moment ja auch nur die Gruppe die in der if-Schleife ist eine andere Begrenzung hat, für alle anderen gilt die andere.

Wie gesagt, möglich ist fast alles. 
Mein Einwand bzw. Gedankengang bedeutete ja keine Ablehnung des Vorschlags, sondern sollte nur auf die mögliche Problematik hinweisen, dass nen Admin vergisst, nen neues Limit anzugeben.

Wenn ich Dich richtig verstehe, dann willst Du in Deinem Code checken, ob für die Gruppe des aktuellen Users ein seperates Limit existiert und wenn dem nicht so ist, dann bekommt er das Standard-Limit verpasst.

Wenn dem so ist, dann braucht's keine Limit-Einstellung für "Sonstige". Wie in meinem Thread erwähnt, ist die "automatische" Erweiterung des Adminmenüs um ne neue Gruppeneinstellung nicht wirklich ein Problem.

Zu der Datenbanküberlastung: Man könnte, ein Hinweisfeld dazu ins Adminmenü einbauen und wer das nicht beachtet, kann sich nachher auch nicht beschweren.

Ach so, du hast quasi an nen Button "Datenbank überprüfen" (oder so ähnlich) gedacht. Das hatte ich so nicht nicht gesehen. 
In dem Fall spricht natürlich nichts gegen den Featurewunsch. 

[GerhardSt]

Hallo JoergK,

die letzten Änderungen für´s Adminmenü, habe ich gerade hochgeladen.
Dürfte eigentlich nicht´s mehr fehlen oder?

Ich hoffe dein Angebot für´s Coden des Adminmenü´s steht noch

[JoergK]

Hi Gerhard,

aber klar steht mein Angebot noch und ich habe bereits damit begonnen.
Um Dir und den anderen den Mund schon mal etwas wässrig zu machen, hier ne erste Preview:

• Die derzeitige Anzeige der Verzeichnisse wird noch in entsprechende Auswahllisten umgebaut.
  Mein Ziel ist letztendlich, dass ein Admin ausschliesslich mittels Auswahlen
  (Select-Listen / Radio-Buttons) die Einstellungen vornehmen kann, um Tippfehler auszuschliessen. 
  
  
• Bei den Begrenzungen werden für Gruppen, für die noch keine eigenen Begrenzungen existieren, werden Standardwerte vorgeschlagen.

Selbstverständlich gibt es gleich Sprachdateien für die 3(4) Standardsprachen: german (german_du), english & french (Wordlingo sei dank  )

Ich denke, dass ich am Wochenende um einige Schritte voran komme und in dem Zuge auch Deine letzte (?) Änderung bezüglich der seitenweise Anzeige integriere.

[GerhardSt]

Hi JoergK,

schaut super aus

Zum Thema Sprachdateien: Die Erweiterungen von mir sind bis jetzt nur german und german_du, währe natürlich super wenn diese Varriablen auch noch übersetzt werden.