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 Ideas

• Priorities
• Repeating tasks
• Get all tasks which are due between two given dates
• Subtasks

Anderes

• Refactor!!!! Delete everything not being used anymore, simplify.
• Drone
• Tests
• Find a nme
• Move packages to a better structure
• Swagger UI

• Fix CORS

• Use echo.NewHTTPError instead of c.JSON(Message{})
• Better error messages when the model which is sent to the server is wrong
• Better error handling to show useful error messages and status codes
• Viper for config instead of ini
• Docs for installing
• Tests for rights managemnt
• Rights checks: * [x] Create lists * [x] Edit lists * [x] Add tasks * [x] Edit tasks
• The -1 namespace should also be accessible seperately

Short Term

• Cacher configurable
• Should throw an error when an id < 1
• /users should also return the rights
• Extra endpoint /teams/members /list/users to update rights without needing to remove and re-add them
• namespaces & listen update does not work, returns 500
• Logging for all errors somewhere
• 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 dev -> Docs
  • License
  • Contributing
• Redocs
• Swaggerdocs verbessern
  • Descriptions in structs
  • Maxlength specify etc. (see swaggo docs)
• Rights
• API
• Anleitung zum Makefile
• How to build from source
• Struktur erklären
• 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"
  • Roles which enable or disable chaning certain fields of a task -> includes custm fields
• Custom fields: Templates at List > Namespace > Global level, overwriting each other
• Related tasks -> settable with a "kind" of relation like blocked, or just related or so
• Description should be longtext

General features

• Deps nach mod umziehen
• Performance bei rechtchecks verbessern
  • User & Teamright sollte sich für n rechte in einer Funktion testen lassen
• Endpoint um die Rechte mit Beschreibung und code zu kriegen
• "Smart Lists", Listen nach bestimmten Kriterien gefiltert -> speichern und im pseudonamespace
• "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
  • Being able to define filters for notifications or turn them silent completely -> Probably frontend only
• 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
• Bindata for templates
• GetUserByID and the likes should return pointers
• Colors for lists and namespaces -> Up to the frontend to implement these
• Some kind of milestones for tasks
• Create tasks from a text/markdown file (probably frontend only)
• Label-view: Get a bunch of tasks by label
• Better caldav support (VTODO)
• Debian package should have a service file
• Downloads should be served via nginx (with theme?), minio should only be used for pushing artifacts.

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.
• Things like list/task order should use queries and not url params
• Fix lint errors

Linters

• goconst
• Staticcheck -> waiting for mod
• gocyclo-check
• gosec-check -> waiting for mod
• goconst-check -> 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
• More sharing features (all of these with the already existing permissions)
  • Invite users per mail
  • Share a link with/without password
• Comments on tasks
• @mention users in tasks or comments to get them notified
• Summary of tasks to do in a configurable interval (every day/week or so)
• Importer (maybe frontend only)
  • Trello
  • Wunderlist
  • Zenkit
  • Asana
  • Microsoft Todo
  • Nozbe
  • Lanes
  • Nirvana
  • Good ol' Caldav (Tasks)
• More auth providers
  • LDAP/AD
  • Kerberos
  • SAML (what?)
  • smtp
  • OpenID