vgwidt / sumi

Multi-user issue tracking and knowledge base app built with Yew & Actix
MIT License
10 stars 1 forks source link

Add tasklists #23

Open vgwidt opened 1 year ago

vgwidt commented 1 year ago

Tickets should be able to have tasklists associated with them with a list of items to do. Github Issues does something interesting in that it looks for all checkboxes in the original issue posting. I think that would be nice, but I also believe a task list should be more dynamic and that the description of a ticket generally won't change much. I think it would be cool to have an immediately editable task list section in a ticket where tasks can be managed. This will require a new table for tasks.

vgwidt commented 1 year ago

Design decision: do I want to put the tasklist inside of the description, or add a separate module for it? If it is separate, I'd also want to add a "task_group" table so that tasks could be split into groups for a ticket. We wouldn't need to do that inside a description as the user could add headers etc.

vgwidt commented 1 year ago

The today version of me thinks that separating task lists is better. I still feel the description should be relatively static (despite configuring versioning). It feels weird to go back and edit the ticket every time a task needs to be added, removed, or changed.

vgwidt commented 1 year ago

Do we want to create a default/generic task group? I did not give the opportunity to null the group_id for a task, but this would allow the addition of a ticket_id field to attach a task directly to a ticket. At the time I was thinking I'd just create a default task group like To-do {date}

TASKLIST [+Task] [+Group] :: tasks without group?

:: To-do 20230314 [+Task][Edit][-Delete] :: [ ] To do [Edit][-Delete]

:: To-do group 2 [+Task][Edit][-Delete] :: [ ] To do [Edit][-Delete]

vgwidt commented 1 year ago

Still struggling with having tasks related to tickets and tasks related to groups.

I could have a tasks table, then a ticket_tasks table and group_tasks table that distinguishes them (https://stackoverflow.com/questions/10068033/postgresql-foreign-key-referencing-primary-keys-of-two-different-tables), but also still considering a "default" group for every ticket, which could be defined as root using something like order_index 0. The tasks branch currently forces a task to be in a group. I could leave it like that but I have reservations about it as I think it would be more likely that simple groupless tasks would be added. But I definitely like the idea of task grouping.

vgwidt commented 1 year ago

Note on components re-rendering: when added and deleting, it doesn't rerender the list of available groups/tasks correctly, so when editing or deleting it may delete the wrong one. As a workaround, when adding or removing, the entire tasklist is cleared and re-fetched.

vgwidt commented 1 year ago

Task groups don't feel good to use. It takes a lot of work just to create the first task. If task groups are wanted, we have to add a quick task option that either creates a default task group for the ticket and adds to that (how do we know its the default? order?) or nix task groups and just link tasks to tickets. I definitely want to make the option available for groups somehow though.