Changeset 5644 for main/waeup.sirp/trunk/docs/source/developerdocs

Timestamp:

20 Jan 2011, 06:53:42 (14 years ago)

Author:

Henrik Bettermann

Message:

Take different application forms for the same screening into consideration.

File:

• main/waeup.sirp/trunk/docs/source/developerdocs/german/application.rst (modified) (4 diffs)

main/waeup.sirp/trunk/docs/source/developerdocs/german/application.rst

@@ -2 +2 @@
 ***********
 
-Das Application Package dient der Anmeldung einer großen Zahl von Personen (bis 50.000) zur Teilnahme an einem hochschulinternen Screening-Verfahren, welche die Zulassung zum Studium an der Hochschule regeln. Es gibt zur Zeit acht verschiedene Screening-Verfahren und entsprechend viele Anmeldeformulare, die sich alle in in ihren Stammdaten sehr ähneln. Ein Screening wird in der Regel durch einen Massentest ('Exercise') begleitet. Manchmal spielt auch nur die Herkunft (z.B. aus dem armen Norden) oder das Geschlecht eine Rolle bei der Vergabe von Studienplätzen. Hier die verschiedenen Screening-Verfahren:
+Das Application Package dient der Anmeldung einer großen Zahl von Personen (bis 50.000) zur Teilnahme an einem hochschulinternen Screening-Verfahren, welche die Zulassung zum Studium an der Hochschule regeln. Es gibt zur Zeit acht verschiedene Screening-Verfahren mit zum Teil mehreren unterschiedlichen Anmeldeformularen. Ein Screening wird in der Regel durch einen Massentest ('Exercise') begleitet. Manchmal spielt auch nur die Herkunft (z.B. aus dem armen Norden) oder das Geschlecht eine Rolle bei der Vergabe von Studienplätzen. Hier die verschiedenen Screening-Verfahren:
 
 **1. Universities**
@@ -33 +33 @@
 Darüber hinaus bieten die FCEs auch noch Sandwich und Diploma-Programme an. Die Formulare der Universitäten können benutzt werden.
 
+Die Frage tauchte auf, wie wir mit Screeningverfahren umgehen, für die es mehrere Anmeldeformulare gibt (z.B. PUME und PUME 2nd Choice). Ich schlage vor, jedes Anmeldeformular als eigenständigen Container für Application Records zu implementieren. Das Screening interessiert uns recht wenig, nur das Formular ist für uns interessant. An dem ApplicationForm-Container hängen dann die Informationen: Start Date, End Date (Deadline) und Title (Liste kann erweitert werden). Wir benötigen somit nur zwei Container-Ebenen, wobei die Id des ApplicationForm-Containers sich zusammensetzen muss aus dem Kürzel des Screeningverfahrens (+ evtl. Kennung unterschiedlicher Anmeldeformulare) + Sessionkennung. Der Pfad für eine PUME-Application könnte somit wie folgt aussehen: ``applications/pume_11/123456``. Innerhalb eines ApplicationForm-Containers ist die Id eindeutig. Beim Export der Daten über Sessiongrenzen hinweg müsste die Kennung, in diesem Fall ``pume_11``, der Id noch vorangestellt werden. In einer CSV-Datei würde die Id des Records dann ``pume_11_123456``` lauten. 
+
 Bei den Certificates gibt as das Attribut application_category. Dieses Attribut hilft bei der Gruppierung von Certificates, die den Antragstellern zur Auswahl gestellt werden. Hier werden die Screening-Typen DP, CT und PT noch einmal zusammengefasst, da sie anscheinend alle zu den gleichen Abschlüsse führen. Auch kommt bei all diesen Studenten der CEST zum Einsatz.
 
-Für den Worksflow müssen zwei Gruppen unterschieden werden. PUME, PUDE und PCE durchlaufen vorher das JAMB-Screening, d.h. JAMB liefert den Basisdatensatz, der inkl. der Passfotos über das Data Center importiert werden muss. Bei der Anmeldung im Portal müssen sich die Applicanten erst durch ihre JAMB Registration Number identifizieren. Zusätzlich geben sie noch eine Application PIN ein, mit der sie die Berechtigung gekauft haben, das Formular weiter auszufüllen zu dürfen. Alle anderen Applikanten geben nur die PIN ein. Ihr Datensatz wird in diesem Moment erzeugt. Als Registration Number wird dann (anstatt die JAMB RegNo) die Batch- und die Seriennummer der Scratch Card verwendet (Bauweise s.u.).
+Für den Worksflow müssen zwei Gruppen unterschieden werden. PUME, PUDE und PCE durchlaufen vorher das JAMB-Screening, d.h. JAMB liefert den Basisdatensatz, der inkl. der Passfotos über das Data Center importiert werden muss. Bei der Anmeldung im Portal müssen sich die Applikanten erst durch ihre JAMB Registration Number identifizieren. Zusätzlich geben sie noch eine Application PIN ein, mit der sie die Berechtigung gekauft haben, das Formular weiter auszufüllen zu dürfen. Alle anderen Applikanten geben nur die PIN ein. Ihr Datensatz wird in diesem Moment erzeugt. Als Registration Number wird dann (anstatt die JAMB RegNo) die Batch- und die Seriennummer der Scratch Card verwendet (Bauweise s.u.).
 
 Die Vorgehensweise und der Workflow ist wie folgt:
@@ -41 +43 @@
 - JAMB-Datensätze werden im Status 'created' importiert.
 
-- Applicants öffnen die entsprechende Eingabemaske für die PIN und ggf. der JAMB Registration Number. Der PIN Prefix entspricht dem obigen Screeining-Kürzel. Nach dem ersten Zugriff auf einen Datensatz ändert sich dessen Status nach 'edited'.
+- Applikanten öffnen die entsprechende Eingabemaske für die PIN und ggf. der JAMB Registration Number. Der PIN Prefix entspricht dem obigen Screeining-Kürzel. Nach dem ersten Zugriff auf einen Datensatz ändert sich dessen Status nach 'edited'.
 
 - Das Formular öffnet sich, das Passbild wird hochgeladen (falls noch nicht vorhanden) und die Felder werden ausgefüllt. Etwas komplizierter sind die Eingabefelder für Zeugnisnoten. Das müsste man sich mal im alten SRP anschauen.Das Passbild wird in einem separaten Verzeichnis mit der Registration Number als Name abgespeichert. Nur jpg-Bilder mit einer begrenzten  Bytegröße werden erlaubt. 
@@ -47 +49 @@
 - Es gibt nur ein einziges Select-Feld, das sich Daten aus der Academic Section holt: das Auswahlfeld des gewünschten Study Course (=Certificate). Die Auswahl möglicher Certificates geschieht dynamisch. Das Feld application_category der Certificates dient als Filter.
 
-- Wenn alle Pflichtfelder ausgefüllt sind, kann der Datensatz vom Applicant submitted werden. Der Status des Datensatzes ändert sich entsprechend. Nach der Einreichung erscheint ein Drucksymbol zum Ausdrucken eines Slips. Der Slip öffnet sich in einem separaten Fenster und zeigt nur eine Auswahl der Felder aus dem Datensatz an. Der Slip dient zur Vorlage bei der Vorprüfung an der Universität.
+- Wenn alle Pflichtfelder ausgefüllt sind, kann der Datensatz vom Applikant submitted werden. Der Status des Datensatzes ändert sich entsprechend. Nach der Einreichung erscheint ein Drucksymbol zum Ausdrucken eines Slips. Der Slip öffnet sich in einem separaten Fenster und zeigt nur eine Auswahl der Felder aus dem Datensatz an. Der Slip dient zur Vorlage bei der Vorprüfung an der Universität.
 
-- Nach der Massenprüfung an der Universität werden die Ergebnisse der Prüfung importiert und der Datensatz entweder auf 'non admitted' oder 'admitted' gesetzt. In den admitted Datensätzen wird zudem der certificate code importiert, des Kurses für den die Applicants vorläufig zugelassen wurden. 
+- Nach der Massenprüfung an der Universität werden die Ergebnisse der Prüfung importiert und der Datensatz entweder auf 'non admitted' oder 'admitted' gesetzt. In den admitted Datensätzen wird zudem der certificate code importiert, des Kurses für den die Applikanten vorläufig zugelassen wurden. 
 
-- Ein paar Tage später werden die admitted Datensätze in das Portal kopiert (ca. 5000 bis 7000 Stück), d.h. in Studentenobjekte umgewandelt. Die Applicants-Tabelle wird nach einem Jahr geleert. Sehr bürokratisch ist die Verwaltung der Registration Number. CEST und Sandwich applicants bekommen eine eigene Registration Number verpasst (siehe WAeUPTool.py)::
+- Ein paar Tage später werden die admitted Datensätze in das Portal kopiert (ca. 5000 bis 7000 Stück), d.h. in Studentenobjekte umgewandelt. Die Applicants-Tabelle wird nach einem Jahr geleert. Sehr bürokratisch ist die Verwaltung der Registration Number. CEST und Sandwich Applikanten bekommen eine eigene Registration Number verpasst (siehe WAeUPTool.py)::
 
     if brain.screening_type in ('dp','pt','ct','cest','sandwich','sandwich2008') and brain.serial and brain.entry_session: