Zum Inhalt springen

Metalab OS/Calendaring: Unterschied zwischen den Versionen

Frank (Diskussion | Beiträge)
Frank (Diskussion | Beiträge)
endlich ein update! (& re-org)
 
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 ==


Zeile 35: Zeile 72:
=== Modify Entry ===
=== Modify Entry ===


Ein Benutzer verändert die Daten einer Veranstaltung. Für ACs erfolgt
Ein Benutzer verändert die Daten einer Veranstaltung. <strike>Für ACs erfolgt
wiederum ein Verifizierungsschritt. Ist der Benutzer nicht der ursprüngliche
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
Ersteller einer Veranstaltung, wird diesem eine Benachrichtigung über die
Veränderung per Email geschickt.
Veränderung per Email geschickt.
Zeile 52: Zeile 92:
Veränderung einzelner Termine einer sich wiederholenden Veranstaltung wird es wahrscheinlich in der ersten Version noch nicht geben:
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...)
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 der Soruces ist im Subversion: https://ma.metalab.at/svn/cmos/trunk/metacal/
Erste '''öffentliche beta-Version''' (Danke [[Benutzer:Metaz|Stefan]]!): http://mos.metalab.at/calendar/
<br />
(Wie erwähnt nicht menschenwürdig navigierbar... Neue Events "new/", Monatsliste "''jahr''/''monat''".)
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)
Neuerungen / Features
* Jetzt sind Events doch tatsächlich editierbar...
* 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 ===
* Userinterface
** Benutzbarkeit: Navigationselemente etc. (derzeit heißt es URLs tippen!)
** Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen
** refactor templates
* Veranstaltungen absagen fehlt noch
* Handling von ACs
** Wie soll das Editieren durch ACs gehandhabt werden?
** Token per Email für neu angelegte Veranstaltungen von ACs
* 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.)