Meeting Mod - begrenzen der Gesamtteilnehmerzahl

[fwl]

Hallo Karsten Ude!

Dann schlage ich vor es hier fortzusetzen, dann steht alles zusammen.

Hier mein bisheriges Ergebnis:

phpbb_meeting_data erweitern um Feld

meeting_names tinyint(1)

um zu erfassen, ob Namen gepflegt werden müssen.

Das Formularstück dazu:

[code] <tr>
<td class="row2"><span class="nav">Namentliche Anmeldung

</span></td>
<td class="row1"><p>
<span class="gensmall">&nbsp;
<span class="genmed1">
<input type="radio" name="meeting_names" value="1" />Ja&nbsp;&nbsp;
<input type="radio" name="meeting_names" value="0"

checked="checked" />Nein</span>
</span></p>
</td>
</tr>[/code]
#####


Tabellenstruktur für neue Tabelle meeting_teilnehmer

ID mediumint(8)
meeting_id mediumint(8)
user_id mediumint(8)
meeting_edit_time Datum
Vorname text(25)
Nachname text(25)
Kategorie mediumint(8)
geloescht Datum
user_id_Loeschung mediumint(8)
bbcode_uid varchar(10)

Wozu wird das Feld bbcode_uid benötigt?

Tabellenstruktur für neue Tabelle meeting_kategorien

ID mediumint(8)
Kategorie text(25)

Eingabe der Kategorien nur durch Administratoren (evtl. im ACP)


#####

Programmablauf

Wenn meeting_names = 1 dann in neuen Programmteil verzweigen, sonst bestehender Code;


neues Eingabeformular verarbeiten;


Benutzer kann solange Datensätze mit Namen hinzufügen, bis:

(erfasste Anzahl) = (maximale Anzahl Plätze)

oder (durch Benutzer erfasste Anzahl) = (Anzahl Gäste, die ein Benutzer max. einladen

darf)


Formularanfang dazu:

<form name="form1" method="post" action="eintragen.php">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td>Vorname</td>
<td>Nachname </td>
<td>Kategorie</td>
</tr>
<tr>
<td><input name="varVorname" type="text" id="ort" size="20" maxlength="60"></td>
<td><input name="varNachname" type="text" id="ort" size="20" maxlength="60">

</td>
<td>
<select name="varKategorie" size="1" id="ort" type="text"

maxlength="60"></select></td>
</tr>
</table>
<input type="submit" name="Submit" value="Teilnehmer hinzufügen"> <input name="leeren"

type="reset" id="leeren" value="Zur&uuml;cksetzen">
</form>

#####

Abfrage für die Anzeige der Teilnehmer:

SELECT meeting_teilnehmer.*, meeting_teilnehmer.meeting_edit_time
FROM meeting_teilnehmer
WHERE (((meeting_teilnehmer.geloescht) Is Null))
ORDER BY meeting_teilnehmer.meeting_edit_time;


Ausweis nach Kategorien

SELECT meeting_kategorien.Kategorie, Count(meeting_teilnehmer.ID) AS [Anzahl]
FROM meeting_kategorien LEFT JOIN meeting_teilnehmer ON meeting_kategorien.ID =

meeting_teilnehmer.meeting_id
WHERE (((meeting_teilnehmer.geloescht) Is Null))
GROUP BY meeting_kategorien.Kategorie;


Dazu sollte noch die Gesamtanzahl ausgegeben werden.

#####

Zum Löschen sollten die Berechtigungen wie im bisherigen Mod verwandt werden.
Anstelle einer Löschung des Datensatzes soll nur ein Zeitstempel der Löschung erfasst

werden, sowie der Nutzer, der die Löschung eingetragen hat. Angezeigt werden brauchen

diese Felder nicht. Im Bedarfsfall könnte man in der DB nachsehen.


#####

Welche Informationen sind noch erforderlich?

Kannst du mit den Formularstücken etwas anfangen oder was soll ich etwas daran ändern?

Viele Grüße und vielen Dank

fwl

[oxpus]

Vielen Dank schon einmal für die Aufstellung.
Ich schaue mir das am WE genauer an und bastel das dann in die nächste Version mit ein.

Zunächst aber ein *daumenhoch* Danke für die prima Arbeit!

[oxpus]

Eine Frage hätte ich zu Deinen Ausführungen:
Warum soll der Gast nicht komplett gelöscht werden, wenn ein User den nicht eintragen will?
Könnte ja auch ein "Versehen" sein.
Anmelden und ändern kann man ja schliesslich bis zur Anmeldefrist und wenn die "überflüssigen" Namen tot in der Datenbank stehen, wäre das unnötiger Datenschrott...

Und was soll es mit den Kategorien auf sich haben?

[fwl]

Hallo Karsten!

Mit dem möglichen Versehen hast du Recht, jedoch möchte ich die Daten aus zwei Gründen in der DB behalten.
1. Kann ich so nachvollziehen, was wann eingetragen war. (Dokumentationfunktion)
2. Kann ich mir vorstellen, diese Daten evtl. später mal auszuwerten.

Ein mögliches Anwendungsbeispiel wäre z.B. ein Ranking für einen anderen Termin. Die Idee dabei wäre, die Personen zu belohnen, die sich kooperativ verhalten hat.
Konkret, wer angemeldet war und erschienen ist, erhält ein Positivmerkmal.
Wer angemeldet war und nicht erschienen ist oder erst unmittelbar vor einem Termin abspringt, so dass ein anderer nicht mehr nachrücken kann, erhält ein Negativmerkmal.
Wer sich rechtzeitig abmeldet und so dazu beiträgt, die Veranstaltungen optimal auszulasten, erhält ebenfalls ein Positivmerkmal.

Wenn die Daten in der DB verbleiben, kann man nach Sammlung einer entsprechenden Datenbasis ganz gute Aussagen ableiten. Insofern ist es für mich kein Datenmüll; ich kann deine Argumentation aber verstehen.

Die Teilnehmer können in verschiedene Gruppen eingeteilt werden. Für statistische Zwecke würde ich deshalb gerne das Merkmal mit speichern. Da die Gruppen aber fest vorgegeben sind, reicht es vollkommen, wenn nur Admins die Kategorien pflegen können. Das Feld kann auch anders genannt werden, wenn dir das besser gefällt.


Viele Grüße und vielen Dank

fwl

[oxpus]

Nochmal zu den Namen:
Warum diese weiter aufheben, wenn dieser Mensch nicht kommt? Eine Abmeldung kann man hier ja auch nach der "Anmeldefrist" sperren und nur noch den User selber abmelden lassen (der bliebe dann ja auch stehen).

Und Kategorien:
Auch wenn ich das Kind umbenenne, will sich der Zweck der Übung mir nicht erschliessen. Sorry.
Kann ich einbauen, kein Thema, aber User/Gäste in "Kategorien" einteilen...

[fwl]

Hallo Karsten!

Mir erscheint es sinnvoll, etwas zu den Hintergründen zu erklären, statt auf der abstrakten Ebene zu bleiben.

Der konkrete Einsatz ist in einem Bord für eine freiw. Feuerwehr gedacht. Damit sollen dann Plätze bei bestimmten Schulungen verwaltet werden. Dieser Anwendungszweck ist aber sehr speziell, deshalb hatte ich versucht, die Lösung so abstrakt zu halten, dass auch andere Vereine die neuen Möglichkeiten nutzen können. Ich kann mir nämlich auch entsprechende Fälle in anderen Vereinen denken, wo prinzipiell die selben Features benötigt werden, diese nur andere "Namen" haben.

Konkret zu den Kategorien:
Für eine Feuerwehr wären das die Löscheinheiten (also organisatorische Teile). Andere Vereine unterscheiden zwischen Jugendabteilung und verschiedenen Mannschaften. Deshalb hatte ich als möglichst offene Bezeichnung "Kategorie" gewählt.
Bei der Feuerwehr z.B. kann die Anforderung vorgegeben werden, bestimmte Kontingente an bestimmte Löscheinheiten zu vergeben. (Deshalb auch die Abfrage gruppiert nach diesem Merkmal.) Programmtechnisch braucht diese Kontingentierung aber nicht implementiert zu werden, da
1. dies zu speziell und
2. dies nicht jedes Mal gefordert wird und
3. sich dies durch den Admin regulieren läßt.

Ein Vorschlag zur Implementierung im Mod: Wenn man dieses Feld mit anlegt und im Quelltext auskommentiert und in der Dokumentation auf dieses Feature hinweist, stört es andere Nutzer nicht, läßt sich aber bei Bedarf leicht aktivieren.

Zur Erfassung der Teilnehmer:

Leider lassen sich nicht immer alle Wünsche der Teilnehmer erfüllen, da z.B. die Zahl der Plätze begrenzt ist, und es ist erforderlich, gewisse Vorgaben der Leitung umzusetzen (z.B. falls die oben beschriebene Kontingentierung für einen Termin vorgegeben wird).
Um dann die nachvollziehbare Enttäuschung nicht so groß werden zu lassen, ist es wichtig, dass die Entscheidungen objektiv begründbar und nachvollziebar sind. Bei entsprechender Transparenz sind die Vereinsmitglieder bereit, auch unangenehme Entscheidungen mit zu tragen.

Diese Transparenz läßt sich nur erreichen und objektiv darstellen, wenn die Daten gespeichert bleiben und man sehen kann, Wer Wann Wen abgemeldet hat. Ansonsten kommen schnell Diskussionen auf, die auf nicht nachvollziehbaren Aussagen beruhen (z.B. Der hat aber schon dann ...). Allein das Wissen der Mitglieder, dass diese Fälle (sind zum Glück Einzelfälle) geklärt werden können, schafft Vertrauen und Akzeptanz.

Später kann man wie schon beschrieben die Daten auch für die faire Verteilung nutzen, denn bei den Terminen handelt es sich um Schulungsmaßnahmen, die von den meisten sehr begehrt sind, aber nur begrenzt zur Verfügung stehen, nach einer Zeit aber wieder angeboten werden.

Ein Vorschlag zur Implementierung im Mod:
Man könnte die Daten gespeichert lassen wie beschrieben und für die Vereine, die die Lösung der Daten wollen, einen Aufruf für eine Löschabfrage anlegen.

Ein entsprechendes SQL-Statement kann ich erstellen, wenn das hilft.

Ich hoffe, die Ausführungen waren nicht zu lang, sondern haben zum Verständnis der Spezifikation beigetragen. Ich hatte diese anfangs nicht mit aufgeführt, da es sich nicht um technische Beschreibungen handelt, sondern es sehr schwammige Bescheibungen "weicher" Faktoren sind.

Ist das so für einen Außenstehenden verständlich oder soll ich noch etwas näher erklären?

Viele Grüße und vielen Dank

fwl

[oxpus]

Soweit verstanden, aber:
Wenn Du bestimmte User/Kollegen zu Treffen einladen willst, warum dann nicht die betreffenden Personen im beschreibenden Text ansprechen und auch die Usergruppen im phpBB einteilen, damit auch nur diese User anmelden können?
Du hättest ja sonst 2mal Gruppen zu pflegen und im MOD zu berücksichtigen (bei was auch immer)...
Und nochmal: Gespeichert blieben ja alle Namen und damit auch die Zuordnungen zu den Benutzern, die die Gäste mit eingeladen haben.
Eine zusätzliche Einteilung der angemeldeten Vereinsmitglieder halte ich daher für überflüssig, da man eben auf Usergruppen zurückgreifen kann und bei falschen Anmeldungen diese zum einen durch einen Admin/Mod oder Meeting-Ersteller ausladen, bzw. in einem persönlichen Gespräch auf den "Fehler" hinweisen kann.
Denn auch mit Kategorien muss ja ein Mitglied ja erst einmal eingeteilt werden, was wiederum die mögliche Anzahl an Fehlern erhöht.
Und bei einer Feuerwehr, die meherere Hundert Mitglieder haben kann (oder bleiben wie allgemeiner bei einem Verein) mit z. B. 20 "Kategorien" würde wohl kaum einer fleissig seine Gäste einteilen wollen, oder?

Kurzum:
Sicher kein Problem, sowas zu programmieren, aber ich halte es immer noch für schlicht überflüssig und übertrieben, die Gäste nochmal einzuteilen. Schliesslich ist ja der Kamarad, der einlädt für diese Einladungen verantwortlich.
Und die namen der Gäste kann man ja durch ein Popup auch aufrufbar gestalten, damit diese immer nachvollzogen werden können.
Also wer wann wen eingeladen hat.
Die ausgeladenen Gäste hätte ich dann einfach auch wirklich gelöscht, denn diese interessieren ja nicht wirklich...

[fwl]

Hallo Karsten!

Wenn Du bestimmte User/Kollegen zu Treffen einladen willst, warum dann nicht die betreffenden Personen im beschreibenden Text ansprechen und auch die Usergruppen im phpBB einteilen, damit auch nur diese User anmelden können?

Eine Begrenzung auf bestimmte Gruppen ist eher unwahrscheinlich. Begrenzt wird eher die Anzahl je Kategorie. Das soll aber nicht die Entwicklung stören. Wenn da was schief geht, wird das ein Admin richten.

Du hättest ja sonst 2mal Gruppen zu pflegen ...

Prinzipiell richtig, da funktionale und räumliche Trennung. Aber den räumlichen Aspekt könnte man einfach mit den Kategorien abhandeln. Wenn ich die Zuordnung über phpbb-Gruppen mache, dann muss ich das ja für alle möglichen User machen. Das wäre auch machbar, scheint mir aber deutlich größerer Aufwand zu sein.

Und nochmal: Gespeichert blieben ja alle Namen und damit auch die Zuordnungen zu den Benutzern, die die Gäste mit eingeladen haben.
Eine zusätzliche Einteilung der angemeldeten Vereinsmitglieder halte ich daher für überflüssig, da man eben auf Usergruppen zurückgreifen kann und bei falschen Anmeldungen ...

Die Benutzer sollen ruhig auch Gäste aus verschiedenen Kategorien erfassen dürfen. (Die zusätzliche Fehlerquelle nehme ich in Kauf.) Insofern gibt es da keine Fehler. Ich möchte nur nachträgliche Abmeldungen dokumentiert haben.
Wenn ich das richtig sehe, besteht der Unterschied zwischen Datensatz löschen und als gelöscht eintragen ja nur in der SQL-Anweisung und der Tabellenstruktur. Deshalb mein Vorschlag, wir lassen diesen Punkt erstmal aus, das ist ja nichts Grundlegendes für die Funktionsweise des Mods.

Kann ich noch irgendwie helfen?

Noch zwei Fragen zum Quelltext: Was bedeutet "->" und "=>" in php? Da es Sonderzeichen sind, funktioniert leider die Suche danach nicht. Sind das Variablenzuweisungen oder was?

Viele Grüße und vielen Dank für Deine Mühe.

fwl

PS: Die nächsten zwei Tage werde ich kaum zum Antworten kommen. Wenn also noch was offen ist, müssten wir das ab Samstag klären.

[oxpus]

Der Aufwand mit Kategorien wird hierbei lediglich auf die User verlagert, die selbige mit angeben müssten.
Wenn Du die User aber bereits in Gruppen einteilst, können sich von vornherein nur diese auch am Meeting anmelden, sofern selbiges entsprechend erstellt wurde.
Dann sind Fehler schon einmal eher ausgeschlossen...

Und zu den Gastnamen:
Es geht mir nicht um die SQL-Anweisung, einen Gast per DELETE oder UPDATE loszuwerden, sondern den beim UPDATE erzeugten Datenmüll.
Auch wenn aktuell die Webspacegrössen "explodieren", so wird bei wachsender Datenbank eben genau diese auch langsamer.
Und das gilt es ja möglichst zu vermeiden
Ebenso braucht diese Daten wohl wirklich kaum noch jemand, ob Hr. Meier zum Meeting 47/11 angemeldet und wieder abgemeldet wurde. Interessanter wäre doch, wer wurde überhaupt zum Stichtag angemeldet und kam davon auch, oder nicht?

[fwl]

Hallo Karsten!

... Aufwand mit Kategorien wird hierbei lediglich auf die User verlagert ...

Mit dem Unterschied, dass die User das nur für die teilnehmenden Gäste pflegen müssten, zu einer Erfassung für alle theoretisch möglichen Gäste.

...User aber bereits in Gruppen einteilst...

Die Gäste sollen eingeteilt werden, nicht die User. Evtl. haben wir da aneinander vorbei geredet.

Ebenso braucht diese Daten wohl wirklich kaum noch jemand, ob Hr. Meier zum Meeting 47/11 angemeldet und wieder abgemeldet wurde. Interessanter wäre doch, wer wurde überhaupt zum Stichtag angemeldet und kam davon auch, oder nicht?

Das ist auch interessant. Die späten Abmelder sind aber auch interessant:

Folgendes Szenario:
Angenommen, es stehen nur 10 Plätze zur Verfügung bei 50 Interessierten.
Wer jetzt nicht teilnimmt, muss 6 Monate warten, bis erneut 10 Plätze zur Verfügung stehen. Nach der Terminveröffentlichung beginnt der Wettlauf um die Plätze. Eine Person, die weiß, dass sie evtl. einen anderen Termin an diesem Tag hat, reserviert sich trotzdem einen Platz, da sie ja evtl. teilnehmen kann.
Die 40, die keinen Platz bekommen haben, verplanen den Termin anderweitig.
Von den 10 Teilnehmern scheiden einige durch Krankheit plötzlich aus und melden sich ab. Damit die freigewordenen Plätze nicht verfallen, setzt der Admin den Anmeldetermin auf unmittelbar vor der Veranstaltung, in der Hoffnung, dass sich noch schnell jemand anmeldet.
Das System klappt, solange die Abmeldungen früh erfolgen, dass die anderen Interessierten noch nichts anderes vorhaben.

Problematisch ist aber, dass Personen, die angemeldet sind, keinen Vorteil haben, wenn sie ihre Information über den Ausfall frühzeitig weitergeben.

Jetzt sucht man nach einer Möglichkeit, kooperatives Verhalten (z.B. eine frühzeitige Abmeldung, die einem Anderen eine Teilnahme ermöglicht) zu belohnen.
Die Möglichkeit, ein Pfand zu hinterlegen, scheidet aus. Deshalb ist die Idee, die begehrten Plätze als Motivationsgrundlage zu nutzen.
Das wäre möglich, wenn in Folgeterminen von der Regel "nach Anmeldereihenfolge" abgewichen würde und die Reihenfolge aus dem bisherigen Verhalten hergeleitet wird. Dazu wären die Daten nützlich.

Wenn das aber zu speziell ist, dann lassen wir das.

Zu den "->" Zeichenfolgen habe ich schon herausgefunden, dass es sich um Aufrufe von Instanzvariablen handelt.
Wann wird "=>" verwendet?

Viele Grüße und vielen Dank für Deine Mühe.

fwl