Metalab OS/Calendaring: Unterschied zwischen den Versionen
Frank (Diskussion | Beiträge) (-1. versuch) |
Frank (Diskussion | Beiträge) (endlich ein update! (& re-org)) |
||
| (11 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| + | == Status der Implementierung == | ||
| + | |||
| + | Erste '''öffentliche beta-Version''' (Danke [[Benutzer:Metaz|Stefan]]!): http://mos.metalab.at/calendar/ | ||
| + | <br /> | ||
| + | |||
| + | Neuerungen / Features | ||
| + | * Handhabung von ACs nun vollständig implementiert. | ||
| + | * Umstieg auf die [http://www.djangoproject.com/documentation/newforms/ newforms] library. | ||
| + | * Implementierte Usecases: | ||
| + | ** Browsen nach Jahr/Monat/Woche/Tag/upcoming | ||
| + | ** neuen Termin eintragen | ||
| + | ** Termin bearbeiten | ||
| + | * Export als icalendar [http://www.ietf.org/rfc/rfc2445.txt]. | ||
| + | * RSS und Atom Feeds | ||
| + | |||
| + | Aktuelle Version der Sources ist im Subversion: https://ma.metalab.at/svn/cmos/trunk/metacal/ | ||
| + | |||
| + | Voraussetzungen zum Mitcoden: | ||
| + | * 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) | ||
| + | |||
| + | === TODOs === | ||
| + | |||
| + | * Userinterface | ||
| + | ** Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen | ||
| + | ** refactor templates | ||
| + | * Veranstaltungen absagen fehlt noch | ||
| + | * Modell weiter verfeinern | ||
| + | ** Zielgruppe / öffentlich oder privat | ||
| + | ** benötigte Ressourcen (z.B. Beamer) | ||
| + | * andere Prozesse automatisiert anstoßen | ||
| + | ** Auto-Announces auf Mailinglisten | ||
| + | ** Update anderer Kalender und verwandter Dienste (upcoming.org etc.) | ||
| + | |||
== Use Cases == | == Use Cases == | ||
Rollen: | Rollen: | ||
* AC: ein beliebiger unauthentifizierter Benutzer | * AC: ein beliebiger unauthentifizierter Benutzer | ||
| − | * | + | * registered User: ein authentifizierter Benutzer |
* Calendar Admin: ein authentifizierter Benutzer mit administrativen Privilegien | * Calendar Admin: ein authentifizierter Benutzer mit administrativen Privilegien | ||
| Zeile 12: | Zeile 49: | ||
Monat, nächste n Tage und Liste der nächsten n Veranstaltungen | Monat, nächste n Tage und Liste der nächsten n Veranstaltungen | ||
wechseln. | wechseln. | ||
| − | Zudem kann die | + | Zudem kann die Ansicht auf bestimmte Räume eingeschränkt werden. |
Der AC kann einzelne Veranstaltungen anwählen, um die dazugehörigen | Der AC kann einzelne Veranstaltungen anwählen, um die dazugehörigen | ||
| − | Details (was, wann, wo, | + | Details (was, wann, wo, Beschreibung, url, ...) einzusehen. |
| − | === | + | === Retrieve Feed === |
Ein AC ruft über http einen RSS (oder Atom?) Feed der nächsten n | Ein AC ruft über http einen RSS (oder Atom?) Feed der nächsten n | ||
Veranstaltungen ab. | Veranstaltungen ab. | ||
| − | === | + | === Add Entry === |
| − | Ein | + | 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 === | === Modify Entry === | ||
| − | Ein | + | Ein Benutzer verändert die Daten einer Veranstaltung. <strike>Für ACs erfolgt |
| − | + | wiederum ein Verifizierungsschritt.</strike> | |
| − | + | ACs können nur ihre eigenen Veranstaltungen editieren, denn als AC muß das | |
| + | für die Bestätigung verwendete Token abermals eingegeben werden. | ||
| + | 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 [http://www.ietf.org/rfc/rfc2445.txt iCalendar RRULEs]. | |
| + | Wie daraus Datum und Uhrzeit einzelner Wiederholungen bestimmt werden, erledigt dankbareweise das Modul [http://labix.org/python-dateutil dateutil]. | ||
| − | Veränderung einzelner Termine einer sich wiederholenden Veranstaltung: | + | 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...) | |
| − | Veranstaltung. | ||
Aktuelle Version vom 30. März 2007, 19:04 Uhr
Status der Implementierung
Erste öffentliche beta-Version (Danke Stefan!): http://mos.metalab.at/calendar/
Neuerungen / Features
- Handhabung von ACs nun vollständig implementiert.
- Umstieg auf die newforms library.
- Implementierte Usecases:
- Browsen nach Jahr/Monat/Woche/Tag/upcoming
- neuen Termin eintragen
- Termin bearbeiten
- Export als icalendar [1].
- RSS und Atom Feeds
Aktuelle Version der Sources ist im Subversion: https://ma.metalab.at/svn/cmos/trunk/metacal/
Voraussetzungen zum Mitcoden:
- Eine Django-Installation der Entwicklungsversion (kein Release!)
- Die aktuelle Version der MOS Entwicklungsumgebung
- Extra-Module
- http://codespeak.net/icalendar/ (iCalendar-Export)
- http://labix.org/python-dateutil (recurrence rules)
TODOs
- Userinterface
- Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen
- refactor templates
- Veranstaltungen absagen fehlt noch
- Modell weiter verfeinern
- Zielgruppe / öffentlich oder privat
- benötigte Ressourcen (z.B. Beamer)
- andere Prozesse automatisiert anstoßen
- Auto-Announces auf Mailinglisten
- Update anderer Kalender und verwandter Dienste (upcoming.org etc.)
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.
ACs können nur ihre eigenen Veranstaltungen editieren, denn als AC muß das
für die Bestätigung verwendete Token abermals eingegeben werden.
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...)
