Metalab OS/Calendaring: 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
(neue source-version & generelles update)
Zeile 47: Zeile 47:
 
== Recurrence ==
 
== Recurrence ==
  
1 2 3
+
Der Kalender benutzt ein Subset der [http://www.ietf.org/rfc/rfc2445.txt iCalendar RRULEs].
D - n  every nth day
+
Wie daraus Datum und Uhrzeit einzelner Wiederholungen bestimmt werden, erledigt dankbareweise das Modul [http://labix.org/python-dateutil dateutil].
W - n  weekday(date) of the week every n weeks
 
M - n  monthday(date) of the month every n months
 
M m n  every mth weekday(date) every nth month
 
  
1. interval (day, week, month)
+
Veränderung einzelner Termine einer sich wiederholenden Veranstaltung wird es wahrscheinlich in der ersten Version noch nicht geben:
2. week of the month (1st, 2nd, 3rd, 4th, last)
+
Der generelle Plan ist, für die veränderten Termine einen extra Eintrag zu machen und die ursprüngliche Veranstaltung auszusetzen. (Letzteres ist bisher im Datenmodell noch gar nicht vorgesehen...)
3. stride (every nth interval)
 
  
Daraus Belegung im Kalender berechnen.
+
== Status der Implementierung ==
  
Veränderung einzelner Termine einer sich wiederholenden Veranstaltung:
+
Aktuelle Version: [[Bild:Metacal.zip]]
werden extra eingetragen und referenzieren die ursprüngliche
 
Veranstaltung.
 
 
 
== Status der Implementierung ==
 
  
Es gibt inzwischen eine sehr rudimentäre Version: [[Bild:Metacal.zip]]
+
Voraussetzungen:
 +
* Eine [http://www.djangoproject.com/ Django]-Installation der Entwicklungsversion (kein Release!)
 +
* Die aktuelle Version der [[MOS#Entwicklungsumgebung|MOS Entwicklungsumgebung]]
 +
* Extra-Module
 +
** http://codespeak.net/icalendar/ (iCalendar-Export)
 +
** http://labix.org/python-dateutil (recurrence rules)
  
Neu ist der Export als icalendar [http://www.ietf.org/rfc/rfc2445.txt]. Dafür braucht's allerdings das passende
+
Neuerungen / Features
[http://codespeak.net/icalendar/ python modul].
+
* Umstieg auf die [http://www.djangoproject.com/documentation/newforms/ newforms] library.
 +
* Implementierte Usecases: Browsen nach Jahr/Monat/Woche/Tag (wenn wir von der Navigation mal absehen...), neuen Termin eintragen
 +
* Export als icalendar [http://www.ietf.org/rfc/rfc2445.txt].
 +
* RSS und Atom Feeds
  
 
=== TODOs ===
 
=== TODOs ===
  
* Editieren von Events: derzeit broken, denn die Validators für's Modell verlangen Werte, die zwar für jedes Event definiert, aber nicht änderbar sein müssen.
+
* Editieren von Events: derzeit broken, gleich in newforms implementieren.
 
* Benutzbarkeit: Navigationselemente etc. (derzeit heißt es URLs tippen!)
 
* Benutzbarkeit: Navigationselemente etc. (derzeit heißt es URLs tippen!)
 
* Templates überarbeiten: da ist sehr viel Redundanz drin
 
* Templates überarbeiten: da ist sehr viel Redundanz drin
 
* Token per Email für Aktionen von ACs
 
* Token per Email für Aktionen von ACs
* Daten angemeldeter Benutzer nutzen
 
 
* Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen
 
* Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen
 
* Modell weiter verfeinern
 
* Modell weiter verfeinern

Version vom 13. Februar 2007, 18:32 Uhr

Use Cases

Rollen:

  • AC: ein beliebiger unauthentifizierter Benutzer
  • registered User: ein authentifizierter Benutzer
  • Calendar Admin: ein authentifizierter Benutzer mit administrativen Privilegien

View Calendar

Ein AC sieht sich mittels eines Browsers eine HTML-Repräsentation des metalab-Kalenders an. Der AC kann zwischen den Ansichten Tag, Woche, Monat, nächste n Tage und Liste der nächsten n Veranstaltungen wechseln. Zudem kann die Ansicht auf bestimmte Räume eingeschränkt werden. Der AC kann einzelne Veranstaltungen anwählen, um die dazugehörigen Details (was, wann, wo, Beschreibung, url, ...) einzusehen.

Retrieve Feed

Ein AC ruft über http einen RSS (oder Atom?) Feed der nächsten n Veranstaltungen ab.

Add Entry

Ein Benutzer erstellt eine neue Veranstaltung mit allen dazugehörigen Daten (was, wann, wo, Beschreibung, url, ...).

ACs müssen eine Email-Adresse angeben, über die eine Verifizierung des Termins erfolgt (a la mailman): Durch Eingabe eines per Mail übermittelten Tokens wird der Termin bestätigt und sichergestellt, daß die Email-Adresse auch erreichbar ist.

Für registered User fällt der Verifizierungsschritt.

Modify Entry

Ein Benutzer verändert die Daten einer Veranstaltung. Für ACs erfolgt wiederum ein Verifizierungsschritt. Ist der Benutzer nicht der ursprüngliche Ersteller einer Veranstaltung, wird diesem eine Benachrichtigung über die Veränderung per Email geschickt.

Administer Entry

Ein Calender Admin modifiziert eine Veranstaltung direkt über das Admin-Interface von Django.

Recurrence

Der Kalender benutzt ein Subset der iCalendar RRULEs. Wie daraus Datum und Uhrzeit einzelner Wiederholungen bestimmt werden, erledigt dankbareweise das Modul dateutil.

Veränderung einzelner Termine einer sich wiederholenden Veranstaltung wird es wahrscheinlich in der ersten Version noch nicht geben: Der generelle Plan ist, für die veränderten Termine einen extra Eintrag zu machen und die ursprüngliche Veranstaltung auszusetzen. (Letzteres ist bisher im Datenmodell noch gar nicht vorgesehen...)

Status der Implementierung

Aktuelle Version: Datei:Metacal.zip

Voraussetzungen:

Neuerungen / Features

  • Umstieg auf die newforms library.
  • Implementierte Usecases: Browsen nach Jahr/Monat/Woche/Tag (wenn wir von der Navigation mal absehen...), neuen Termin eintragen
  • Export als icalendar [1].
  • RSS und Atom Feeds

TODOs

  • Editieren von Events: derzeit broken, gleich in newforms implementieren.
  • Benutzbarkeit: Navigationselemente etc. (derzeit heißt es URLs tippen!)
  • Templates überarbeiten: da ist sehr viel Redundanz drin
  • Token per Email für Aktionen von ACs
  • Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen
  • Modell weiter verfeinern