SoSe16 AK Accounts

Vorstellung des AKs

Verantwortliche/r: Fabs (TU Berlin)

Einleitung/Ziel des AK

Dies ist ein Folge-AK des AK ZaPF-IT des letzten Jahres. Es soll für die ZaPF ein wiederverwertbares Anmeldesystem gebaut werden. Überlegungen hierzu sind bereits zwischen den ZaPFen erarbeitet worden und werden hier vorgestellt und diskutiert. Ein konkretes Konzept soll im Rahmen dieses AKs fergig ausgearbeitet werden, sowie sich eine Arbeitsgruppe für die Arbeit zwischen den ZaPFen finden.

Protokoll

vom 05.05.2016

Beginn 10:00

Ende 10:05

Redeleitung

Fabs (Tu Berlin)

Protokoll

Paul, Mayer

Anwesende Fachschaften

Tu Berlin

Fu Berlin

HU Berlin

Uni Frankfurt

Uni Bonn

Uni Münster

Uni Jena

Uni Konstanz

Uni Dresden

Uni Siegen

Tagesordnung / Themen

⁃ Das Accountsysten ⁃ Das Anmeldesystem ⁃ Anforderungen an das Account um Anmeldesystem

Das Accountsystem

• Jena: Die Konstanzer Lösung wurde für die Dresdener Zapf erweitert und ist bereits (fast) einsatzbereit.
• Münster: Es gibt ein Problem, weil die Fachschaftsangehörigkeit immer aktuell sein muss.
• Konstanz: Jeder kann selber die Fachschaft angeben, aber bei der Anmeldung wird sie nochmal von der Fachschaft überprüft.
• Dresden: Die Fachschaftsangehörigkeit, kann auch jedes Semester erneut abgefragt werden.
• Jena: Da es sich bei einem solchen System um kritische Infrastruktur handelt, muss es sehr sorgfältig entwickelt werden. Unkritische Dienste sollten zuerst ausgeschlossen sein, um unnötig große ausfälle zu verhindern.
• Münster: Was ist mit Gästen? Es sollte ein Fallbacksystem geben, falls es zu einem Ausfall kommt.
• Jena: Jedes Jahr wird ohnehin das Gleiches System entwickelt, einfach diese für alle Implementieren.
• Konstanz: Eine fallback Option würde das Programm unnötig verkomplizieren, aber das Programm sollte alles einfacher gestalten.
• Frankfurt: Anmelde Daten können nach der Zapf vernichtet werden, was den Datenschutz dient.
• Münster: Das Programm sollte erweiterbar sein.
• Frankfurt: Es muss eine längere Entwichlungs und Testphase mit Modularen Bau geben.
• Redeleitung: Später sollten alle weiteren Sachen integriert werden.
• Jena: Es sollte erst mal das Programm lauffähig gemacht werden und ein Prototyp entwickelt werden, also auch Code geschrieben werden, und nicht nur Spezifikationen erstellt werden.
• Jena: System für Konstanz (PHP) ist unter Zeitdruck entstanden und nicht Optimal, aber besser als lauter Stückchen im Backend.
• Es gibt Sicherheitsbedenken.
• Jena: Man nimmt Orga ein teil der Freiheit in dem man der Orga das Accountsystem wegnimmt
• Konstanz: Es herrscht kein Zwang, dass System zu benutzen, sie können es auch selber bauen.
• Sicherheit ist natürlich sehr wichtig.

Meinungsbild: Wer ist grundsätzlich für so ein System? Alle dafür

Das Anmeldesystem

• Redeleitung: Da es viele Sonderfälle gibt, sollte das Formular sehr Flexibel sein.
• Konstanz: Beispiel: Alle mussten sich einen Monat vorher für die Exkursion registrieren, aber einige Exkursionen hätten auch noch eine Woche vorher erstellen lassen.
• Redeleitung: Es muss eine Freez-option für teile des Formulars geben.
• Dresden: Will zuerst besprächen wie es konkret weiter geht.
• Münster: Das Datenmodell muss immer dynamisch erweiterbar sein, weil wir nicht wissen was kommt.

Allgemeine Zukunft:

• Konstanz: Für Dresden ist es nicht mehr möglich das System fertig zu stellen, wegen der Testphase, aber das System von Konstanz steht zur Verfügung.
• FUB: Für Dresden steht das System aus Konstanz zur Verfügung, aber wie danach weiter?
• Konstanz: Es soll ein neues System her, weil Datenschutz Probleme gelöst werden sollten und wegen der Wartbarkeit (Scala)
• Münster: Das System soll beibehalten werden, bis etwas besseres implementiert wurde.

Die Redeleitung wird an Dresden übergeben, weil der Redeführer gehen muss:

• Es wird eine Demonstration von einem verbesserten Konstanzer System gegeben:
  • Es wird ein Token erstellt.
  • Formular ähnlich wie Konstanz.
  • Leerer Strings sind möglich, also gibt es keine Pflichtfelder.
  • Alles was in Konstanz Funktioniert hat funktioniert auch weiter.

Die Redeleitung wird an Konstanz übergeben. Anforderungen an das Account und Anmeldesystem

• Dresden: Das System muss personell von mehreren getragen werden weil es sonst stirbt, wenn der/die Entwickler/in geht.
• Konstanz: Das das System Modular sein soll, gibt es ohnehin mehrere Entwickler.

Wer will aktuell entwickeln? Friedrich Dresden; Robert (Konstanz); Beratend Richard (Jena); Beratend und Planung Magnus (Frankfurt) Verfahrensvorschlag, Konstanz: Es wird ein Wikieintrag (dauerhaft) eingerichtet und eine Mailingliste erstellt. Gegenvorschlag: Jena, Instentmessaging benutzen (für die Entwicklung).

Der AK bittet den TopF darum eine Mailingliste (privat) einzurichten.

• Jena: Andere sollten den Code einsehen und ihn überprüfen um die Möglichkeit zu haben das Projekt für gescheitert zu erklären. Es muss eine Qualitätssicherung geben.
• Kevin Dresden, ist bereit den Code zu überprüfen.
• Dresden: Wer kümmert sich langfristig um die Wartung des Systems?
• Fu Berlin: Es muss jemanden geben der eingearbeitet ist um schnell Bugs zu fixen.
• Dresden: TopF soll das System überprüfen und die Zustimmung für den Einsatz geben, insbesondere auch für den langfristigen.

Zusammenfassung

Alle sind sich einig, dass ein System entwickelt werden sollte welches dann allen Zukünftigen Zapfen zur Verfügung gestellt wird. Das System muss von Grund auf neu entwickelt werden und Modular sein,es soll mit Python entwickelt werden (stapf.pad.spline.de/83). Aktuell Bereit zu Entwickeln sind Friedrich Dresden; Robert (Konstanz); Beratend Richard (Jena); Beratend und Planung Magnus (Frankfurt). Der TopF hat den Auftrag erhalten eine Mailingliste für Interessierte zu erstellen, so das jeder sich bei Interesse einbringen kann.