Termine Erweiterung oder neu

[rpinto-mpunkt]

Hallo,

wir wollen die Terminverwaltung (Modul: Dates/Termine) gehörig erweitern. Dazu gehört z.B. auch Serientermine einzuführen. Weiterhin wollen wir das Registrieren für einen Termin sowohl für Mitglieder als auch Nicht-Mitglieder einführen, somit auch eine Kontingentierung um die Größe der Gruppe zu beschränken.

Einerseits denke ich, dass man das vorhandene Modul um die zusätzlichen Features erweitern könnte. Allerdings kommen dadurch vielleicht zu viele neue Features hinzu die das Gros der Benutzer gar nicht braucht.

Meine Frage ist jetzt: Sollen wir eher ein neues Modul schreiben, vielleicht den jetzigen Stand des dates-Modul übernehmen oder dieses eher anpassen? Mir wäre ersteres lieber.
Selbstverständlich würden wir dafür sorgen, dass gewünscht Features, die sowieso implementiert werden müssen und im Feature Tracker stehen (wie die Serientermine) auch in das Originalmodul einfliessen.

Hier noch mal eine Auflistung der Features die wir hinzufügen wollen:

• Teilnehmer
  • Registrierung von Teilnehmern
  • Beschränkung der Teilnehmer auf bestimmte Benutzergruppen und/oder Anzahl
  • Download der Teilnehmerliste als CSV
  • ...
• Serientermine
• Ort aus Liste auswählbar
  • Raumnummer => max. Teilnehmerzahl
  • Belegungsplan der Räume

Welches Vorgehen ist zu Empfehlen? Neues Modul, "branchen" des Vorhandenen, Erweitern des Vorhandenen?
Soll auf Basis des 2.1.5er Releases entwickelt werden oder auf Basis des trunks oder branches (welchem) im SVN?
Soll in diesem SVN entwickelt werden oder in einem eigenen?

Auf möglichst viele (und passende ) Antworten freut sich
Euer
Raul

[fasse]

Hallo Raul,

das hört sich ja auf Anhieb sehr interessant an, was du/ihr da vor habt. Viele Punkte die du ansprichst, sind bei uns auch schon seit längerem auf der Wunschliste.

So wie ich das aus deinem Post verstehe, willst du das Terminmodul für Kurse nutzen, bei denen sich Mitglieder und nicht Mitglieder anmelden können ?!?

Einbauen würde ich Ganze in unseren Trunk. Der Branch macht bei solch weitreichenden Veränderungen keinen Sinn und die eigentliche Weiterentwicklung von Admidio sollte im Trunk geschehen. Ansonsten macht man sich das Leben auch nur künstlich schwer, da ihr eure Branch-Anpassungen irgendwann dann auch in einen weiterentwickelten Trunk übernehmen müsstet, falls die Features in zukünftigen Admidio-Versionen weiter enthalten sein sollen.

Nun zu deinen Featuren:
- Die Serientermine sind schon lange gewünscht und sollten dann auch in unser Terminmodul integriert werden. Da brauch ich eigentlich nicht mehr viel zu zu schreiben.

- bei deinen anderen Funktionen sollten wir uns mal überlegen, was hier die sinnvollste Integration ist. Falls du diese Erweiterung für eine Kursverwaltung brauchst, dann sollte man überlegen, inwieweit man unser Rollensystem hier mit integrieren kann. Kurse oder ähnliches soll eigentlich durch Rollen dargestellt werden. Bisher kann man bei Rollen schon "Termine" angeben, wenn auch stark eingeschränkt und die Verknüpfung zum Terminmodul fehlt auch. Erweitert man dies aber, so könnte ich mir vorstellen, dass man hier zu dem Kurs (Rolle), x Termine (Serientermine) definieren kann. Diese werden dann automatisch in das Terminmodul übernommen. (Die Konfiguration von Serientermine bei der Rolle und im Terminmodul könnte man zusammen nutzen). Orte und max. Teilnehmerzahl würde man bei der Rolle angeben.

Der Vorteil, dies über Rollen zu machen, wäre der, dass du später viele Funktionen der Rolle (Teilnehmerlistenausgabe, Rechteverwaltung) nutzen könntest. Aber evtl. habe ich auch deinen Anwendungszweck falsch gedeutet. Schreib am Besten mal, was hinter deinen Überlegungen steht.

Viele Grüße
Fasse

[rpinto-mpunkt]

Hallo Fasse,

habe mich gerade mit den Rollen auseinandergesetzt. Die "Termine" die man dort einträgt sind ja, zumindest derzeit, eher ein aufgebohrter Beschreibungstext So lange die nicht im Kalender eingetragen werden macht das wohl wenig Sinn. Aber gut, kann man ja ändern

Was ich jetzt auch noch nicht verstanden habe ist, wie sich ein Benutzer für eine bestimmte Rolle sozusagen "bewerben" oder ihr direkt beitreten kann, also die Opt-in-Funktionalität. Dass nur der Leiter oder ein Admin jemand hinzufügen kann ist nicht in unserem Sinne...
Es könnte auch durchaus sein dass so ein "Kurs" (nennen wir so einen Termin mal so) auch nur ein mal stattfindet. Soll aber die weiteren Features, wie Raum, Teilnehmerliste etc. weiterhin behalten. Dafür jedes mal eine neue Rolle anzulegen mit der Auswahl der Rechte fände ich ein wenig übertrieben.

Was mir gerade auch noch einfällt ist das Kopieren von solchen Terminen/Kursen. Also, dass man sagt: So etwas wie ich jetzt machen will ist sehr ähnlich zu dem was ich vor einem Jahr schon mal gemacht hab. Und dann kopiert man den und passt ihn an.

Hast du dir generell schon mal Gedanken zu Verknüpfungen zwischen Modulen gemacht? Also wie würdest du die Kurse aus dem roles-Modul in das date-Modul eintragen? Über eine API, eine Klasse oder doch direkt in "seine" Datenbank schreiben?
Weil so könnte man sich auch überlegen so ein "Meta-Modul" oder "Mashup" aus den Modulen zu machen um auf alle gewünschten und schon implementierten Features zurückgreifen zu können.

Im Sinne von: Man legt einen Termin an über das date-Modul, aktiviert die Kontigentierung und erstellt so eine "versteckte" Rolle in die Benutzer (und nicht-Benutzer) sich eintragen können (eben durch einen Klick auf den Termin im Kalender). Der Ersteller des Termins kann auch noch andere zu Leitern des Kurses machen und eine Email an alle Teilnehmer versenden.

Hm, weiß nicht, vielleicht wäre es doch besser das als eigenes Modul zu machen indem man den vorhandenen Code kopiert, anpasst und erweitert. Sonst schränkt man vielleicht die vorhandenen Module nur zu sehr ein, oder?

Gruß
Raul

[fasse]

Hallo Raul,

nach längerem Grübeln bin ich jetzt auch erst einmal von der Konfiguration in den Rollen weg.

Ziel soll es praktisch sein, dass vorhandene Mitglieder Termine zusagen können und noch Nicht-Mitglieder relativ einfach auch zu solchen Terminen zusagen können oder ?

Ich würde diese Funktionalität schon in das Date-Modul einbauen, allerdings dann optional. Man kann es also in den Einstellung abschalten. Genauso optional könnte man dann die Gestaltung mit vordefinierten Orten machen.

Meiner Meinung nach sollten sich diese Nicht-Mitglieder schon registrieren, allerdings müsste man dann Admidio erweitern, so dass diese mit der Registrierung automatisch definierten Rollen zugewiesen werden. Z.B. der Rolle "Terminzusage".

Erstelle ich nun einen neuen Termin, kann ich dort eine Rolle angeben, welche "Mitglieder" sich bei diesem Termin anmelden können. Hier ordne ich dann die Rolle "Terminzusage" zu. Somit ist dein Fall abgedeckt, dass "Nicht-Mitglieder" relativ einfach für einen Termin anmelden können und du hast durch die Registrierung einen größeren Schutz vor Spammern. Außerdem kann man diese Funktionalität noch gut für andere Bereiche nutzen. Will ich z.B. einen Termin für eine Vorstandssitzung eintragen, so ordne ich die Rolle "Vorstand" zu und diesem Termin können dann nur die Vorstandsmitglieder zusagen.

Was hälst du von dieser Umsetzungsidee ?

Im Moment schreiben Module schon die Datenbanken anderer Module falls dies benötigt wird. Allerdings über DB-Klassen, welche dann auf nötige Regeln bzw. Daten achten. Aber wie gesagt, sehe ich hier noch keinen Bedarf an einem neuen Modul, sondern eher eine sinnvolle Erweiterung des Dates-Moduls, wobei dann die entsprechenden Features ggf. über Einstellungen deaktiviert werden. So sind die Anwender zufrieden, die dieses Feature nicht benötigen und für die anderen ist nicht wieder die Integration eines weiteren Moduls nötig, da sich die Inhalte vom jetzigen Termin-Modul und dem ggf. neuen Modul doch stark überschneiden.

Gruß
Fasse

[rpinto-mpunkt]

Ziel soll es praktisch sein, dass vorhandene Mitglieder Termine zusagen können und noch Nicht-Mitglieder relativ einfach auch zu solchen Terminen zusagen können oder ?

Klingt nach einer guten Zusammenfassung

Ich würde diese Funktionalität schon in das Date-Modul einbauen, allerdings dann optional. Man kann es also in den Einstellung abschalten. Genauso optional könnte man dann die Gestaltung mit vordefinierten Orten machen.

Ois klor Dank SVN kann man sich ja immernoch umentscheiden. Also, nicht das ich was gegen den Vorschlag habe, ich meinte nur "zur Not"

Meiner Meinung nach sollten sich diese Nicht-Mitglieder schon registrieren, allerdings müsste man dann Admidio erweitern, so dass diese mit der Registrierung automatisch definierten Rollen zugewiesen werden. Z.B. der Rolle "Terminzusage".

Genau, oder halt "Terminzusage_<termin_id>" oder so...

Erstelle ich nun einen neuen Termin, kann ich dort eine Rolle angeben, welche "Mitglieder" sich bei diesem Termin anmelden können. [...]
Was hälst du von dieser Umsetzungsidee ?

Klingt noch adäquat. Mal schauen was passiert wenn wir damit anfangen

Im Moment schreiben Module schon die Datenbanken [...] und für die anderen ist nicht wieder die Integration eines weiteren Moduls nötig, da sich die Inhalte vom jetzigen Termin-Modul und dem ggf. neuen Modul doch stark überschneiden.

Logo, dann fang ich mal bissl an

Derzeit hab ich allerdings das Problem, dass die SVN Version ja nur auf PHP5 läuft und mir dort Fehlermeldungen in der Art

Strict Standards: Declaration of TableOrganizations::readData() should be compatible with that of TableAccess::readData() in \adm_program\system\classes\table_organizations.php on line 50

ausgegeben werden. Ich google derzeit nach Lösungen aber habe noch keine gefunden (nein, das error-logging will ich nicht abschalten, warum? ). Gibt es ein Dev-Forum wo Probleme mit den SVN-Versionen besprochen werden?

Gruß und Danke
Raul

[fasse]

Derzeit hab ich allerdings das Problem, dass die SVN Version ja nur auf PHP5 läuft und mir dort Fehlermeldungen in der Art

Strict Standards: Declaration of TableOrganizations::readData() should be compatible with that of TableAccess::readData() in \adm_program\system\classes\table_organizations.php on line 50

ausgegeben werden. Ich google derzeit nach Lösungen aber habe noch keine gefunden (nein, das error-logging will ich nicht abschalten, warum? ). Gibt es ein Dev-Forum wo Probleme mit den SVN-Versionen besprochen werden?

Nein, zur Zeit noch nicht. Geht im Moment alles per Mail.
Das error-logging sollst du auch nicht ausschalten, im Gegenteil, es ist erwünscht das es aktiviert ist
Das Problem scheint wohl zu sein, dass in den beiden betroffenen Klassen die Methode readData unterschiedlich deklariert ist und PHP5 hier wohl penibler prüft. Das wird dann auch noch andere Klassen betreffen. Hier müsste man dann die Deklaration der Methode in den Klassen anpassen.

Gruß
Fasse

[rpinto-mpunkt]

Im Moment schreiben Module schon die Datenbanken anderer Module falls dies benötigt wird. Allerdings über DB-Klassen, welche dann auf nötige Regeln bzw. Daten achten.

Ok, eine Frage hätte ich dazu:
Kommen die Klassen für die Module in das adm_program/modules/<module>/ Verzeichnis oder in adm_program/system/classes?
Ersteres wäre irgendwie klüger weil die Klassen dort sind, wo sie benutzt werden aber dadurch auch unportabler bzw. nicht so gut exportierbar. Also schlechter Nutzbar für andere Module...

[lrdfrb]

Aus aktuellem Anlass muss ich diesen Thread mal wieder hochholen.

Mittlerweile ist es ja möglich, Termine zuzusagen.
Was mir dabei noch nicht so ganz gefällt, ist die Teilnehmerliste, die man angezeigt bekommt.
Es wäre schön, wenn man die noch konfigurieren könnte, damit nicht jeder Teilnehmer gleich die kompletten Daten der anderen Teilnehmer sieht (also praktisch eine Feldauswahl für die Teilnehmerliste)

[edit]
Hab jetzt gesehen, dass man die Liste über die Option, Felder auf unsichtbar zu setzen, ändern kann, Vorschlag bleibt aber trotzdem bestehen
[/edit]