MOS-neu: Unterschied zwischen den Versionen

aus Metalab Wiki, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Zur Navigation springenZur Suche springen
(ideensammlung für MOS neu)
 
Zeile 17: Zeile 17:
  
 
* Wer ist Memeber?
 
* Wer ist Memeber?
* Welcher Permissions gibts im MOS?
+
* Welcher Permissions gibts im MOS? [fin: admin ja/nein, member ja/nein (indirekt), key ja/nein (indirekt)]
 
* Hat er/sie einen Schlüssel?
 
* Hat er/sie einen Schlüssel?
 
* Ist er /sie auf der Mailingliste?
 
* Ist er /sie auf der Mailingliste?

Version vom 21. Januar 2012, 18:50 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.


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.