Handbuch zur. Rückerstattungssoftware für Semestertickets RESST. Gültig für RESST in Version 1.6. Stand:

Transkript

1 Handbuch zur Rückerstattungssoftware für Semestertickets RESST Gültig für RESST in Version 1.6 Stand:

2 Copyright (C) 2012 Moritz Kütt. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover s, and no Back-Cover s. A copy of the license is included in the section entitled "GNU Free Documentation License".

3 Inhalt 1.Idee Form der Software Prinzip Weitere Funktionen Installation Systemvorraussetzungen Installationsroutine Backup Frontend Backend Konfigurationsoptionen/Variablen Tex Pfade DB Seite Genehmigung Semester Betrag e Brief GNU Free Documentation License...13

4 1. Idee Viele Hochschulen bieten ihren Studierenden Semestertickets an, wobei mittels eines Solidarmodells meist alle Studierenden dieses Ticket kaufen müssen. Im Rahmen dieses Solidarmodells und auch der entsprechenden Semesterticketverträge gibt es Gründe, aus denen die Gebühr für das Semesterticket den Studierenden zurückerstattet werden kann. Dabei wird in der Regel auch das Ticket entwertet. Zur Abwicklung solcher Anträge dient diese Software (RESST). Dabei sollen Studierende ihren Antrag möglichst online stellen, genauso soll die Übertragung von Nachweisen weitestgehend digital erfolgen, sowie der Status der Bearbeitung online eingesehen werden können Form der Software Die Software basiert auf einer Kombination aus PHP für die Datenverarbeitung und MySQL für die Datenspeicherung. Dies ermöglicht den Zugriff auf die Antragsstellung und Bearbeitung über einen Webserver, der über verschiedene Computernetzwerke erreichbar ist. Neben der Antragsstellung ist so auch die Administration durch den AStA dezentral möglich Prinzip Für die Abwicklung solcher Anträge erhalten Studierenden daher mit ihrer ersten Antragstellung ein Benutzerkonto. Für das Hochladen von Nachweisen, das Einsehen des Antragsstatus aber auch für neue Anträge können die Studierenden nun dieses Benutzerkonto benutzen. Es gibt pro Matrikelnummer nur ein Benutzerkonto, falls schon ein Antrag gestellt wurde, kann der Studierende neue Anträge nun nur noch unter diesem erstellen. Für die Konten ist die Matrikelnummer der Benutzername, ein Passwort wird automatisch generiert und Studierenden zugesendet. Die Antragsstellung und Einsicht durch den Studierenden erfolgt im Frontend, das alle Optionen dafür zur Verfügung stellt. Auf dem Backend können die Anträge durch den AStA und andere Stellen bearbeitet werden. Die Bearbeitung ist durch unterschiedliche Benutzer möglich. Hierbei gibt es das grundsätzliche Prinzip, das alle durchgeführten Aktionen immer als Vorgänge in Verbindung mit dem Ausführenden Benutzer gespeichert werden. So kann die Bearbeitung eines Antrages auf verschiedene Personen verteilt werden (etwa: Verkehrsreferent zuständig für Genehmigungen, Finanzreferent für Überweisungen). Einzelne Vorgänge können später eingesehen werden Weitere Funktionen Zur weiteren Arbeitserleichterung, enthält die Software vorgefertigte -e für Fälle, in denen notwendige Unterlagen fehlen. Außerdem können über eine Druckfunktion Genehmigungen und Ablehnungen für die Anträge generiert werden (Standardbrief), um sie dann gesammelt zu verschicken. Für die Überweisung der Gelder besteht eine Exportmöglichkeit der Kontodaten im Dateiformat CSV (Comma Separated Values) und DTA/DTAUS (Datenträgeraustauschverfahren). CSV-Dateien können von Excel gelesen werden, genauso unterstützen viele Banking-Programme den Import einer solchen Datei, alternativ auch die DTA/DTAUS Dateien. Unterstützung für SEPA ist ebenfalls vorhanden.

5 2. Installation Vor der ersten Installation der Software empfiehlt es sich, dass folgende Kapitel vollständig zu lesen. Mit Installation ist die Einrichtung der Software auf einem Webserver gemeint. Nachdem diese vollständig durchgeführt wurde ist für die Nutzung der Software zur Bearbeitung von Anträgen keine weitere Installation mehr nötig. Die Bearbeitung erfolgt dann über unterschiedliche Rechner mithilfe der Webbrowser. Die installierende Person sollte grundlegende Kenntnisse in der Administration von LAMP- Systemen (Linux, Apache, MySQL, PHP) haben. Die Installationsroutine ist versucht alle möglichen Fehler zu erkennen, dies ist jedoch abhängig von der Systemkonfiguration nicht immer möglich Systemvorraussetzungen Die Software wurde bisher nur unter Linux-Systemen getestet, daher ist die Installation auf einem Linux-System zu empfehlen. Welche Distribution dabei gewählt wird, bleibt dem Administrator überlassen. Nötige Software Apache Webserver PHP Modul des Webservers (PHP-Version >= 5), mit MySQL-API MySQL-Server PEAR-Installation mit folgenden Paketen (siehe install.php) Latex-Installation (zur Generierung der Serienbriefe) Smarty Template Engine (Version 2.*, nicht 3.*!) Mailserver Damit aus der Software Mails versandt werden können, ist der Zugang zu einem SMTP Server nötig. Dabei kann entweder ein Zugang verwendet werden, der keine Authentifizierung erfordert. Es ist auch möglich, einen Server zu verwenden, der Authentifizierung ermöglicht. Dazu kann in der Konfiguration ein Benutzername und ein Passwort für diese Authentifizierung hinterlegt werden. Es ist NICHT möglich, auf den SMTP Server per SSL-Verschlüsselung zuzugreifen! Grundsätzlich muss auch eine Absenderadresse angegeben werden. nötig für mailversand smtp-zugang mit/ohne authentifizierung kein ssl adresse Netzwerkstruktur backend geschützt, aber nur bedingt gut https! 2.2. Rückerstattungsgründe und Nachweise RESST kann für die Rückerstattung aus verschiedenen Gründen genutzt werden (z.b. Urlaubssemester, Doppelstudium etc.). Unterschiedliche Antragsgründe können durch

6 unterschiedliche Nachweise belegt werden. Nachweise und Gründe müssen in der Konfiguration definiert werden. Ein Rückerstattungsgrund hat immer einen maschinenlesbaren Namen (am besten nur kleine Buchstaben, ohne Leerzeichen o.ä.), einen Namen, eine Beschreibung, eine zusätzliche Beschreibung sowie eine Liste der benötigten Nachweise. Beispiel: $config['gruende']['schwerbehinderung']['name'] = "Schwerbehinderung"; $config['gruende']['schwerbehinderung']['beschreibung'] = "Schwerbehinderung mit Freifahrt in öffentlichen Verkehrsmitteln"; $config['gruende']['schwerbehinderung']['berechtigt'] = "Schwerbehinderte mit gesetzlichem Anspruch auf Beförderung."; $config['gruende']['schwerbehinderung']['nachweise'] = "semesterticket,schwerbehindertenausweis,beiblatt"; Ein Nachweis hat immer einen maschinenlesbaren Namen (am besten nur kleine Buchstaben, ohne Leerzeichen o.ä.), einen Namen, einen Zusatz, einen der für Nachforderungs s genutzt wird sowie die Möglichkeit einzustellen, ob dieser Nachweis online hochgeladen werden kann Installationsroutine Die Daten aus dem Github Repository müssen auf einen PHP Webspace geladen werden. Es ist empfehlenswert das Repository direkt auf dem Server zu klonen um so direkt updates laden zu können. Über das Submodule wird automatisch die SEPA Bibliothek eingebunden. git clone cd resst git submodule init git submodule update Updates können anschließend in dem Verzeichnis mit git pull gemacht werden. Die Installation startet mit Aufruf der URL Wenn die Systemanforderungen erfüllt sind kann direkt installiert werden, sonst wird informiert was fehlt. Nach der Installation ist das Backend zur Bearbeitung hier erreichbar: Standardlogin ist admin mit dem Passwort aendermich. Diesem Benutzer müssen noch Rechte zugewiesen werden, dazu auf Benutzer verwalten klicken und dann neben admin auf Rechte, dort alle Häkchen setzen.

7 2.4. Absicherung des Webservers (WICHTIG!) Die Ordner nachweise und pdf müssen über eine.htaccess-datei gesichert sein. Die entsprechende Datei ist enthalten, wird aber je nach Apache Konfiguration evtl. nicht aktiv. Unbedingt prüfen!!!! 2.5. Backup Der Ordner nachweise und die Datenbank müssen gesichert werden. 3. Frontend Das Frontend steht allen Antragstellerinnen und Antragstellern zur Verfügung. Studierende können hier Anträge zur Rückerstattung stellen. Bei der erstmaligen Antragsstellung wird den Studierenden zu ihrer Matrikelnummer (die dann als Benutzername gilt) ein Passwort zugeteilt. Mit diesen Zugangsdaten können sie die nötigen Nachweise hochladen sowie den Status ihres Antrages einsehen. Auch für weitere Anträge der gleichen Matrikelnummer ist dieser Zugang nötig, d.h. pro Matrikelnummer gibt es nur eine Zugangsmöglichkeit zum System. Werden vom System Passwörter generiert und versendet, sind dies Einmalpasswörter, die dann bei der ersten Nutzung zwingend geändert werden müssen. Falls Studierende ihr Passwort vergessen haben, können sie sich ein neues Passwort zustellen lassen. Dazu wird die in den Anträgen angegebene -Adresse verwendet, und ebenfalls ein Einmalpasswort versendet. Alternativ dazu lässt sich auch eine Authentifizierung über Single-Sign-On mit CAS nutzen, wobei dieses Verfahren wohl nur an der TU Darmstadt eingesetzt wird, aber vielleicht lässt es sich ja anpassen. Die Studierenden melden sich so direkt über ihre Uni-Zugangsdaten an. Nach erfolgreichem Login werden an RESST Daten übertragen (Matrikelnummer, Name, adresse), die dann nicht mehr von den Studierenden ausgefüllt werden. Auch die Statusabfrage ist so möglich, die Einmalpasswörter entfallen. Das Hochladen von Unterlagen ist prinzipiell selbsterklärend. Neben der Datei muss noch ein Nachweistyp ausgewählt werden, hier können die Studierenden nur solche Nachweise auswählen, welche für den entsprechenden Antrag zulässig sind. Es ist aber auch jederzeit möglich, eine eigene Angabe zum Nachweis zu machen ( Sonstiges ). Wenn im Frontend eingeloggt, sehen Studierende immer den letzten Bearbeitungsstand ihres Antrags, und haben zusätzlich auch die Möglichkeit Angaben zu ändern bzw. den Antrag zurückzuziehen. Alle diese Änderungen sind für die Bearbeiter unter Vorgänge einzusehen. Sobald ein Antrag genehmigt ist, können die Studierenden in nicht mehr verändern oder Nachweise hinzufügen. Für zusätzliche Anträge (z.b. kommende Semester) müssen sich Studierende mit ihren alten Zugangsdaten einloggen und können dann einen neuen Antrag eingeben. Ohne das alte Passwort ist dies nicht möglich, jedoch kann ein neues Passwort wie oben beschrieben an die im alten Antrag angegebene -Adresse versandt werden. 4. Backend Das Backend dient der Verwaltung der gestellten Anträge. Zugang zum Backend ist nur für vom AStA registrierte Benutzer möglich. Bei der ersten Installation wurde ein Superbenutzer eingerichtet, der Zugriff auf alle Teile des Programms hat, neue Benutzer einrichten kann und diesen Benutzern Rechte zuweisen kann. Es ist auch möglich, weitere Superbenutzer einzurichten. Das Rechtesystem für Backend-Nutzer ist sehr feingliederig. Es besteht die Möglichkeit, Nutzer die

8 Durchführung sog. Vorgänge zu erlauben (etwa Änderung eines Antrags oder Genehmigung). Prinzipiell macht es hier sinn, verschiedene Benutzer mit verschiedenen Rechten einzurichten. Hier ist es Möglich die integrierte Passwortverwaltung zu umgehen und z.b. über LDAP zu authentifizieren. Dabei muss die Authentifizierung über den Webserver (z.b. Apache) geschehen. RESST übernimmt dann den Benutzernamen, der allerdings trotzdem angelegt sein muss. Die grundsätzliche Ansicht im Backend bezieht sich auf ein Semester. Allgemein wird beim ersten Login die Liste aller Anträge des aktuellen Semesters angezeigt. Über eine Menü Grundsätzliche Backend-Ansicht semester wechseln beträge listen/anzeigen Benutzerverwaltung eigenes passwort verändern super-user benutzer anlegen Globale Konfiguration Listen semesterdaten anpassen welche was ist die idee Antrag ansehen was sieht man oben unten mitte Antragspezifische Vorgänge Allgemeine Vorgänge 5. Konfigurationsoptionen/Variablen Alle Konfigurationseinstellungen werden in der Datei config.php vorgenommen. Dort werden sie in der PHP-Variable $config gespeichert, die ein großes, mehrdimensionales Array ist. Einstellungen müssen PHP-Syntax konform erfolgen, sonst funktioniert RESST nicht (z.b. Semikolon am Ende einer Zeile etc.). Alle möglichen Optionen sind im folgenden aufgelistet. Einstellungen vom Typ müssen in Anführungszeichen übergeben werden, solche vom Typ

9 Bool ohne Anführungszeichen, dafür nur mit den Werten 0 oder 1. Zahl wird ebenfalls ohne Anführungszeichen angegeben, es können Zahlen mit oder ohne Komma sein. Es gibt keine Default-Werte Tex Einstellungen für die TeX/LaTeX-Umgebung $config['tex']['kommando'] Pfad zum Tex (PDFLATEX) Kommando (z.b. /usr/bin/pdflatex) 5.2. Pfade Pfadeinstellungen für die Software $config['pfade']['http'] Basis-URL des Web-Servers, ohne Pfad zu RE- Software (z.b. ) $config['pfade']['root'] Absoluter Pfad zur RE-Software im Dateisystem des Servers $config['pfade']['webroot'] Relativer Pfad der RE-Software mit bezug zum /-Verzeichnis des Webservers $config['pfade']['smarty'] Absoluter Pfad zur Smarty-Bibliothek ("" falls schon in includes des Webservers auffindbar) $config['pfade']['pear'] Absoluter Pfad zur PEAR-Installation ("" falls schon in includes des Webservers auffindbar) $config['pfade']['cas'] Absoluter Pfad zur CAS-Installation ("" falls schon in includes des Webservers auffindbar), nicht notwendig falls CAS nicht benutzt werden soll 5.3. DB Datenbankeinstellungen für die MySQL-Datenbank $config['db']['host'] Host, auf dem die MySQL Datenbank läuft (typischerweise localhost ) $config['db']['benutzer'] Benutzername für die MySQL-Datenbank $config['db']['passwort'] Passwort für die MySQL-Datenbank $config['db']['datenbank'] MySQL-Datenbank-Name Einstellungen üfr s. Hier wedern sowohl technische Dinge geregelt, als auch die e der jeweiligen s vorgegeben. Bei den en können Variablen benutzt werden (z.b. VORNAME ), die dann automatisch durch Werte des Antrages/der Software ersetzt werden (beim Beispiel durch den Vornamen des Antragsstellers). Folgende Ersetzungen sind insgesamt möglich: Variable VORNAME Bedeutung Vorname des Antragsstellers/der

10 NACHNAME FRIST BISAUF UNTERLAGEN FRONTENDLOGIN FRONTENDINDEX PASSWORT Antragstellerin Nachname des Antragsstellers/der Antragstellerin Frist, bis zu der im Semester des Antrages Unterlagen nachgereicht werden können. Liste der Unterlagen, die nicht hochgeladen werden können (je nach Einstellung in der Konfiguration) Ausgewählte nachgeforderte Unterlagen, bzw. deren jeweiliger Nachforderungstext. Login-Seite des Frontends Startseite des Frontends Per Mail verschicktes Einmalpasswort MATRIKELNUMMER Matrikelnummer des Antragsstellers Nicht alle Variablen können überall benutzt werden, daher sind immer mögliche angegeben. ['absender'] Absenderadresse (wird für ausgehende Mails genutzt) ['SMTPhost'] SMTP Server, über den Mails verschickt werden ['authentifizierung'] ['benutzername'] Bool Ist Authentifizierung für den SMTP-Server nötig? (1 = Ja, 0 = Nein) Benutzername für Authentifizierung bei SMTP-Server (nur nötig falls Authentifizierung benötigt, sonst "") ['passwort'] Passwort für Authentifizierung bei SMTP-Server (nur nötig falls Authentifizierung benötigt, sonst "") ['immerneu'] Bool Falls 1: Immer wenn ein neuer Antrag zu einer Matrikelnummer gestellt wird, wird ein neues Passwort verschickt (auch bei Neuanträgen durch den Nutzer im Frontend). OTRS Integration Das System kann mit dem Ticketsystem OTRS verknüpft werden. Für jeden Antrag wird dabei ein Ticket in OTRS angelegt, worin auch alle ausgehenden Mails abgelegt werden. Wenn der Antragsteller auf diese antwortet ist somit eine Verknüpfung gegeben. Die Mail selbst wird immer über RESST verschickt, allerdings mit Ticketnummer im Betreff, die Speicherung in OTRS ist zusätzlich. In OTRS wird ein Link zum passenden Antrag angezeigt. Einrichtung OTRS: Benutzer mit Rechten für die verwendete Queue anlegen Webservice aktivieren, GenericTicketConnector importieren oder manuell anlegen:

11 Dynamisches Feld ResstAntragID mit Typ und Objekttyp Ticket anlegen. Bei Link Anzeigen: die URL von RESST und /backend/index.php? vorgang=ansehen&antrag_id=$lqdata{"resstantragid"} eintragen. In Sysconfig: Ticket::Frontend::AgentTicketZoom###DynamicField (Key: ResstAntragID, Value: 1) Ticket::Frontend::AgentTicketSearch###DynamicField (Key: ResstAntragID, Value: 1) ['otrs'] Bool Falls 1: OTRS wird verwendet ['otrs_url'] URL des GenericInterface Connectors. Sollte auf /nphgenericinterface.pl/webservice/ GenericTicketConnector enden. ['otrs_ticket_url'] URL zur Ticketansicht. Ticket ID wird angehängt. Normalerweise: /index.pl? Action=AgentTicketZoom;Tick etid= ['otrs_queue'] Queue, z.b. AStA::Semesterticket ['otrs_ticketstate'] Gewünschter Ticketstatus für neu angelegte Tickets. Normalerweise closed. ['otrs_user'] User mit entsprechenden Rechten auf die Queue ['otrs_pass'] Passwort ['otrs_namespace'] Namespace, Standard: ector/ e ['nachforderung']['betreff'] ['nachforderung'][''] ['neueintrag'] ['Betreff'] ['neueintrag'] [''] Betreff für s, mit denen Dinge nachgefordert werden für Nachforderungs s. Mögliche Variablen: VORNAME, NACHNAME, FRIST, BISAUF, UNTERLAGEN Betreff für s, die Antragssteller über Neueintrag informieren der s, die über Neueintrag informieren. Mögliche Variablen: VORNAME, NACHNAME, FRONTENDLOGIN, FRONTENDINDEX,

12 ['passwort_vergessen']['betreff'] ['passwort_vergessen']['' ['asta_neueintrag']['betreff'] ['asta_neueintrag'][''] ['genehmigung_versand'] ['Verschicken'] ['genehmigung_versand'] ['Betreff'] ['genehmigung_versand'][''] ['genehmigung_abholung'] ['Verschicken'] ['genehmigung_abholung'] ['Betreff'] ['genehmigung_abholung'] [''] ['genehmigung_entwertung'] ['Verschicken'] ['genehmigung_entwertung'] ['Betreff'] ['genehmigung_entwertung'] [''] ['ablehnung_nur_mail'] ['Verschicken'] Bool Bool Bool Bool PASSWORT, MATRIKELNUMMER Betreff für s, die Antragstellern neues Passwort zuschicken. für s mit neuem Passwort. Mögliche Variablen: VORNAME, NACHNAME, FRONTENDLOGIN, PASSWORT, MATRIKELNUMMER Betreff der s, die Antragssteller darüber informieren, dass durch den AStA für sie ein Antrag eingegeben wurde der s, die Antragssteller darüber informieren, dass durch den AStA für sie ein Antrag eingegeben wurde. Mögliche Variablen: VORNAME, NACHNAME, FRONTENDLOGIN, PASSWORT, MATRIKELNUMMER Falls 1: Benachrichtigung wird verschickt, wenn Antrag genehmigt ist und Antragsteller um Versand per Post gebeten hat. Betreff Falls 1: Benachrichtigung wird verschickt, wenn Antrag genehmigt ist und Antragsteller das Semesterticket abholt. Betreff Falls 1: Benachrichtigung wird verschickt, wenn Antrag genehmigt ist und Antragsteller das Semesterticket vor Ort entwerten lässt. Betreff der Mail. Im Template kann zusätzlich FRIST eingefügt werden. Hier wird die Nachmeldefrist für weitere Unterlagen eingefügt. Falls 1: Benachrichtigung wird verschickt, wenn Antrag abgelehnt ist und keine weiteren Unterlagen verschickt oder abgeholt werden müssen. Das kann durch ein entsprechende Konfiguration der Ablehnungsgründe

13 ['ablehnung_nur_mail'] ['Betreff'] ['ablehnung_nur_mail'][''] ['ablehnung_versand'] ['Verschicken'] ['ablehnung_versand']['betreff'] ['ablehnung_versand'][''] ['ablehnung_abholung'] ['Verschicken'] ['ablehnung_abholung'] ['Betreff'] ['ablehnung_abholung'][''] Bool Bool passieren, oder bei der Vor-Ort-Entwertung. Betreff der Mail. Falls 1: Benachrichtigung wird verschickt, wenn Antrag abgelehnt ist und noch ein Brief verschickt wird. Betreff der Mail. Falls 1: Benachrichtigung wird verschickt, wenn Antrag abgelehnt ist und das Semesterticket noch abgeholt werden muss. Betreff der Mail Seite $config['seite']['titel'] Titel für Seiten der RE-Software (z.b. Semesterticket Rückerstattung ) $config['seite']['untertitel'] Untertitel für Seiten der RE-Software, empfehlenswert: hier sollte der AStA Name auftauchen $config['seite']['wendenan'] Sinnvoll konjugierter für generierte Sätze des Typs Bei fragen wende dich an.... Die Punkte werden in diesem Fall durch die Konfigurationsvariable ersetzt. $config['seite']['kontakt '] Kontakt des AStA/Verkehrsreferats $config['seite']['astahomepage'] Homepage des AStA $config['seite']['astaadresse'] Post-/Kontaktadresse des AStA für Auflistung auf den Webseiten der Software $config['seite']['satzungslink'] Link zu Rückerstattungssatzung 5.6. Genehmigung $config['genehmigung'] ['vieraugen'] Bool 1: Jeder Antrag muss doppelt genehmigt werden 0: Jeder Antrag muss nur einmal genehmigt werden 5.7. Antragsverfahren Fett gedruckte Einträge sind Standard, müssen auch nicht in der Config auftauchen.

14 $config['antragsverfahren'] ['geburtstag'] $config['antragsverfahren'] ['adresse'] $config['antragsverfahren'] ['versand'] $config['antragsverfahren'] ['vor_ort'] Bool Bool Bool Bool 1: Geburtstag abfragen 0: keinen Geburtstag abfragen 1: Adresse abfragen 0: keine Adresse abfragen (nur Versand möglich) 1: Versand ist möglich 0: kein Versand 1: Entwertungsverfahren vor Ort. Bis zu einer Frist muss Ticket im Büro entwertet werden, danach folgt Überweisung. 0: deaktiviert 5.8. Frontendlogin Einstellungen für Frontendlogin Verfahren, hier ist auch ein Login über CAS möglich, sofern es dafür einen Server gibt. Das Verfahren ist gerade ausschließlich auf die TU Darmstadt angepasst. Bei Verwendung an anderen Hochschulen muss das erweitert werden. $config['frontendlogin']['type'] Int Typ des Frontendlogins 1 = Standard RESST, interne Verwaltung 2 = externe Verwaltung über PHP CAS $config['frontendlogin'] ['CASserver'] $config['frontendlogin'] ['CASport'] $config['frontendlogin'] ['CASpfad] $config['frontendlogin'] ['CASzertifikat] 5.9. Backendlogin Einstellungen für Backend-Login Verfahren. Dabei ist derzeit nur die Übernahme eines HTTP Headers möglich, so kann z.b. HTTP Basic Authentifizierung, LDAP oder ein anderes serverbasiertes System verwendet werden. Die Accounts müssen trotzdem manuell in RESST angelegt werden und es muss ein Passwort gesetzt werden. Das Passwort wird allerdings ignoriert, der Nutzer wird nur aufgrund des übermittelten Namens eingeloggt, der z.b. von Apache geprüft werden muss. $config['backendlogin']['type'] Int Typ des Frontendlogins 1 = Standard RESST, interne Verwaltung 3 = HTTP Header $config['backendlogin'] ['server_var'] String Key der in der $_SERVER Variable abgefragt werden soll. Meist HTTP_REMOTE_USER oder REMOTE_USER Datenüberprüfung Möglichkeiten die Überprüfung anzupassen

15 $config['datenueberpruefung'] ['maildomain'] String Maildomain zur Sicherstellung, dass eine Uni-Adresse verwendet wird. Sobald die Variable gesetzt ist, ist die Prüfung aktiv Semester $config['semester'] ['sommerbeginn'] $config['semester'] ['winterbeginn'] $config['semester'] ['antragsfristsommer'] $config['semester'] ['fristsommer'] $config['semester'] ['antragsfristwinter'] $config['semester'] ['fristwinter'] Monat und Tag des Beginn des Sommersemesters im Format mm-tt Monat und Tag des Beginn des Wintersemesters im Format mm-tt Monat und Tag der generellen Frist für Anträge in Sommersemestern im Format mm-tt (individuelle Fristen können pro Semester eingestellt werden). Monat und Tag der generellen Frist für Abgabe von Unterlagen in Sommersemestern im Format mm-tt (individuelle Fristen können pro Semester eingestellt werden). Auf den gleichen Wert wie $config['semester']['antragsfristommer'] setzen, sofern es nur eine Frist gibt. Monat und Tag der generellen Frist für Anträge in Wintersemestern im Format mm-tt (individuelle Fristen können pro Semester eingestellt werden). Monat und Tag der generellen Frist für Abgabe von Unterlagen in Wintersemestern im Format mm-tt (individuelle Fristen können pro Semester eingestellt werden). Auf den gleichen Wert wie $config['semester']['antragsfristwinter'] setzen, sofern es nur eine Frist gibt. $config['semester']['pausezeit'] Zahl Tage Pause, für die die Software nach der Antragsfrist jeden Semesters geschlossen wird, also keine Neuanträge durch Studierende akzeptiert werden Betrag $config['betrag']['portoabzug'] Zahl Abzug für Porto. Wird hier 0 angegeben, wird auf die Berechnung des Abzuges verzichtet und keine entsprechenden Hinweise ausgegeben (etwa auf Briefen). $config['betrag']['altekonten'] Bool 1: Es werden Konten vom Typ Kontonummer/BLZ angegeben. 0: Dieses Format soll nicht benutzt werden (falls hier 0, muss jedoch $config['betrag']['sepa'] auf 1 gesetzt werden. $config['betrag']['sepa'] Bool 1: Es werden Konten vom Typ IBAN/BIC angegeben. 0: Dieses Format soll nicht benutzt werden (falls hier 0, muss jedoch $config['betrag']['altekonten'] auf 1 gesetzt werden.

16 $config['betrag']['absender'] $config['betrag']['blz'] $config['betrag'] ['Kontonummer'] e $config['e']['anfangsabsatz'] $config['e']['antragsintro'] $config['e']['porto'] = " wird dein Ticket nach Genehmigung und Entwertung im AStA zu dir zurückgeschickt. Falls du es im Moment nicht brauchst, sparst du uns Portokosten, wenn du es später abholst."; Brief $config['brief']['absendername'] = "AStA der TU Darmstadt"; $config['brief']['absenderadresse'] = "Hochschulstrasse 1, Darmstadt"; $config['brief']['signatur'] = "Verkehrsreferent A.B."; $config['brief']['wendenan'] = "das Verkehrsreferat des ASTA der TU Darmstadt"; $config['brief']['kontakt '] = "verkehr@asta.tu-darmstadt.de"; $config['brief']['betreff'] = "Rückerstattung des Semestertickets"; $config['brief']['portobegruendung'] = " (vom bezahlten Semesterticketbetrag wurden 0,55 Euro für den Rückversand des Tickets abgezogen)"; $config['brief']['ablehnung'] = 'Du hast die R"uckerstattung des Semesterticketbeitrages f"ur das SEMESTER beantragt. Dein Antrag wurde abgelehnt. Begr"undung: BEGRUENDUNG Rechtsbehelfsbelehrung I. Die R"ucksendung von Antragsunterlagen abgelehnter Antr"age erfolgt zu Lasten des Antragsstellers. Das Antragsformular wird nicht zur"uckgesendet. II. Gegen diese Ablehnung kann innerhalb von 14 Tagen nach Zugang Widerspruch eingelegt werden. Der Widerspruch ist schriftlich zu begr"unden und an ABSENDERNAME, ABSENDERADRESSE zu schicken.'; $config['brief']['genehmigung'] = 'deinem Antrag auf R"uckerstattung des Semesterticketbeitrages f"ur das SEMESTER wurde stattgegeben. Anbei erh"altst Du deinen Studierendenausweis zur"uck. Rechtsbehelfsbelehrung I. Die R"uckerstattung erfolgt unter Wegfall der Fahrtberechtigung f"ur das komplette Semester. Der Studierendenausweis wurde entsprechend gekennzeichnet (Lochung / Markierung).

17 II. Die R"uckerstattung ist endg"ultig. III. Solltest Du deinen Studierendenausweis verlieren, wird das Studierendensekretariat als zust"andige Stelle ebenfalls nur einen entwerteten Ausweis ausstellen. Die "Uberweisung des R"uckerstattungsbetrages in H"ohe von ENDBETRAG Euro PORTOBEGRUENDUNG wird demn"achst erfolgen. Bei R"uckfragen wende dich bitte an WENDENAN unter KONTAKT .';

18 6. GNU Free Documentation License GNU Free Documentation License Version 1.3, 3 November 2008 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. < Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

19 The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover s" are certain short passages of text that are listed, as Front-Cover s or Back-Cover s, in the notice that says that the Document is released under this License. A Front-Cover may be at most 5 words, and a Back-Cover may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. The "publisher" means any person or entity that distributes copies of the Document to the public. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING

20 You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover s, you must enclose the copies in covers that carry, clearly and legibly, all these Cover s: Front-Cover s on the front cover, and Back-Cover s on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct