|
|
| (Eine dazwischenliegende Version von einem anderen Benutzer wird nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| − | == WTF ?==
| + | #redirect [[Metalab OS]] |
| − | | |
| − | Das MOS (Metalab Operating System) wurde auf einem SVN snapshot gebaut und wild verändert.
| |
| − | | |
| − | Updaten geht daher nicht leicht, neue Funktionen implementieren ist immer mit ein paar wenigen Eingeweihten Softwarezauberern verbunden.
| |
| − | | |
| − | Kurzum das Ding ist schön, aber mühsam in der Weiterenttwicklung, Daher wurde am Jour Fixe besprochen ob man das nicht neu implementieren möchte.
| |
| − | | |
| − | Hier sollen Features gesammelt werden um herauszufinden was wir brauchen.
| |
| − | | |
| − | | |
| − | == Bestehende Features ==
| |
| − | | |
| − | Das MOS bietet momentan die folgenden Features:
| |
| − | | |
| − | === Mitgliederverwaltung ===
| |
| − | | |
| − | * Wer ist Memeber?
| |
| − | * Welcher Permissions gibts im MOS? [fin: admin ja/nein, member ja/nein (indirekt), key ja/nein (indirekt)]
| |
| − | * Hat er/sie einen Schlüssel?
| |
| − | * Ist er /sie auf der Mailingliste?
| |
| − | * Kontodaten
| |
| − | * Kontomanagement / gebouncte Einzieher vermerken ..
| |
| − | | |
| − | ===Eventmanagement / Kalender ===
| |
| − | | |
| − | ==== Events ====
| |
| − | | |
| − | | |
| − | * Name
| |
| − | * Start
| |
| − | * Ende
| |
| − | * Location
| |
| − | * Wikiseite
| |
| − | * Teasertext
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | == Neue Features ==
| |
| − | | |
| − | Eindeutige usernames für MOS / wiki / jabber / ??? eventuell mit einer art openID oder anderwertig exportierbar / abfragbar um damit andere services zu authorisieren
| |
| − | | |
| − | | |
| − | '''Flexible Datenexportstrukturen'''
| |
| − | | |
| − | Daraus kann man zum Beispiel die Mailinglisten-subscriber extrahieren
| |
| − | | |
| − | Oder die Zugangsberechtigten zum Doorlocksystem
| |
| − | | |
| − | | |
| − | | |
| − | '''Generisches Listenfeature mit Exportfunktion'''
| |
| − | | |
| − | Eine Möglichkeit im Webinterface gezielt nach Benutzern zu suchen die zB per datum X einen validen lock-key hatten
| |
| − | | |
| − | Oder zu sehen wieviele zahlende Mitglieder der Verein momentan wirklich hat, oder an einem Stichtag hatte.
| |
| − | | |
| − | | |
| − | | |
| − | '''Getrennte Datenquellen'''
| |
| − | | |
| − | Es wäre schön wenn manche Daten in einer getrennten Datenbank liegen könnten.
| |
| − | | |
| − | Die sensiblen Mitgliederdaten wie Kontoinformationen und Zutrittskeys in einem separaten Datenhafen speichern.
| |
| − | | |
| − | Oder alternativ '''ALLE''' Daten in einem "sicheren" Datenhafen speichern und dort remote query Schnittstellen zur Verfügung zu stellen.
| |
| − | | |
| − | Die Webseite holt sich zB ein mal pro minute die aktuellen eventdaten für die startseite per cronjob und cacht die lokal.
| |
| − | | |
| − | Wenn ein User sich einloggen will auf der Webseite könnte man die credentials über einen sicheren kanal am datenhafen verifizieren und wenn das passt den user reinlassen und ihm die daten aus dem datensafe holen.
| |
| − | | |
| − | Das ganze konzept gehört einmal schön durchbespochen und visualisiert.
| |
