Metalab OS/Calendaring: Unterschied zwischen den Versionen
Pk (Diskussion | Beiträge) |
Frank (Diskussion | Beiträge) update & 1st public version |
||
Zeile 21: | Zeile 21: | ||
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. 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 == | == Recurrence == | ||
1 2 3 | 1 2 3 | ||
- | D - n every nth day | ||
n | W - n weekday(date) of the week every n weeks | ||
- n | M - n monthday(date) of the month every n months | ||
m n | M m n every mth weekday(date) every nth month | ||
1. | 1. interval (day, week, month) | ||
2. | 2. week of the month (1st, 2nd, 3rd, 4th, last) | ||
3. stride (every nth interval) | |||
Daraus Belegung im Kalender berechnen. | Daraus Belegung im Kalender berechnen. | ||
Zeile 58: | Zeile 62: | ||
werden extra eingetragen und referenzieren die ursprüngliche | werden extra eingetragen und referenzieren die ursprüngliche | ||
Veranstaltung. | Veranstaltung. | ||
== Status der Implementierung == | |||
Es gibt inzwischen eine sehr rudimentäre Version: [[Bild:Metacal-0.0.1.tar.gz]] | |||
=== 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. | |||
* 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 | |||
* Daten angemeldeter Benutzer nutzen | |||
* Übersetzungen: Sprachakuderwelsch entwirren, deutsche & englische Texte erstellen | |||
* Modell weiter verfeinern |