[quote=Strat,05.08.2006, 16:10]zu pb_overview-initialisierung: habe gerade was in install/cleanupDB.pl gecoded und auf dem server ausgefuehrt und auf sourceforge hochgeladen.[/quote]
hmm, es gibt in DB.pm schon eine funktion UpdateOverview.
die kann man einfach benutzen, dann hat man das nicht an zwei
stellen. außerdem hab ich mir dann die ganze mühe mit der
abstraktion umsonst gemacht.

habe das mal abgeändert.

ich hoffe, dass ich bald ein translation-plugin für HTC fertig habe.
dann könnten wir das board mal übersetzen. englisch wär schon
ziemlich gut.

englische buttons bräuchten wir dann allerdings auch.\n\n

<!--EDIT|pq|1154991603-->

was haltet ihr davon, wenn man die moderatoren etwas entlastet (ich denke dabei an boards, die nicht so entspannt laufen wie unseres) und das anonyme posten erlaubt, aber dann usern gestattet zu sagen "ist spam" oder so. zB wenn ein registrierter user mit mehr als 50 posts sagt "spam", dann wird es automatisch ausgeblendet und ein mod muss es freischalten oder so. damit hätte man quasi so ein "alles ist ok, solange sich niemand dran stört"-verhalten. gerade bei größeren boards könnte das sonst für die moderatoren irgendwann nervig werden (und es ist ja nicht immer einer da, es sei denn man hat so ein wunderbares moderatoren-zu-user-verhältnis).

jan, das ist eine gute idee. hatte auch schon daran gedacht, dass
funktionen wie bei perlmonks sinnvoll sein könnten.
andererseits kann ein link auf eine pornoseite schon rechtliche
konsequenzen haben, habe ich mir sagen lassen.
ich wollte jetzt erstmal einbauen, dass moderatoren oben immer ein
feld angezeigt bekommen, in dem steht "x nicht freigegene posts".
vielleicht könnte man auch noch eine neue gruppe einführen,
die zwischen gast und moderator ist. das wären dann vertrauenswürdige
user, die halt nicht moderieren, aber die einen thread freischalten
können *.
zusätzlich noch ein feld in der db "approved_by" mit der userid, um
approvals im nachhinein checken zu können.

dann hätte man sozusagen das prinzip einer whitelist anstatt einer
blacklist (also explizit zulassen anstatt explizit ausschließen),
aber mit genug usern in dieser gruppe ist die wartezeit fürs approven
dann kurz genug (im schnitt), dass es aktzeptabel ist.

das mit dem "user mit > 50 posts dürfen etwas als spam markieren"
ist zwar auch eine gute methode, aber ich denke, dass sie etwas
schwerer umzusetzen ist (mehr code, mehr zusätzliche datenbankfelder).

was denken die anderen so?

*) eine neue gruppe würde auch zum konzept von strat passen, gruppen
und berechtigungen auszubauen.\n\n

<!--EDIT|pq|1154994714-->

thema css: ich finde das default.css viel zu kompliziert.
auf der overview-seite gibt es 5 spalten, und jede hat ihre
eigene css-klasse (forum1, forum2...forum5).
ich frage mich, ob es wirklich notwendig ist, dass die alle
unterschiedlich sind. und wenn ja, kann man das nicht zusammenfassen?
in etwa:

mit opera funktioniert das jedenfalls prima.

thema schema-änderungen:
wie wäre es, wenn jeder, der schema-änderungen macht,
außerdem noch ein release.sql beifügt, das die notwendigen
ALTER TABLE macht (wenn möglich).
dann braucht man nicht immer seine testdaten zu löschen.

edit: das wäre spätestens nach dem ersten offiziellen release sowieso
notwendig, um bei schema-änderungen das update auf die neue version
zu ermöglichen.\n\n

<!--EDIT|pq|1154999874-->

Das mit der zusätzlichen Gruppe halte ich für eine gute Idee. Außerdem hat man dann einen besseren Einfluss darauf, wer denn Posts freigeben darf. Bei einer Post-abhängigen Grenze hat man den Effekt, dass Leute, die eine sehr angeregte Diskussion führen ruckzuck über dieser Grenze sind, obwohl sie vielleicht erst zwei Tag im Forum Mitglied sind.

die zusaetzliche gruppe gefaellt mir gut; poweruser ab 100 Beitraegen?

DB-Update: das macht sinn; da sollten wir aber dann Versionen vergeben, damit man sagen kann: updateDb_0.05_0.06.sql oder so\n\n

<!--EDIT|Strat|1155040927-->

hmm, poweruser klingt so nach powerseller. :-/
ein besserer name fällt mir aber auch nicht ein.
ich denke, man könnte es so machen, dass man vom 99. zum 100.
post poweruser wird und die gruppe geändert wird. so kann man
jemanden manuell auch wieder zurückstufen, falls das wirklich
notwendig sein sollte.

wir haben aber immer noch das problem mit Gast-antworten. momentan
gibt es den status onhold nur für threads.
wenn wir das für antworten auch so machen (mit einem neuen
status), würden antworten erst erscheinen, wenn sie approved
werden. die frage ist dann, an welcher stelle im thread sie erscheinen.
könnte evtl. verwirrend sein, wenn die plötzlich vor anderen
postings auftauchen, obwohl sie erst danach approved werden.
interessant finde ich: bei perlmonks kann ja jeder posten, was er will.
approved werden müssen nur threads. aber scheinbar wird
perlmonks nicht von spammern heimgesucht. wie machen die das?

[quote=Strat,08.08.2006, 14:40]DB-Update: das macht sinn; da sollten wir aber dann Versionen vergeben, damit man sagen kann: updateDb_0.05_0.06.sql oder so[/quote]
habe jetzt ein release_r130.sql hinzugefügt, also für die revision.
bei großen updates macht natürlich die $VERSION mehr sinn.