es wird Zeit, dass wir mit dem programmieren anfangen; Das Hauptziel sollte sein, den demokratie-mod zu machen.
Ich schlage vor, wir fangen mal mit den Datenstrukturen an; Wir brauchen auf jeden Fall eine Datenstruktur fr jemand, der irgendein
Amt hat (sei es gewhler Moderator, oder was sonst noch so kommen mag) und natrlich eine Datenstruktur fr den Whler.
Ich wrde sagen wir implementieren Strukturen als Tabellen in der Datenbank und kapseln die Datenbank ber PHP-Klassen (z.B. wrde
es sich anbieten, mal irgendeine abstrakte Klasse fr Amtsinhaber machen wrden. Da knnten wir dann munter von ableiten.
Ich wrde sagen, die Sprache in der wir kommentieren und unsere Variablen benennen ist Englisch. Wir wollen ja ein internationales
Projekt sein...
Das sollte die Amtsinhaber-Tabelle haben:
+eine Variable, die angibt was fr ein Amt die Person hat;
wahrscheinlich werden wir da Source-Code wie z.B. hier nehmen:
********************
define(FOO,1);
define(BAR,2);
[...]
if($c->i == BAR){
aha, er ist also ein BAR
}
********************
+die user_id aus phpbb_users (ist klar)
+Eine Amtsinhaber-ID (ist der key der Tabelle)
+ein paar relativ abstrakte Datenfelder, die wir dann je nach Amt verschieden fllen (um das zu verstecken sind ja Objekt gut)
Sonst noch was ?
Dann brauchen wir noch eine Tabelle fr die Wahlberechtigten (phpbb_users knnten wir zwar modifizieren und auch dafr nehmen, das
sollten wir aber nicht machen, weil sicherlich nicht alle User auch wahlberechtigt sind. Auerdem sind wir dann aufwrtskompartibler)
Die Tablle solle folgendes haben
+ Klasse des Users
+ die user_id aus phpbb_users
Sonst noch was ?
Sollen wir auch phpbb_users erweitern ? Nen Platz fr den wirklichen Namen habe ich nicht gesehen, der muss schon rein wrde ich sagen. Oder machen wir da ne eigene Tabelle fr ?
Phpbb untersttzt schon ein System fr polls.
Nachteil: wir mssen aufpassen, nicht Namespace-Probleme zu bekommen.
Vorteil: Wir haben schon was, was wir nehmen knnen. Hat sich schon jemand den Code dafr nher angeschaut. Was meint ihr ?
Bis denn
MaJo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich hab mir die Polls zwar noch nicht angeschaut, aber ich denk, wir sollten es nutzen, wenn schon was da ist.
Was wir noch ndern mssen:
Das Ergebnis sollte wohl allen erst zum Abschluss der Wahl offiziell bekannt werden.
Wie machen wir das dann mit den Rechten?
Vorschlge:
Wir setzen nach jeder Wahl die Rechte in der Datenbank.
Oder wir manipulieren die includes/auth.php.
Wobei ich dafr wre, dass ein Moderator nur die
Beitrge ndern darf, die in seiner Legislaturperiode geschrieben wurden.Oder?
Soll es denn mglich sein, mehrere mter gleichzeitig innezuhaben? So siehts dein Tabellenentwurf ja vor.
dann wre folgendes praktisch (aus dem obigen Beispiel):
*********************
if($c->isAmt(BAR))
{
//aha, er ist also (u.a.) ein BAR
}
*********************
Gre Thomas
P.S: ich bin grad in der Klausurenzeit. Daher halt ich mich ein bisschen zurck, wie ihr sicher schon gemerkt habt ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Wobei ich dafr wre, dass ein Moderator nur >die Beitrge ndern darf, die in seiner >Legislaturperiode geschrieben wurden.Oder?
Bin ich auf dafr
>P.S: ich bin grad in der Klausurenzeit. Daher >halt ich mich ein bisschen zurck, wie ihr >sicher schon gemerkt habt ;-)
Ich bin grad in der Abi-Zeit: das gleiche gilt fr mich...
>Soll es denn mglich sein, mehrere mter >gleichzeitig innezuhaben? So siehts dein >Tabellenentwurf ja vor.
Prinzipiell ja, aber es sollte mter geben, die nicht kombinierbar sind (leuchtet ein)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Leute
Let this discussion be in english further on, ok ?
I think we should let all our tables start with democ4phpbb_
The code we produce should be located in phpBB2/democ4phpbb/
Here's a suggestion for the table for the abstract minister class about like this:
CREATE TABLE democ4phpbb_minister (
int user_id,
int minister_id,
text_array data,
);
(I know that it is no valid sql syntax ;-) ).
the text_arry will contain a string describing the options of a certain minister, e.g. when he entered his office, what his rights are...
Pro: We are abstract and thus flexible enough to make ministers apart from the tribunes (so could we call the moderators) like e.g. judges, WITHOUT inheriting this class (we dont need interitance at all).
Con: We will not be able to make database-queries like $sql->query("all-ministers-who-have-that-and-that"), we would have to grep a array of all ministers and query e.g. like this:
for ($i=0;isset($ministers[$i]);$i++){
if($ministers[$i]->foo() == BAR){
...
}
}
We program a class around this table
class minister{
//returns the uid of this minister
function get_uid(){ ... };
//sets attributes; makes changes to the text-array in democ4phpbb_ministers
get_X() {...}
set_X() {...}
has_X() {...}
}
Attributes could be:
+ who is his Co-moderator
+ when did the term of office for this minister start ?
+ hat this minister the right to do X ?
Pro: rather flexible, we dont have to say: this is a moderator, he can't do X, only judges can do that.
Con: classes get very big (functions for e.g. judges, moderators ... all in one class)
Syntax for the text_array in democ4phpbb_ministers:
attribute1:value;attribute2:value;
(the value and the attribute are seperated by a : while two attribute-value pairs are seperated by ; )
For everything the ministers can do there will be a file in phpBB2/democ4phpbb/minister/,
e.g. phpBB2/democ4phpbb/minister/delte_post.php
(similar to phpBB2/admin/ ). phpBB2/democ4phpbb/minister/index.php will test the attributes of a minister and will make only give a link to those functions a minister ist allowed to use.
It the user executing phpBB2/democ4phpbb/minister/index.php is no minister, it will give him/her means to configure his democracy-settings
This index.php will also test if the minister is yet in office or if the time for a sucessor has come.
Additionally there will be the directory
phpBB2/democ4phpbb/admin, in which the admin can find pages to control the democracy-stuff (what percentage of the electorate have to vote against a minister to impeach him/her, how long is the term of office...).
What do we have to change in phpBB2 with this approach:
+phpBB2/templates/subSilver/overall_header.tpl to give a link to phpBB2/democ4phpbb/minister/index.php
+phpBb2/democ4phpb/templates/subSilver/admin/index.navigate.tpl to give a linke to phpBB2/democ4phpbb/admin/index.php
What do you say ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we should use the features already implemented in phpBB.
e.g. ranks and groups for ministers
there are two possibilities to use these features:
1. implement all these functions directly, e.g. add sql queries and code to the appropiate place or even implement "wrappers" to our minister object.
2. at the installation of our mod we (let) create different ranks/groups, one for every type of minister in every forum.
then a script only needs to modify the user_group table and the ranks table automatically after every change (mostly a new election, sometimes impeachment)
pros:
we nearly don't need to touch the original phpbb source.for this permission stuff
so: it's simpler, easier to implement, more secure, more compatible to future versions of phpBB, and faster in runtime.
cons: ???
What different data do you want to store exactly in that field?
And is it really that different?
My suggestion: at least some db fields for the most common data and then your large data field for more private things.
I want to be able to ask at least: "who are the moderators in my grade?" "who has been it last year?"
so I want the following fields:
- "begin" which must have a value
- "end" which also can be empty
- "category","subcategory" or in our case "grade" which indicates where is this guy moderator/judge/...
I would use the the php serialize()/unserialize functions.
some questions:
what for is your minister_id field exactly? primary key? or type of minister?
should we store former ministers? in this table or in another?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We could run into problems when we want to give our ministers rights you cannot give a group in phpBB2. So we would have to change the interface the admin has to give the various groups their permissions, or we would have to split the interface into two parts (the default-interface with a custom one). Solution ?
What do we want our moderators to do ? I think they should be able to decide what their users can do in the forum they moderate, so we have to program something like: this group can decide what this other group can do. Is this yet implemented ?
Making it possible not only to moderate a forum but a category is easier as I tought. We only have to create the possibility to create new fori (fori = plural of forum ? ;-) ) with the minister-group for this forum as admin. hehe
Now to your questions
> What different data do you want to store exactly in that field?
I think everything where the data can not be put elsewhere
>My suggestion: at least some db fields for the >most common data and then your large data field >for more private things.
>I want to be able to ask at least: "who are the >moderators in my grade?" "who has been it last >year?"
>
>so I want the following fields:
>- "begin" which must have a value
>- "end" which also can be empty
I agree
Maybe there should also be something like a priority-field, because some people deserve less thrust than others.
Another field could be a text-array in which all actions of the ministers are stored (Is this violation of privacy good ?). What do you mean ?
You also wanted a field which indicates, in which category the minister is allowed to execute his/her duty, but I think there should be also the possibility for ministers who can execute their duty globally (for example the memvers of the "council of the old" (ltestenrat), in case there will be something like that in the future. In this case we could fill the field with a special value.
>I would use the the php serialize()/unserialize >functions.
Agreed
>should we store former ministers?
yes, why not; it doesn't hurt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>what for is your minister_id field exactly? >primary key? or type of minister?
I thought it would be the primary key;
We could make a field indicating the minister-type of a minister, but we should keep in mind, that people are allowed to hold to ministries.
I think in this case we simply fill one minister-tale for each ministry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Another field could be a text-array in which all actions of the ministers are stored (Is this
> violation of privacy good ?). What do you mean ?
What for do we have a Law&Order Team?? ;-)
In my opinion this violation of privacy is acceptable.
The minister is responsible for what he does.
But why not record his actions in an extra table?
then it's faster (otherwise: always unserialize/reserialize an array)
and more convenient (e.g. a user's complaint: "who has deleted my posting?").
So a simple log table contains:
-timestamp
-minister ID
-action
- perhaps ID of posting that was affected? (so we need an archive table for deleted postings)
perhaps we should record everything there (or in another log table) e.g. results of elections,
errors, hacking attempts, identification failures, new members....
a team member could download/(let download by a cron/wget script) the logs every month (or after a longer period) and archive it on cd-r?
should we delete all captured data after a certain time? (privacy!!)
>Maybe there should also be something like a priority-field, because some people deserve >less thrust than others.
I don't like this idea. Sounds like bigbrother. Who determines how much thrust one person deserves? We?
Furthermore: what for do you need such a priority rating?
> I think in this case we simply fill one minister-tale for each ministry.
you mean "table"?
I suggest: simply another record with a different Minister ID, a different minister type and the same userid into the same table.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>But why not record his actions in an extra >table?
>then it's faster (otherwise: always >unserialize/reserialize an array)
>and more convenient (e.g. a user's complaint: >"who has deleted my posting?").
>So a simple log table contains:
>-timestamp
>-minister ID
agreed;
>-action
should action be a integer or text-field ?
>- perhaps ID of posting that was affected? (so >we need an archive table for deleted postings)
But what if no posting at all has been affected by the action (e.g. when the action is adding a new user). Are those actions so frequently that we have to take care of this ?
Perhaps we should save some other value next to/instead of the posting-ID, maybe the group-id of the user(s), whom the actions affects (User: "give me all deleted postings in the forums is use" ).
>perhaps we should record everything there (or >in another log table) e.g. results of >elections,
>errors, hacking attempts, identification >failures, new members....
>a team member could download/(let download by a >cron/wget script) the logs every month (or >after a longer period) and archive it on cd-r?
I don't agree. Sure it would be interesting to see hacking attempts and indentification failures, but what would be the use of this data ?
>>Maybe there should also be something like a >>priority-field, because some people deserve >>less thrust than others.
>I don't like this idea. Sounds like bigbrother. >Who determines how much thrust one person >deserves? We?
>Furthermore: what for do you need such a >priority rating?
Imagine the following scenario: We have 3 moderators for the forums of the 5th class: Two moderators are from the 5th class and one moderator is from the 13th class to supervise the 5th-class-moderators, so the ministers from the 5th class should not be able to undo what the moderator from the 13th class has decided (we could solve this concrete issue with making the 13th-class-moderator the admin of the moderator-group for the 5th-class-fori, so he can throw the 5th-class-moderators out if they don't behave).
>> I think in this case we simply fill one >>minister-tale for each ministry.
>>you mean "table"?
>I suggest: simply another record with a >different Minister ID, a different minister
>type and the same userid into the same table.
Agreed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Imagine the following scenario: ..one moderator is from the 13th class to supervise the
> 5th-class-moderators...
ok, but then I suggest to make an extra minister named "supervisor",
so that e.g. 5th grade pupils can easily distinguish him from moderators elected by them.
And not every 12/13th grade moderator is suited for a supervisor of "little children" ;-)
>Sure it would be interesting to see hacking attempts and indentification failures, but what
>would be the use of this data ?
Okay, it will be "only" interesting.
But if one tries to hack our forum again and again, perhaps in order to cheat other community members, wouldn't it be cool if we could find out his username and tell him to stop that, if he is registered?
Don't you like that "log-table" idea in general or just that hacking/indentification failure?
I originally thought it could serve as a "history" for important going-ons:
who was elected, who joined the community, who left it and so on.
> >-action
> should action be a integer or text-field ?
this question depends on what we want to record. see above
perhaps addtional fields for:
- integer for the type of action
- ministerID for the minister who did it (or zero/empty)
- ID of affected subject (or zero/empty)
- text field for description (or empty)
> Are those actions so frequently that we have to take care of this ?
I hope not. But even if one member complains, then its an advantage if we have a proper organized log. we can save a lot of time later.
perhaps we can turn off logging (at least of specific actions) after the "beta phase", if we encounter no problems
P.S: lets use a mailing list... there's also an archive for it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>ok, but then I suggest to make an extra >minister named "supervisor",
>so that e.g. 5th grade pupils can easily >distinguish him from moderators elected by >them.
Do you mean a supervisor should be a second minister-type, next to a moderator ? If yes, we should make a directory in phpBB2/democ4phpbb/ as well, e.g. phpBB2/democ4phpbb/supervisor/
>But if one tries to hack our forum again and >again, perhaps in order to cheat other >community members, wouldn't it be cool if we >could find out his username and tell him to >stop that, if he is registered?
Yeah, but thas has nothing to do with the democracy we are going to create. A log table for the democrycy-stuff is good, but i would veto logging useless data like failed logins. If some community members try to cheat the other members they will eventually notice that and the moderators will do the right thing.
But generally I like this log-table-thing. So the two moderators can keep track of what the other moderator does.
Suggestion for the Log-Table:
int minister_id; (minister who did it)
int action; (filled with some define()d constants)
text_array action_description; (filled with some serialize()d vars, depending on the action)
text_array comment; (where the admin can document why he did this)
>P.S: lets use a mailing list... there's also an >archive for it.
Von mir aus; ich mach mich mal schlau und kmmer mich darum.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Der Typ hat sich nicht mehr gemeldet, ich glaube wir knnen wieder auf deutsch weiterreden...
>>P.S: lets use a mailing list... there's also >>an archive for it.
>Von mir aus; ich mach mich mal schlau und >kmmer ich darum.
Also ich habe jetzt 2 Listen (Law&Order und Technik gemacht und mich auch schon subscribed)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Ich glaub der wartet auf eine Nachricht >unsererseits, ob er mitmachen darf.
Die hat er von mir schon bekommen.
Wie dem auch sei, weiter im Text:
Wir brauchen noch eine Datenstruktur fr einen User, der fr ein Amt vorgeschlagen wurde und jetzt zur Wahl steht. Mein Vorschlag:
Tabellenname: democ4phpbb_candidate
Felder:
+int user_id (damit wir wissen, wer der Kandidat ist)
+int votes (Stimmen halt)
+int group_id (Group-Id von der Gruppe, von der er gewhlt wird)
+int ministry (Amt, das er bekommt, wenn er genug Stimmen hat)
Wenn dieser user gewonnen hat und noch kein minister-record fr ihn existiert wird ein neuer geschaffen.
Wenn schon einer existiert, dieser aber gerade nicht aktiv ist (weil dieser User halt nicht mehr in dem Amt ist, weil z.B. seine Amtszeit vorber gegangen ist) wird dieser record geupdated.
Was machen wir, wenn der User schon einen Posten hat (und somit sein minister-record besetzt ist ?). Machen wir dann ein neuen record, oder schauen wir, dass die minister-records auch fr mehrere Posten ausgelegt sind. Wir knnten das z.B. so machen, dass wir das Integer-Feld admin_type mit mehreren mit logisch Oder kombinierbaren definie()s fllen (du verstehst was ich meine, nicht ?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Wenn dieser user gewonnen hat und noch kein minister-record fr ihn existiert wird ein neuer
> geschaffen.
> Wenn schon einer existiert, dieser aber gerade nicht aktiv ist (weil dieser User halt nicht mehr in
> dem Amt ist, weil z.B. seine Amtszeit vorber gegangen ist) wird dieser record geupdated.
Ich htte halt gesagt: Dann schreiben wir einfach einen neuen Record mit einem anderen Datum (immer Beginn und Ende oder: ID der Legislaturperiode. ID wre elegant. was dagegen sprechen knnte: unregelmiges Beenden/Neuwahlen eines Amtes) und dem betreffenden Amt.
Weiteres Vorgehen:
-alter Record wird entweder so belassen wie er ist und bei SQL-Anfragen wird das momentane Datum/LegislaturperiodenID angegeben oder
-alter Record wird als alt markiert und bei jeder SQL Anfrage wird angegeben: alt/aktuell
-alter Record wird in eine "Amt_History"-Tabelle verschoben (sprich: "insert into ahistory", "delete from amt"
Zu den Wahlen:
Wir knnen doch einfach das eingebaute Vote-System modifizieren.
Wahlen sollten doch extra auf einer democ-Seite sein, nicht als regulrer Poll, oder?
Wichtig: weitere Tabelle: wer hat schon gewhlt?
Den Code knnen wir zum grten Teil vom eingebauten System kopieren und anpassen.
Sollen wir besondere Sicherheitsvorkehrungen fr die Wahl treffen?
Vielleicht erneute Eingabe des Passwortes?
Was soll dann "int ministry" beinhalten?
schon allgemein: "1. Moderator in einem Klassenforum" mit der zugehrigen groupID extra?
wir wollen doch einen ersten und einen zweiten Moderator.
Man lsst sich aber nur als Moderator allgemein aufstellen, der mit den zweitmeisten Stimmen wird der zweite. Da mssen wir noch was vereinbaren.
> Machen wir dann ein neuen record, oder schauen wir, dass die minister-records auch fr
> mehrere Posten ausgelegt sind....
> ...dass wir das Integer-Feld admin_type mit mehreren mit logisch Oder kombinierbaren definie()s
> fllen (du verstehst was ich meine, nicht ?).
Wei zwar nicht was du mit "definie()" meinst, ich hoffe aber doch, dass ich zumindest das Konzept verstanden hab:
jedes Bit des int bedeutet ein anderes Amt?
Bin ich eher nicht so dafr. Das wird einfach zu kompliziert.
Man soll ja auch gleichzeitig mter in verschieden Gruppen ausben drfen. (z.B. Supervisor)
Mach mer einfach einen neuen Record mit dem passenden Datum(szeitraum)/ LegislaturperiodeID/aktuell-Bitgesetzt. (s.o.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Puuh, das wird langsam richtig kompliziert, ich habe mir das nochmal durchdacht und bin zu folgendem Ergebnis gekommen (bisschen ein neuer Ansatz):
TABLE democ4phpbb_minister {
int minister_id (primary key)
int user_id
boolean can_get_ministry (ist true, wenn dieser user ein Ministerium bernehmen kann)
};
Wer einmal in dieser Tabelle drin ist (also, wer schon mal minister war, bleibt auch drin und wird nicht mehr gelscht, auch wenn er sein Amt aufgibt).
TABLE democ4phpbb_ministry{
int ministry_id (primary key)
int minister_id (die id von dem minister, der gerade dieses Amt hat)
int group_id (Group-ID von der Gruppe, ber die man Macht hat, wenn man dieses Ministerium hat)
}
In der Tabelle ist nur, wer gerade aktiv ein Amt ausbt. Bei einem Amtswechsel wird nur die minister_id ausgetauscht.
TABLE democ4phpbb_action{
int action_id (primary key)
int minister_id (wer hat das gemacht)
int ministry_id (welches Amt hatte er)
int action_type (was hat er gemacht)
text comment (mit was hat er das, was er gemacht hat begrndet)
int victim (mit dem hat er das gemacht ? Group-Id oder User-Id)
int group_or_user (hat er das, was er gemacht hat mit einer Gruppe oder mit einem User gemacht)
date timestamp (wann hat er das gemacht)
}
Wer irgenetwas macht (zensiert, gewhlt wird, aus dem Amt geschmissen wird ...) wird hier gelogged. So knnen wir perfekt rekonstruieren, was wer gemacht hat. Ich glaube die Felder sind allgemein genug, so dass wir alle mglichen Sache, die passieren, hier aufzeichnen knnen.
Was hlts du auch von folgenden Datenstrukturen:
TABLE democ4phpbb_elector{
int elector_id (primary_key)
boolean voted (hat er schon gewhlt)
boolean allowed_to_vote (darf er whlen ?)
int user_id (wer ist er ?)
}
TABLE democ4phpbb_candidate{
int candidate_id (primary_key)
int ministry_id (wofr bewirbt er sich)
int minister_id (wer ist er (1)?)
int user_id (wer ist er (2)?)
int votes (wieviele Stimmen hat er ?)
}
P.s: in der CVS-Rubrik kannst du meine bescheidenen Erfolge im Umgang mit CVS sehen.
Bis denn,
MaJo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gibt es einen speziellen Grund, warum du eine zustzliche tabelle willst: democ4phpbb_minister?
es wrde ja meiner Ansicht nach reichen, wenn wir in democ4phpbb_ministry einfach statt der minister_id die user_id reinnehmen?
Das ganze kostet einigen unntigen Aufwand (v.a. Performance), da man bei jeder Abfrage die zwei Tabellen verknpfen muss: "...WHERE democ4phpbb_minister.minister_id = democ4phpbb_ministry.minister_id..."
die einzige zustzliche Info ist "can_get_ministry"
Frage: Wann genau soll jemand KEIN Amt bekommen drfen?
Beginn und Ende des Amts fehlen noch.
auerdem wrd ich in democ4phpbb_ministry noch reinnehmen: "ministry_type", also z.B.
1.Moderator, 2.Moderator, Supervisor usw.
Bei allgemeinen mtern einfach: group_id=0
Bei democ4phpbb_action.comment: wird vielleicht kompliziert, das einzubauen.
Am Rande: victim klingt so negativ. Wie wrs mit "affected"?
democ4phpbb_elector:
warum zwei ID's benutzen: userid und electorid?
beim phpbb-vote-System heit die Tabelle brigends phpbb_vote_voters
mit den Feldern vote_id , vote_user_id , vote_user_ip
Wobei vote_id die nummer der Abstimmung ist.
Und quasi fr jeden abgegebenen "Stimmzettel" ein Record angelegt wird.
Frage: Aus welchen Grnden wollen wir jemanden ausschlieen?
Du hast jetzt 2mal ein Feld, um jemand auszuschlieen.
Wie oft soll das vorkommen? Soll z.B. ein User erst ab einem bestimmten Mitgliedszeitraum whlen/gewhlt werden knnen?
Dann knnen wir das einfacher ber "phpbb_users.user_regdate" regeln.
oder soll einer gebannt werden knnen?
Dann wrs vielleicht einfacher mit einer sog. "Blacklist". Denn so oft soll das ja nicht vorkommen, oder?
Oder soll einer bis zur genaueren Authentifikation (z.B. uns Ausweis zeigen) kein Vollmitglied sein?
Dann wre vielleicht ein zustzliches Feld in phpbb_users praktischer.
zu democ4phpbb_candidate:
zur Unterscheidung von user_id und minister_id : siehe oben.
zu ministry_id:
wir mssen mal klar definieren:
ist ministry_id einmalig?
und: vielleicht sollten wir das eher ber minister_type und minister_group regeln?
Ansonsten hab ich nix dran auszusetzen.
..oder....was hltst du von einer election_id fr alle Tabellen die mit Wahlen zu tun haben?
Falls mal z.B in einem Forum ne unvorhergesehene Neuwahl stattfinden soll, damit die sich nicht mit einer andern laufenden Wahl ins Gehege kommt?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>gibt es einen speziellen Grund, warum du eine >zustzliche tabelle willst: >democ4phpbb_minister?
1) Wir knnen damit den Teil, der sich immer verndert an einer Stelle speichern und den Teil, der sich immer verndert an einer anderen Stelle.
2) Wir knnen Daten, die mit einen Minister zu tun haben, an einer Stelle speichern (wie z.B. das can_get_ministy-Feld. Ok, das war vielleicht ein dummes Beispiel, aber wenn wir nachdenken wird uns sicher etwas einfallen, wo man das brauchen kann. Zugegeben, wenn wir can_get_ministry weglassen sieht democ4phpbb_minister ziemlich berflssig aus).
Was meinst du ? Sollen wir das in 2 Tabellen aufspalten ?
Wir knnen uns die Option ja mal offenhalten, eine Tabelle democ4phpbb_minister zu machen, wenn wir was finden, was wir als spezifische Daten fr einen Minister speichern wollen. Diese Tabelle dann einzubinden drfte ja nicht so schwer sein.
>es wrde ja meiner Ansicht nach reichen, wenn >wir in democ4phpbb_ministry einfach statt der >minister_id die user_id reinnehmen?
ok, berredet.
>Beginn und Ende des Amts fehlen noch.
Brauchen wir das berhaupt ? In democ4phpbb_minister hat das nicht zu suchen (dann wrden wir Probleme kriegen, wenn jemand 2 mter hat oder jemals gehabt hat). In democ4phpbb_ministry hat das auch nichts zu suchen, weil wie ich es mir gedacht habe nur Leute, die _aktiv_ einen Posten haben einen record in democ4phpbb_ministry haben.
Jeder Ministerwechsel wird als action in democ4phpbb_action aufgezeichnet. Wenn wir also rekonstuieren wollen, was passiert ist, mssen wir halt schauen wer wann was war.
>auerdem wrd ich in democ4phpbb_ministry noch >reinnehmen: "ministry_type", also z.B.
>1.Moderator, 2.Moderator, Supervisor usw.
>Bei allgemeinen mtern einfach: group_id=0
gut
>Bei democ4phpbb_action.comment: wird vielleicht >kompliziert, das einzubauen.
Wieso ? (ich habe mit DBs noch nicht so viel gemacht)
>Am Rande: victim klingt so negativ. Wie wrs >mit "affected"?
ok, habs gendert
>democ4phpbb_elector:
>warum zwei ID's benutzen: userid und electorid?
Stimmt, eins ist berflssig. Nehmen wir elector_id raus. allowed_to_vote knnen wir auch rausnehmen (weil wir nocht nicht wissen, ob das gut ist, wenn wir das so implementieren).
>Dann wrs vielleicht einfacher mit einer sog. >"Blacklist". Denn so oft soll das ja nicht >vorkommen, oder?
Ja, das erscheint mir auch als der richtige Weg zu entscheiden, wer nicht whlen darf.
>zu democ4phpbb_candidate:
>ist ministry_id einmalig?
Wenn der User gewinnt, wird aus democ4phpbb_ministry der record herausgesucht, der die ministry_id hat und dann wird dieser record so angepasst, dass er auf den neuen User zugeschnitten ist.
>und: vielleicht sollten wir das eher ber >minister_type und minister_group regeln?
Wir brauchen aber auf jeden Fall ministry_id, weil wir das ja in democ4phpbb_action brauchen.
>..oder....was hltst du von einer election_id >fr alle Tabellen die mit Wahlen zu tun haben?
Finde ich gut. Dann brauchen wir aber noch eine Tabelle, in der election_id primary key ist und in der wir dann genauer sagen, was das fr eine Wahl ist (ich hab das mal dazugemacht).
Mit obrigen nderungen sehen die Tabellen so aus
**************************************
TABLE democ4phpbb_ministry{
int ministry_id (primary key)
int user_id (die id von dem user, der gerade dieses Amt hat)
int group_id (Group-ID von der Gruppe, ber die man Macht hat, wenn man dieses Ministerium hat; bei allmchtigen Gruppen: group_id=0)
int ministry_type (was ist das fr ein Amt ?)
};
TABLE democ4phpbb_action{
int action_id (primary key)
int user_id (wer hat das gemacht)
int ministry_id (welches Amt hatte er)
int action_type (was hat er gemacht)
text comment (mit was hat er das, was er gemacht hat begrndet)
int affected (mit dem hat er das gemacht ? Enthlt Group-Id oder User-Id, je nachdem)
int group_or_user (hat er das, was er gemacht hat mit einer Gruppe oder mit einem User gemacht)
date timestamp (wann hat er das gemacht)
};
TABLE democ4phpbb_elector{
int election_id
boolean voted (hat er schon gewhlt)
int user_id (wer ist er ?)
};
TABLE democ4phpbb_candidate{
int election_id
int candidate_id (primary_key)
int user_id (wer ist er ?)
int votes (wieviele Stimmen hat er ?)
};
TABLE democ4phpbb_election{
int election_id (primary key)
int ministry (worum geht die Wahl)
int group_id (wer darf whlen)
date begin (wann hat die Wahl begonnen)
date end (wann hrt die Wahl auf)
}
***********************************************
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vorschlag:
wir nehmen berall statt date datetime. Dann ist die Uhrzeit auch noch drin:
datetime democ4phpbb_action.timestamp
datetime democ4phpbb_election.begin
datetime democ4phpbb_election.end
sollen wir in democ4phpbb_action und die IP, von der aus das gemacht wurde, auch noch reinnehmen? (in phpBB2 wird die bei jedem Beitrag aufgezeichnet.)
und in democ4phpbb_elector? Wie gesagt, in phpbb_vote_voters ist die auch drin.
>>Bei democ4phpbb_action.comment: wird vielleicht >kompliziert, das einzubauen.
>Wieso ? (ich habe mit DBs noch nicht so viel gemacht)
von der DB her nicht schwer, aber dann mssen wir phpBB so ndern, dass vor jedem Lschvorgang nach dem Grund gefragt wird.... Ok, wir knnens ja versuchen.
Bei unsere democ4phpBB-Oberflche ist es natrlich kein Problem, da knnen wirs von Anfang an problemlos einbauen.
Frage: wollen wir die gelschten Beitrge irgendwie sichern? (vielleicht als Beweismittel?)
Dann bruchte man fast noch ein Feld mit affected_post_id als Zeiger auf die "Papierkorb"-Tabelle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Vorschlag:
>wir nehmen berall statt date datetime. Dann >ist die Uhrzeit auch noch drin:
>datetime democ4phpbb_action.timestamp
>datetime democ4phpbb_election.begin
>datetime democ4phpbb_election.end
Gut, einverstanden
>sollen wir in democ4phpbb_action und die IP, >von der aus das gemacht wurde, auch noch >reinnehmen? (in phpBB2 wird die bei jedem >Beitrag aufgezeichnet.)
Einverstanden.
>und in democ4phpbb_elector? Wie gesagt, in >phpbb_vote_voters ist die auch drin.
Ja, wieso nicht
>Frage: wollen wir die gelschten Beitrge >irgendwie sichern? (vielleicht als >Beweismittel?)
Das knnten wir nicht nur als Beweismittel nehmen, sondern wenn ein Moderator irgendwann mal bereut, was gelscht zu haben, dann kann er das wieder rckgngig machen. Andererseits hat das glaube ich auch noch ein bisschen Zeit.
>Dann bruchte man fast noch ein Feld mit >affected_post_id als Zeiger auf die >"Papierkorb"-Tabelle.
Wo dieser Zeiger ? In democ4phpbb_action ?
Wie gesagt, ich glaube aber das das noch ein bisschen Zeit hat.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich habe jetzt mal die Datenstrukturen in MySQL-Syntax ins CVS-Repository unter democ4phpbb/doc/mysql_schema.sql reingetan, damit wir mal was festes, ofizielles haben. Schau's dir aber ruhig mal an, ich hab mit Datenbanken noch nicht so viel gemacht.
>>Vorschlag:
>>wir nehmen berall statt date datetime. Dann >ist die Uhrzeit auch noch drin:
>datetime democ4phpbb_action.timestamp
>datetime democ4phpbb_election.begin
>datetime democ4phpbb_election.end
ich habe anstatt datetime int(11) genommen. Die bei phpBB2 machen das auch so. Es knnte sein, dass datetime nicht auf jeder SQL-Platform vorhanden ist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
wahrscheinlich. Mit einem UNIX-Timestamp kann man auch viel leichter rechnen, z.B. Zeitrume, verschiedene Zeitzonen usw.
wir knnen auch voted tinyint(1) DEFAULT '0'
auch weglassen, und bei der Wahl einfach einen Eintrag in die Tabelle machen.
Siehe phpbb_vote_voters ;-)
Dann belegen die Nichtwhler auch keinen Platz.
und ums einheitlich zu machen:
statt: CREATE TABLE democ_ministry
CREATE TABLE democ_office
Sonst ist eigentlich alles in Ordnung
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Leute,
es wird Zeit, dass wir mit dem programmieren anfangen; Das Hauptziel sollte sein, den demokratie-mod zu machen.
Ich schlage vor, wir fangen mal mit den Datenstrukturen an; Wir brauchen auf jeden Fall eine Datenstruktur fr jemand, der irgendein
Amt hat (sei es gewhler Moderator, oder was sonst noch so kommen mag) und natrlich eine Datenstruktur fr den Whler.
Ich wrde sagen wir implementieren Strukturen als Tabellen in der Datenbank und kapseln die Datenbank ber PHP-Klassen (z.B. wrde
es sich anbieten, mal irgendeine abstrakte Klasse fr Amtsinhaber machen wrden. Da knnten wir dann munter von ableiten.
Ich wrde sagen, die Sprache in der wir kommentieren und unsere Variablen benennen ist Englisch. Wir wollen ja ein internationales
Projekt sein...
Das sollte die Amtsinhaber-Tabelle haben:
+eine Variable, die angibt was fr ein Amt die Person hat;
wahrscheinlich werden wir da Source-Code wie z.B. hier nehmen:
********************
define(FOO,1);
define(BAR,2);
[...]
if($c->i == BAR){
aha, er ist also ein BAR
}
********************
+die user_id aus phpbb_users (ist klar)
+Eine Amtsinhaber-ID (ist der key der Tabelle)
+ein paar relativ abstrakte Datenfelder, die wir dann je nach Amt verschieden fllen (um das zu verstecken sind ja Objekt gut)
Sonst noch was ?
Dann brauchen wir noch eine Tabelle fr die Wahlberechtigten (phpbb_users knnten wir zwar modifizieren und auch dafr nehmen, das
sollten wir aber nicht machen, weil sicherlich nicht alle User auch wahlberechtigt sind. Auerdem sind wir dann aufwrtskompartibler)
Die Tablle solle folgendes haben
+ Klasse des Users
+ die user_id aus phpbb_users
Sonst noch was ?
Sollen wir auch phpbb_users erweitern ? Nen Platz fr den wirklichen Namen habe ich nicht gesehen, der muss schon rein wrde ich sagen. Oder machen wir da ne eigene Tabelle fr ?
Phpbb untersttzt schon ein System fr polls.
Nachteil: wir mssen aufpassen, nicht Namespace-Probleme zu bekommen.
Vorteil: Wir haben schon was, was wir nehmen knnen. Hat sich schon jemand den Code dafr nher angeschaut. Was meint ihr ?
Bis denn
MaJo
Ich hab mir die Polls zwar noch nicht angeschaut, aber ich denk, wir sollten es nutzen, wenn schon was da ist.
Was wir noch ndern mssen:
Das Ergebnis sollte wohl allen erst zum Abschluss der Wahl offiziell bekannt werden.
nen Real-Name-Mod gibts schon unter
http://www.phpbb.com/mods/downloads/index.php?t=sub_pages&cat=6
Wie machen wir das dann mit den Rechten?
Vorschlge:
Wir setzen nach jeder Wahl die Rechte in der Datenbank.
Oder wir manipulieren die includes/auth.php.
Wobei ich dafr wre, dass ein Moderator nur die
Beitrge ndern darf, die in seiner Legislaturperiode geschrieben wurden.Oder?
Soll es denn mglich sein, mehrere mter gleichzeitig innezuhaben? So siehts dein Tabellenentwurf ja vor.
dann wre folgendes praktisch (aus dem obigen Beispiel):
*********************
if($c->isAmt(BAR))
{
//aha, er ist also (u.a.) ein BAR
}
*********************
Gre Thomas
P.S: ich bin grad in der Klausurenzeit. Daher halt ich mich ein bisschen zurck, wie ihr sicher schon gemerkt habt ;-)
>Wobei ich dafr wre, dass ein Moderator nur >die Beitrge ndern darf, die in seiner >Legislaturperiode geschrieben wurden.Oder?
Bin ich auf dafr
>P.S: ich bin grad in der Klausurenzeit. Daher >halt ich mich ein bisschen zurck, wie ihr >sicher schon gemerkt habt ;-)
Ich bin grad in der Abi-Zeit: das gleiche gilt fr mich...
>Soll es denn mglich sein, mehrere mter >gleichzeitig innezuhaben? So siehts dein >Tabellenentwurf ja vor.
Prinzipiell ja, aber es sollte mter geben, die nicht kombinierbar sind (leuchtet ein)
Hi Leute
Let this discussion be in english further on, ok ?
I think we should let all our tables start with democ4phpbb_
The code we produce should be located in phpBB2/democ4phpbb/
Here's a suggestion for the table for the abstract minister class about like this:
CREATE TABLE democ4phpbb_minister (
int user_id,
int minister_id,
text_array data,
);
(I know that it is no valid sql syntax ;-) ).
the text_arry will contain a string describing the options of a certain minister, e.g. when he entered his office, what his rights are...
Pro: We are abstract and thus flexible enough to make ministers apart from the tribunes (so could we call the moderators) like e.g. judges, WITHOUT inheriting this class (we dont need interitance at all).
Con: We will not be able to make database-queries like $sql->query("all-ministers-who-have-that-and-that"), we would have to grep a array of all ministers and query e.g. like this:
for ($i=0;isset($ministers[$i]);$i++){
if($ministers[$i]->foo() == BAR){
...
}
}
We program a class around this table
class minister{
//returns the uid of this minister
function get_uid(){ ... };
//sets attributes; makes changes to the text-array in democ4phpbb_ministers
get_X() {...}
set_X() {...}
has_X() {...}
}
Attributes could be:
+ who is his Co-moderator
+ when did the term of office for this minister start ?
+ hat this minister the right to do X ?
Pro: rather flexible, we dont have to say: this is a moderator, he can't do X, only judges can do that.
Con: classes get very big (functions for e.g. judges, moderators ... all in one class)
Syntax for the text_array in democ4phpbb_ministers:
attribute1:value;attribute2:value;
(the value and the attribute are seperated by a : while two attribute-value pairs are seperated by ; )
For everything the ministers can do there will be a file in phpBB2/democ4phpbb/minister/,
e.g. phpBB2/democ4phpbb/minister/delte_post.php
(similar to phpBB2/admin/ ). phpBB2/democ4phpbb/minister/index.php will test the attributes of a minister and will make only give a link to those functions a minister ist allowed to use.
It the user executing phpBB2/democ4phpbb/minister/index.php is no minister, it will give him/her means to configure his democracy-settings
This index.php will also test if the minister is yet in office or if the time for a sucessor has come.
Additionally there will be the directory
phpBB2/democ4phpbb/admin, in which the admin can find pages to control the democracy-stuff (what percentage of the electorate have to vote against a minister to impeach him/her, how long is the term of office...).
What do we have to change in phpBB2 with this approach:
+phpBB2/templates/subSilver/overall_header.tpl to give a link to phpBB2/democ4phpbb/minister/index.php
+phpBb2/democ4phpb/templates/subSilver/admin/index.navigate.tpl to give a linke to phpBB2/democ4phpbb/admin/index.php
What do you say ?
we should use the features already implemented in phpBB.
e.g. ranks and groups for ministers
there are two possibilities to use these features:
1. implement all these functions directly, e.g. add sql queries and code to the appropiate place or even implement "wrappers" to our minister object.
2. at the installation of our mod we (let) create different ranks/groups, one for every type of minister in every forum.
then a script only needs to modify the user_group table and the ranks table automatically after every change (mostly a new election, sometimes impeachment)
pros:
we nearly don't need to touch the original phpbb source.for this permission stuff
so: it's simpler, easier to implement, more secure, more compatible to future versions of phpBB, and faster in runtime.
cons: ???
What different data do you want to store exactly in that field?
And is it really that different?
My suggestion: at least some db fields for the most common data and then your large data field for more private things.
I want to be able to ask at least: "who are the moderators in my grade?" "who has been it last year?"
so I want the following fields:
- "begin" which must have a value
- "end" which also can be empty
- "category","subcategory" or in our case "grade" which indicates where is this guy moderator/judge/...
I would use the the php serialize()/unserialize functions.
some questions:
what for is your minister_id field exactly? primary key? or type of minister?
should we store former ministers? in this table or in another?
We could run into problems when we want to give our ministers rights you cannot give a group in phpBB2. So we would have to change the interface the admin has to give the various groups their permissions, or we would have to split the interface into two parts (the default-interface with a custom one). Solution ?
What do we want our moderators to do ? I think they should be able to decide what their users can do in the forum they moderate, so we have to program something like: this group can decide what this other group can do. Is this yet implemented ?
Making it possible not only to moderate a forum but a category is easier as I tought. We only have to create the possibility to create new fori (fori = plural of forum ? ;-) ) with the minister-group for this forum as admin. hehe
Now to your questions
> What different data do you want to store exactly in that field?
I think everything where the data can not be put elsewhere
>My suggestion: at least some db fields for the >most common data and then your large data field >for more private things.
>I want to be able to ask at least: "who are the >moderators in my grade?" "who has been it last >year?"
>
>so I want the following fields:
>- "begin" which must have a value
>- "end" which also can be empty
I agree
Maybe there should also be something like a priority-field, because some people deserve less thrust than others.
Another field could be a text-array in which all actions of the ministers are stored (Is this violation of privacy good ?). What do you mean ?
You also wanted a field which indicates, in which category the minister is allowed to execute his/her duty, but I think there should be also the possibility for ministers who can execute their duty globally (for example the memvers of the "council of the old" (ltestenrat), in case there will be something like that in the future. In this case we could fill the field with a special value.
>I would use the the php serialize()/unserialize >functions.
Agreed
>should we store former ministers?
yes, why not; it doesn't hurt.
>what for is your minister_id field exactly? >primary key? or type of minister?
I thought it would be the primary key;
We could make a field indicating the minister-type of a minister, but we should keep in mind, that people are allowed to hold to ministries.
I think in this case we simply fill one minister-tale for each ministry.
> Another field could be a text-array in which all actions of the ministers are stored (Is this
> violation of privacy good ?). What do you mean ?
What for do we have a Law&Order Team?? ;-)
In my opinion this violation of privacy is acceptable.
The minister is responsible for what he does.
But why not record his actions in an extra table?
then it's faster (otherwise: always unserialize/reserialize an array)
and more convenient (e.g. a user's complaint: "who has deleted my posting?").
So a simple log table contains:
-timestamp
-minister ID
-action
- perhaps ID of posting that was affected? (so we need an archive table for deleted postings)
perhaps we should record everything there (or in another log table) e.g. results of elections,
errors, hacking attempts, identification failures, new members....
a team member could download/(let download by a cron/wget script) the logs every month (or after a longer period) and archive it on cd-r?
should we delete all captured data after a certain time? (privacy!!)
>Maybe there should also be something like a priority-field, because some people deserve >less thrust than others.
I don't like this idea. Sounds like bigbrother. Who determines how much thrust one person deserves? We?
Furthermore: what for do you need such a priority rating?
> I think in this case we simply fill one minister-tale for each ministry.
you mean "table"?
I suggest: simply another record with a different Minister ID, a different minister type and the same userid into the same table.
>But why not record his actions in an extra >table?
>then it's faster (otherwise: always >unserialize/reserialize an array)
>and more convenient (e.g. a user's complaint: >"who has deleted my posting?").
>So a simple log table contains:
>-timestamp
>-minister ID
agreed;
>-action
should action be a integer or text-field ?
>- perhaps ID of posting that was affected? (so >we need an archive table for deleted postings)
But what if no posting at all has been affected by the action (e.g. when the action is adding a new user). Are those actions so frequently that we have to take care of this ?
Perhaps we should save some other value next to/instead of the posting-ID, maybe the group-id of the user(s), whom the actions affects (User: "give me all deleted postings in the forums is use" ).
>perhaps we should record everything there (or >in another log table) e.g. results of >elections,
>errors, hacking attempts, identification >failures, new members....
>a team member could download/(let download by a >cron/wget script) the logs every month (or >after a longer period) and archive it on cd-r?
I don't agree. Sure it would be interesting to see hacking attempts and indentification failures, but what would be the use of this data ?
>>Maybe there should also be something like a >>priority-field, because some people deserve >>less thrust than others.
>I don't like this idea. Sounds like bigbrother. >Who determines how much thrust one person >deserves? We?
>Furthermore: what for do you need such a >priority rating?
Imagine the following scenario: We have 3 moderators for the forums of the 5th class: Two moderators are from the 5th class and one moderator is from the 13th class to supervise the 5th-class-moderators, so the ministers from the 5th class should not be able to undo what the moderator from the 13th class has decided (we could solve this concrete issue with making the 13th-class-moderator the admin of the moderator-group for the 5th-class-fori, so he can throw the 5th-class-moderators out if they don't behave).
>> I think in this case we simply fill one >>minister-tale for each ministry.
>>you mean "table"?
>I suggest: simply another record with a >different Minister ID, a different minister
>type and the same userid into the same table.
Agreed.
> Imagine the following scenario: ..one moderator is from the 13th class to supervise the
> 5th-class-moderators...
ok, but then I suggest to make an extra minister named "supervisor",
so that e.g. 5th grade pupils can easily distinguish him from moderators elected by them.
And not every 12/13th grade moderator is suited for a supervisor of "little children" ;-)
>Sure it would be interesting to see hacking attempts and indentification failures, but what
>would be the use of this data ?
Okay, it will be "only" interesting.
But if one tries to hack our forum again and again, perhaps in order to cheat other community members, wouldn't it be cool if we could find out his username and tell him to stop that, if he is registered?
Don't you like that "log-table" idea in general or just that hacking/indentification failure?
I originally thought it could serve as a "history" for important going-ons:
who was elected, who joined the community, who left it and so on.
> >-action
> should action be a integer or text-field ?
this question depends on what we want to record. see above
perhaps addtional fields for:
- integer for the type of action
- ministerID for the minister who did it (or zero/empty)
- ID of affected subject (or zero/empty)
- text field for description (or empty)
> Are those actions so frequently that we have to take care of this ?
I hope not. But even if one member complains, then its an advantage if we have a proper organized log. we can save a lot of time later.
perhaps we can turn off logging (at least of specific actions) after the "beta phase", if we encounter no problems
P.S: lets use a mailing list... there's also an archive for it.
>ok, but then I suggest to make an extra >minister named "supervisor",
>so that e.g. 5th grade pupils can easily >distinguish him from moderators elected by >them.
Do you mean a supervisor should be a second minister-type, next to a moderator ? If yes, we should make a directory in phpBB2/democ4phpbb/ as well, e.g. phpBB2/democ4phpbb/supervisor/
>But if one tries to hack our forum again and >again, perhaps in order to cheat other >community members, wouldn't it be cool if we >could find out his username and tell him to >stop that, if he is registered?
Yeah, but thas has nothing to do with the democracy we are going to create. A log table for the democrycy-stuff is good, but i would veto logging useless data like failed logins. If some community members try to cheat the other members they will eventually notice that and the moderators will do the right thing.
But generally I like this log-table-thing. So the two moderators can keep track of what the other moderator does.
Suggestion for the Log-Table:
int minister_id; (minister who did it)
int action; (filled with some define()d constants)
text_array action_description; (filled with some serialize()d vars, depending on the action)
text_array comment; (where the admin can document why he did this)
>P.S: lets use a mailing list... there's also an >archive for it.
Von mir aus; ich mach mich mal schlau und kmmer mich darum.
Der Typ hat sich nicht mehr gemeldet, ich glaube wir knnen wieder auf deutsch weiterreden...
>>P.S: lets use a mailing list... there's also >>an archive for it.
>Von mir aus; ich mach mich mal schlau und >kmmer ich darum.
Also ich habe jetzt 2 Listen (Law&Order und Technik gemacht und mich auch schon subscribed)
Ich glaub der wartet auf eine Nachricht unsererseits, ob er mitmachen darf.
P.S: seine Homepage laut Google:
http://www.rasadam.com/
>Ich glaub der wartet auf eine Nachricht >unsererseits, ob er mitmachen darf.
Die hat er von mir schon bekommen.
Wie dem auch sei, weiter im Text:
Wir brauchen noch eine Datenstruktur fr einen User, der fr ein Amt vorgeschlagen wurde und jetzt zur Wahl steht. Mein Vorschlag:
Tabellenname: democ4phpbb_candidate
Felder:
+int user_id (damit wir wissen, wer der Kandidat ist)
+int votes (Stimmen halt)
+int group_id (Group-Id von der Gruppe, von der er gewhlt wird)
+int ministry (Amt, das er bekommt, wenn er genug Stimmen hat)
Wenn dieser user gewonnen hat und noch kein minister-record fr ihn existiert wird ein neuer geschaffen.
Wenn schon einer existiert, dieser aber gerade nicht aktiv ist (weil dieser User halt nicht mehr in dem Amt ist, weil z.B. seine Amtszeit vorber gegangen ist) wird dieser record geupdated.
Was machen wir, wenn der User schon einen Posten hat (und somit sein minister-record besetzt ist ?). Machen wir dann ein neuen record, oder schauen wir, dass die minister-records auch fr mehrere Posten ausgelegt sind. Wir knnten das z.B. so machen, dass wir das Integer-Feld admin_type mit mehreren mit logisch Oder kombinierbaren definie()s fllen (du verstehst was ich meine, nicht ?).
> Wenn dieser user gewonnen hat und noch kein minister-record fr ihn existiert wird ein neuer
> geschaffen.
> Wenn schon einer existiert, dieser aber gerade nicht aktiv ist (weil dieser User halt nicht mehr in
> dem Amt ist, weil z.B. seine Amtszeit vorber gegangen ist) wird dieser record geupdated.
Ich htte halt gesagt: Dann schreiben wir einfach einen neuen Record mit einem anderen Datum (immer Beginn und Ende oder: ID der Legislaturperiode. ID wre elegant. was dagegen sprechen knnte: unregelmiges Beenden/Neuwahlen eines Amtes) und dem betreffenden Amt.
Weiteres Vorgehen:
-alter Record wird entweder so belassen wie er ist und bei SQL-Anfragen wird das momentane Datum/LegislaturperiodenID angegeben oder
-alter Record wird als alt markiert und bei jeder SQL Anfrage wird angegeben: alt/aktuell
-alter Record wird in eine "Amt_History"-Tabelle verschoben (sprich: "insert into ahistory", "delete from amt"
Zu den Wahlen:
Wir knnen doch einfach das eingebaute Vote-System modifizieren.
Wahlen sollten doch extra auf einer democ-Seite sein, nicht als regulrer Poll, oder?
Wichtig: weitere Tabelle: wer hat schon gewhlt?
Den Code knnen wir zum grten Teil vom eingebauten System kopieren und anpassen.
Sollen wir besondere Sicherheitsvorkehrungen fr die Wahl treffen?
Vielleicht erneute Eingabe des Passwortes?
Was soll dann "int ministry" beinhalten?
schon allgemein: "1. Moderator in einem Klassenforum" mit der zugehrigen groupID extra?
wir wollen doch einen ersten und einen zweiten Moderator.
Man lsst sich aber nur als Moderator allgemein aufstellen, der mit den zweitmeisten Stimmen wird der zweite. Da mssen wir noch was vereinbaren.
> Machen wir dann ein neuen record, oder schauen wir, dass die minister-records auch fr
> mehrere Posten ausgelegt sind....
> ...dass wir das Integer-Feld admin_type mit mehreren mit logisch Oder kombinierbaren definie()s
> fllen (du verstehst was ich meine, nicht ?).
Wei zwar nicht was du mit "definie()" meinst, ich hoffe aber doch, dass ich zumindest das Konzept verstanden hab:
jedes Bit des int bedeutet ein anderes Amt?
Bin ich eher nicht so dafr. Das wird einfach zu kompliziert.
Man soll ja auch gleichzeitig mter in verschieden Gruppen ausben drfen. (z.B. Supervisor)
Mach mer einfach einen neuen Record mit dem passenden Datum(szeitraum)/ LegislaturperiodeID/aktuell-Bitgesetzt. (s.o.)
Puuh, das wird langsam richtig kompliziert, ich habe mir das nochmal durchdacht und bin zu folgendem Ergebnis gekommen (bisschen ein neuer Ansatz):
TABLE democ4phpbb_minister {
int minister_id (primary key)
int user_id
boolean can_get_ministry (ist true, wenn dieser user ein Ministerium bernehmen kann)
};
Wer einmal in dieser Tabelle drin ist (also, wer schon mal minister war, bleibt auch drin und wird nicht mehr gelscht, auch wenn er sein Amt aufgibt).
TABLE democ4phpbb_ministry{
int ministry_id (primary key)
int minister_id (die id von dem minister, der gerade dieses Amt hat)
int group_id (Group-ID von der Gruppe, ber die man Macht hat, wenn man dieses Ministerium hat)
}
In der Tabelle ist nur, wer gerade aktiv ein Amt ausbt. Bei einem Amtswechsel wird nur die minister_id ausgetauscht.
TABLE democ4phpbb_action{
int action_id (primary key)
int minister_id (wer hat das gemacht)
int ministry_id (welches Amt hatte er)
int action_type (was hat er gemacht)
text comment (mit was hat er das, was er gemacht hat begrndet)
int victim (mit dem hat er das gemacht ? Group-Id oder User-Id)
int group_or_user (hat er das, was er gemacht hat mit einer Gruppe oder mit einem User gemacht)
date timestamp (wann hat er das gemacht)
}
Wer irgenetwas macht (zensiert, gewhlt wird, aus dem Amt geschmissen wird ...) wird hier gelogged. So knnen wir perfekt rekonstruieren, was wer gemacht hat. Ich glaube die Felder sind allgemein genug, so dass wir alle mglichen Sache, die passieren, hier aufzeichnen knnen.
Was hlts du auch von folgenden Datenstrukturen:
TABLE democ4phpbb_elector{
int elector_id (primary_key)
boolean voted (hat er schon gewhlt)
boolean allowed_to_vote (darf er whlen ?)
int user_id (wer ist er ?)
}
TABLE democ4phpbb_candidate{
int candidate_id (primary_key)
int ministry_id (wofr bewirbt er sich)
int minister_id (wer ist er (1)?)
int user_id (wer ist er (2)?)
int votes (wieviele Stimmen hat er ?)
}
P.s: in der CVS-Rubrik kannst du meine bescheidenen Erfolge im Umgang mit CVS sehen.
Bis denn,
MaJo
gibt es einen speziellen Grund, warum du eine zustzliche tabelle willst: democ4phpbb_minister?
es wrde ja meiner Ansicht nach reichen, wenn wir in democ4phpbb_ministry einfach statt der minister_id die user_id reinnehmen?
Das ganze kostet einigen unntigen Aufwand (v.a. Performance), da man bei jeder Abfrage die zwei Tabellen verknpfen muss: "...WHERE democ4phpbb_minister.minister_id = democ4phpbb_ministry.minister_id..."
die einzige zustzliche Info ist "can_get_ministry"
Frage: Wann genau soll jemand KEIN Amt bekommen drfen?
Beginn und Ende des Amts fehlen noch.
auerdem wrd ich in democ4phpbb_ministry noch reinnehmen: "ministry_type", also z.B.
1.Moderator, 2.Moderator, Supervisor usw.
Bei allgemeinen mtern einfach: group_id=0
Bei democ4phpbb_action.comment: wird vielleicht kompliziert, das einzubauen.
Am Rande: victim klingt so negativ. Wie wrs mit "affected"?
democ4phpbb_elector:
warum zwei ID's benutzen: userid und electorid?
beim phpbb-vote-System heit die Tabelle brigends phpbb_vote_voters
mit den Feldern vote_id , vote_user_id , vote_user_ip
Wobei vote_id die nummer der Abstimmung ist.
Und quasi fr jeden abgegebenen "Stimmzettel" ein Record angelegt wird.
Frage: Aus welchen Grnden wollen wir jemanden ausschlieen?
Du hast jetzt 2mal ein Feld, um jemand auszuschlieen.
Wie oft soll das vorkommen? Soll z.B. ein User erst ab einem bestimmten Mitgliedszeitraum whlen/gewhlt werden knnen?
Dann knnen wir das einfacher ber "phpbb_users.user_regdate" regeln.
oder soll einer gebannt werden knnen?
Dann wrs vielleicht einfacher mit einer sog. "Blacklist". Denn so oft soll das ja nicht vorkommen, oder?
Oder soll einer bis zur genaueren Authentifikation (z.B. uns Ausweis zeigen) kein Vollmitglied sein?
Dann wre vielleicht ein zustzliches Feld in phpbb_users praktischer.
zu democ4phpbb_candidate:
zur Unterscheidung von user_id und minister_id : siehe oben.
zu ministry_id:
wir mssen mal klar definieren:
ist ministry_id einmalig?
und: vielleicht sollten wir das eher ber minister_type und minister_group regeln?
Ansonsten hab ich nix dran auszusetzen.
..oder....was hltst du von einer election_id fr alle Tabellen die mit Wahlen zu tun haben?
Falls mal z.B in einem Forum ne unvorhergesehene Neuwahl stattfinden soll, damit die sich nicht mit einer andern laufenden Wahl ins Gehege kommt?
>gibt es einen speziellen Grund, warum du eine >zustzliche tabelle willst: >democ4phpbb_minister?
1) Wir knnen damit den Teil, der sich immer verndert an einer Stelle speichern und den Teil, der sich immer verndert an einer anderen Stelle.
2) Wir knnen Daten, die mit einen Minister zu tun haben, an einer Stelle speichern (wie z.B. das can_get_ministy-Feld. Ok, das war vielleicht ein dummes Beispiel, aber wenn wir nachdenken wird uns sicher etwas einfallen, wo man das brauchen kann. Zugegeben, wenn wir can_get_ministry weglassen sieht democ4phpbb_minister ziemlich berflssig aus).
Was meinst du ? Sollen wir das in 2 Tabellen aufspalten ?
Wir knnen uns die Option ja mal offenhalten, eine Tabelle democ4phpbb_minister zu machen, wenn wir was finden, was wir als spezifische Daten fr einen Minister speichern wollen. Diese Tabelle dann einzubinden drfte ja nicht so schwer sein.
>es wrde ja meiner Ansicht nach reichen, wenn >wir in democ4phpbb_ministry einfach statt der >minister_id die user_id reinnehmen?
ok, berredet.
>Beginn und Ende des Amts fehlen noch.
Brauchen wir das berhaupt ? In democ4phpbb_minister hat das nicht zu suchen (dann wrden wir Probleme kriegen, wenn jemand 2 mter hat oder jemals gehabt hat). In democ4phpbb_ministry hat das auch nichts zu suchen, weil wie ich es mir gedacht habe nur Leute, die _aktiv_ einen Posten haben einen record in democ4phpbb_ministry haben.
Jeder Ministerwechsel wird als action in democ4phpbb_action aufgezeichnet. Wenn wir also rekonstuieren wollen, was passiert ist, mssen wir halt schauen wer wann was war.
>auerdem wrd ich in democ4phpbb_ministry noch >reinnehmen: "ministry_type", also z.B.
>1.Moderator, 2.Moderator, Supervisor usw.
>Bei allgemeinen mtern einfach: group_id=0
gut
>Bei democ4phpbb_action.comment: wird vielleicht >kompliziert, das einzubauen.
Wieso ? (ich habe mit DBs noch nicht so viel gemacht)
>Am Rande: victim klingt so negativ. Wie wrs >mit "affected"?
ok, habs gendert
>democ4phpbb_elector:
>warum zwei ID's benutzen: userid und electorid?
Stimmt, eins ist berflssig. Nehmen wir elector_id raus. allowed_to_vote knnen wir auch rausnehmen (weil wir nocht nicht wissen, ob das gut ist, wenn wir das so implementieren).
>Dann wrs vielleicht einfacher mit einer sog. >"Blacklist". Denn so oft soll das ja nicht >vorkommen, oder?
Ja, das erscheint mir auch als der richtige Weg zu entscheiden, wer nicht whlen darf.
>zu democ4phpbb_candidate:
>ist ministry_id einmalig?
Wenn der User gewinnt, wird aus democ4phpbb_ministry der record herausgesucht, der die ministry_id hat und dann wird dieser record so angepasst, dass er auf den neuen User zugeschnitten ist.
>und: vielleicht sollten wir das eher ber >minister_type und minister_group regeln?
Wir brauchen aber auf jeden Fall ministry_id, weil wir das ja in democ4phpbb_action brauchen.
>..oder....was hltst du von einer election_id >fr alle Tabellen die mit Wahlen zu tun haben?
Finde ich gut. Dann brauchen wir aber noch eine Tabelle, in der election_id primary key ist und in der wir dann genauer sagen, was das fr eine Wahl ist (ich hab das mal dazugemacht).
Mit obrigen nderungen sehen die Tabellen so aus
**************************************
TABLE democ4phpbb_ministry{
int ministry_id (primary key)
int user_id (die id von dem user, der gerade dieses Amt hat)
int group_id (Group-ID von der Gruppe, ber die man Macht hat, wenn man dieses Ministerium hat; bei allmchtigen Gruppen: group_id=0)
int ministry_type (was ist das fr ein Amt ?)
};
TABLE democ4phpbb_action{
int action_id (primary key)
int user_id (wer hat das gemacht)
int ministry_id (welches Amt hatte er)
int action_type (was hat er gemacht)
text comment (mit was hat er das, was er gemacht hat begrndet)
int affected (mit dem hat er das gemacht ? Enthlt Group-Id oder User-Id, je nachdem)
int group_or_user (hat er das, was er gemacht hat mit einer Gruppe oder mit einem User gemacht)
date timestamp (wann hat er das gemacht)
};
TABLE democ4phpbb_elector{
int election_id
boolean voted (hat er schon gewhlt)
int user_id (wer ist er ?)
};
TABLE democ4phpbb_candidate{
int election_id
int candidate_id (primary_key)
int user_id (wer ist er ?)
int votes (wieviele Stimmen hat er ?)
};
TABLE democ4phpbb_election{
int election_id (primary key)
int ministry (worum geht die Wahl)
int group_id (wer darf whlen)
date begin (wann hat die Wahl begonnen)
date end (wann hrt die Wahl auf)
}
***********************************************
Vorschlag:
wir nehmen berall statt date datetime. Dann ist die Uhrzeit auch noch drin:
datetime democ4phpbb_action.timestamp
datetime democ4phpbb_election.begin
datetime democ4phpbb_election.end
sollen wir in democ4phpbb_action und die IP, von der aus das gemacht wurde, auch noch reinnehmen? (in phpBB2 wird die bei jedem Beitrag aufgezeichnet.)
und in democ4phpbb_elector? Wie gesagt, in phpbb_vote_voters ist die auch drin.
>>Bei democ4phpbb_action.comment: wird vielleicht >kompliziert, das einzubauen.
>Wieso ? (ich habe mit DBs noch nicht so viel gemacht)
von der DB her nicht schwer, aber dann mssen wir phpBB so ndern, dass vor jedem Lschvorgang nach dem Grund gefragt wird.... Ok, wir knnens ja versuchen.
Bei unsere democ4phpBB-Oberflche ist es natrlich kein Problem, da knnen wirs von Anfang an problemlos einbauen.
Frage: wollen wir die gelschten Beitrge irgendwie sichern? (vielleicht als Beweismittel?)
Dann bruchte man fast noch ein Feld mit affected_post_id als Zeiger auf die "Papierkorb"-Tabelle.
>Vorschlag:
>wir nehmen berall statt date datetime. Dann >ist die Uhrzeit auch noch drin:
>datetime democ4phpbb_action.timestamp
>datetime democ4phpbb_election.begin
>datetime democ4phpbb_election.end
Gut, einverstanden
>sollen wir in democ4phpbb_action und die IP, >von der aus das gemacht wurde, auch noch >reinnehmen? (in phpBB2 wird die bei jedem >Beitrag aufgezeichnet.)
Einverstanden.
>und in democ4phpbb_elector? Wie gesagt, in >phpbb_vote_voters ist die auch drin.
Ja, wieso nicht
>Frage: wollen wir die gelschten Beitrge >irgendwie sichern? (vielleicht als >Beweismittel?)
Das knnten wir nicht nur als Beweismittel nehmen, sondern wenn ein Moderator irgendwann mal bereut, was gelscht zu haben, dann kann er das wieder rckgngig machen. Andererseits hat das glaube ich auch noch ein bisschen Zeit.
>Dann bruchte man fast noch ein Feld mit >affected_post_id als Zeiger auf die >"Papierkorb"-Tabelle.
Wo dieser Zeiger ? In democ4phpbb_action ?
Wie gesagt, ich glaube aber das das noch ein bisschen Zeit hat.
Ich habe jetzt mal die Datenstrukturen in MySQL-Syntax ins CVS-Repository unter democ4phpbb/doc/mysql_schema.sql reingetan, damit wir mal was festes, ofizielles haben. Schau's dir aber ruhig mal an, ich hab mit Datenbanken noch nicht so viel gemacht.
>>Vorschlag:
>>wir nehmen berall statt date datetime. Dann >ist die Uhrzeit auch noch drin:
>datetime democ4phpbb_action.timestamp
>datetime democ4phpbb_election.begin
>datetime democ4phpbb_election.end
ich habe anstatt datetime int(11) genommen. Die bei phpBB2 machen das auch so. Es knnte sein, dass datetime nicht auf jeder SQL-Platform vorhanden ist.
wahrscheinlich. Mit einem UNIX-Timestamp kann man auch viel leichter rechnen, z.B. Zeitrume, verschiedene Zeitzonen usw.
wir knnen auch voted tinyint(1) DEFAULT '0'
auch weglassen, und bei der Wahl einfach einen Eintrag in die Tabelle machen.
Siehe phpbb_vote_voters ;-)
Dann belegen die Nichtwhler auch keinen Platz.
und ums einheitlich zu machen:
statt: CREATE TABLE democ_ministry
CREATE TABLE democ_office
Sonst ist eigentlich alles in Ordnung