MOS-neu: Unterschied zwischen den Versionen
Fin (Diskussion | Beiträge) (→Mitgliederverwaltung: fyi) |
|||
Zeile 8: | Zeile 8: | ||
Hier sollen Features gesammelt werden um herauszufinden was wir brauchen. | Hier sollen Features gesammelt werden um herauszufinden was wir brauchen. | ||
+ | |||
+ | '''See also: [https://metalab.at/issues/query?status=!closed&keywords=~mos Tickets im Tracker]''' | ||
Version vom 22. Januar 2012, 13:42 Uhr
WTF ?
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.
See also: Tickets im Tracker
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.