vikunja-api/Featurecreep.md

Featurecreep

This is the place where I write down ideas to work on at some point. Sorry for some of them being in German, I'll tranlate them at some point.

Feature-Ideen

• Priorities
• Repeating tasks
• Tagesübersicht ("Was ist heute/diese Woche due?") -> Machen letztenendes die Clients, wir brauchen nur nen endpoint, der alle tasks auskotzt, der Client macht dann die Sortierung.
• Subtasks

Anderes

• Refactor!!!! Alle Funktionen raus, die nicht mehr grbaucht werden + Funktionen vereinfachen/zusammenführen. Wenn ein Objekt 5x hin und hergereicht wird, und jedesmal nur geringfügig was dran geändert wird sollte das doch auch in einer Funktion machbar sein. * [x] ganz viel in eigene neue Dateien + Packages auslagern, am besten eine package pro model mit allen methoden etc. * [x] Alle alten dinger die nicht mehr gebraucht werden, weg. * [x] Die alten handlerfunktionen alle in eine datei packen und erstmal "lagern", erstmal brauchen wir die noch für swagger.
• Drone aufsetzen
• Tests schreiben
• Namen finden
• Alle Packages umziehen
• Swagger UI aufsetzen

• CORS fixen

• Überall echo.NewHTTPError statt c.JSON(Message{}) benutzen
• Bessere Fehlermeldungen wenn das Model was ankommt falsch ist und nicht geparst werden kann
• Fehlerhandling irgendwie besser machen. Zb mit "World error messages"? Sprich, die Methode ruft einfach auf obs die entsprechende Fehlermeldung gibt und zeigt sonst 500 an.
• Viper für config einbauen und ini rauswerfen
• Docs für installationsanleitung
• Tests für Rechtekram
• "Apiformat" Methoden, damit in der Ausgabe zb kein Passwort drin ist..., oder created/updated von Nutzern... oder ownerID nicht drin ist sondern nur das ownerobject
• Rechte überprüfen: * [x] Listen erstellen * [x] Listen bearbeiten (nur eigene im Moment) * [x] Listenpunkte hinzufügen * [x] Listenpunkte bearbeiten
• Der -1 namespace sollte auch seperat angesprochen werden können, gibt sonst probleme mit der app.

Short Term

• Cacher konfigurierbar
• Wenn die ID bei irgendeiner GetByID... Methode < 1 ist soll ein error not exist geworfen werden
• /users sollte die Rechte mit ausgeben
• Nen endpoint um /teams/members /list/users etc die Rechte updazudaten ohne erst zu löschen und dann neu einzufügen
• namespaces & listen updaten geht nicht, gibt nen 500er zurück
• Logging für alle Fehler irgendwohin, da gibts bestimmt ne coole library für
• Ne extra funktion für list exists machen, damit die nicht immer über GetListByID gehen, um sql-abfragen zu sparen
• Rausfinden warum xorm teilweise beim einfügen IDs mit einfügen will -> Das schlägt dann wegen duplicate fehl
• Bei den Structs "AfterLoad" raus, das verbraucht bei Gruppenabfragen zu viele SQL-Abfragen -> Die sollen einfach die entsprechenden Read()-Methoden verwenden (Krassestes bsp. ist GET /namespaces mit so ca 50 Abfragen)
• General search endpoints
• Validation der ankommenden structs, am besten mit https://github.com/go-validator/validator oder mit dem Ding von echo
• Pagination
  • Sollte in der Config definierbar sein, wie viel pro Seite angezeigt werden soll, die CRUD-Methoden übergeben dann ein "gibt mir die Seite sowieso" an die CRUDable-Funktionenen, die müssen das dann Auswerten. Geht leider nicht anders, wenn man erst 2342352 Einträge hohlt und die dann nachträglich auf 200 begrenzt ist das ne massive Ressourcenverschwendung.
• Testen, ob man über die Routen methode von echo irgendwie ein swagger spec generieren könnte -> Andere Swagger library
• CalDAV
  • Basics
  • Reminders
  • Discovery, stichwort PROPFIND
• Wir brauchen noch ne gute idee, wie man die listen kriegt, auf die man nur so Zugriff hat (ohne namespace)
  • Dazu am Besten nen pseudonamespace anlegen (id -1 oder so), der hat das dann alles
• Testing mit locust: https://locust.io/

Userstuff

• Userstuff aufräumen -> Soweit es geht und Sinnvoll ist auf den neuen Handler umziehen -> Login/Register/Password-reset geht natürlich nicht -> Bleibt noch Profile abrufen und Einstellungen -> Macht also keinen Sinn das auf den neuen Handler umzuziehen
• Email-Verifizierung beim Registrieren
• Password Reset -> Link via email oder so
• Settings
  • Password update
  • Email update
  • Ob man über email oder Benutzernamen gefunden werden darf

Bugfixes

• Panic wenn mailer nicht erreichbar -> Als workaround mailer deaktivierbar machen, bzw keine mails verschicken
• "unexpected EOF"
• Beim Login & Password reset gibt die API zurück dass der Nutzer nicht existiert

Docs

• Readme
  • Auch noch nen "link" zum Featurecreep
  • ToC
  • Logo
  • How to build -> Docs
  • How to use -> Docs
  • How to dev -> Docs
  • License
  • Contributing
• Redocs
• Swaggerdocs verbessern
  • Descriptions in structs
  • Maxlength specify etc. (see swaggo docs)
• Rights
• API
• Anleitung zum Makefile
• Struktur erklären
• How to build from source
• Dev instructions (tests, makefile, mod, structure, etc.)
• Deploy in die docs
  • Docker
  • Native (systemd + nginx/apache)
• Backups
• Docs aufsetzen

Tasks

• Start/Enddatum für Tasks
• Timeline/Calendar view -> Dazu tasks die in einem Bestimmten Bereich due sind, macht dann das Frontend
• Tasks innerhalb eines definierbarem Bereich, sollte aber trotzdem der server machen, so à la "Gib mir alles für diesen Monat"
• Bulk-edit -> Transactions
• Assignees
  • Check if something changed at all before running everything
  • Don't use list.ReadOne(), gets too much unnessecary shit
  • Wegen Performance auf eigene endpoints umziehen, wie labels
  • "One endpoint to rule them all" -> Array-addable
• Labels
  • Check if something changed at all before running everything
  • Editable via task edit, like assignees
  • "One endpoint to rule them all" -> Array-addable
• Attachments
• Task-Templates innerhalb namespaces und Listen (-> Mehrere, die auswählbar sind)
• Ein Task muss von mehreren Assignees abgehakt werden bis er als done markiert wird
• Besseres Rechtesystem, damit man so fine-graded sachen machen kann wie "Der da darf aber nur Tasks hinzufügen, aber keine abhaken"

General features

• Deps nach mod umziehen
• Performance bei rechtchecks verbessern
  • User & Teamright sollte sich für n rechte in einer Funktion testen lassen
• "Smart Lists", Listen nach bestimmten Kriterien gefiltert -> nur UI?
• "Performance-Statistik" -> Wie viele Tasks man in bestimmten Zeiträumen so geschafft hat etc
• IMAP-Integration -> Man schickt eine email an Vikunja und es macht daraus dann nen task -> Achtung missbrauchsmöglichkeiten
• In und Out webhooks, mit Templates vom Payload
• Reminders via mail
• Activity Feed, so à la "der und der hat das und das gemacht etc"
  • Per list
  • For the current user
• Websockets SSE https://github.com/kljensen/golang-html5-sse-example * User authenticates (with jwt) * When updating/creating/etc an event struct is sent to the broker * The broker has a list of subscribed users * It then checks who is allowed to the see the event it recieved and sends it
• mgl. zum Emailmaskieren haben (in den Nutzereinstellungen, wenn man seine Email nicht an alle Welt rausposaunen will)
• Mgl. zum Accountlöschen haben (so richtig krass mit emailverifiezierung und dass alle Privaten Listen gelöscht werden und man alle geteilten entweder wem übertragen muss oder auf privat stellen)
• /info endpoint, in dem dann zb die limits und version etc steht
• Deprecate /namespaces/{id}/lists in favour of namespace.ReadOne() <-- should also return the lists

Refactor

• ListTaskRights, sollte überall gleich funktionieren, gibt ja mittlerweile auch eine Methode um liste von nem Task aus zu kriegen oder so
• Re-check all {List|Namespace}{User|Team} if really all parameters need to be exposed via json or are overwritten via param anyway.

Linters

• goconst
• Gosimple -> waiting for mod
• Staticcheck -> waiting for mod
• unused -> waiting for mod
• gosec -> waiting for mod

More server settings

• Caldav disable/enable
• Assignees disable/enable
• List/Namespace limits
• Attachements disable/enable
• Attachements size
• Templates disable/enable
• Stats disable/enable
• Activity notifications disable/enable
• IMAP integration disable/enable
• Reminders via mail disable/enable

Later

• Plugins
• Rename Namespaces?
• Namespaces to collections and n-n (one list can be in multiple collections)?
• Per-User limits of lists/namespaces
• Admin-Interface to do stuff like settings and user management
  • Enable/Disable users
  • Better rights, fine-graded
  • Enable/disable allowing user adding to lists/namespaces for specific lists or namespaces
  • Admins should be able to see and mange all the boards
• Limit registration to users with a defined email domain
• Close the instance, either no registration or only one with defined email
• 2fa
• Custom fields for tasks
• Sorting lists by members, tasks, teams, last modified, etc
• "Favourite lists" -> A user can favourize boards which will then show up in a pseudonamespace
• Public lists
• Internal lists -> Only registered users can see the list
• Rights management for both public and internal lists
• Add new users via to a list which don't have an account yet, they'd get a link to sign up for vikunja.
  • Respect registration email domain limits
• Export all data from Vikunja to json
• Watch a (n internal) list -> Will get notification for everything
• Archive a task instead of deleting
• Task dependencies
• Time tracking (possible plugin)
• IFTTT