obsidian-task-collector icon indicating copy to clipboard operation
obsidian-task-collector copied to clipboard

[Feature] Better support for mixed completion

Open bbbco opened this issue 10 months ago • 3 comments

I have a setup like so:

## TODO
- [ ] Major task A
  - [X] Minor task 1
  - [ ] Minor task 2
    - [ ] Patch task i
    - [x] Patch task ii 
- [ ] Major task B
  - [ ] Minor task 1
  - [X] Minor task 2
  - [ ] Minor task 3
- [X] Major task C
## LOG

When collecting tasks, the plugin is just collecting the marked tasks straight up and removing the context from the incomplete tasks. However, I would expect them to be collected like so:

## TODO
- [ ] Major task A
  - [ ] Minor task 2
    - [ ] Patch task i 
- [ ] Major task B
  - [ ] Minor task 1
  - [ ] Minor task 3
## LOG
- Major task A
  - [X] Minor task 1 
  - Minor task 2
    - [x] Patch task ii 
- Major task B
  - [X] Minor task 2
- [X] Major task C

in order to retain context in both the completed and the still unfinished tasks.

bbbco avatar Apr 02 '24 14:04 bbbco

Ah. That is an interesting idea. hmm.

  • Would you expect subsequent subtasks to also go under that heading?
  • And then what happens when the parent task is finally completed?
  • What happens if you change the text of the parent task (if there is some semblance of continuity)

Would it be better/different to make the parent a blockref ^somethign, and have the moved child items link back to the blockref?

ebullient avatar Apr 02 '24 20:04 ebullient

I think what I'm asking is to retain the context in both the collected and leftover group of tasks.

  • Would you expect subsequent subtasks to also go under that heading?

I'm not quite sure I understand this question

  • And then what happens when the parent task is finally completed?

Good question. If a parent task is marked as completed but there are still children tasks left uncompleted, what should happen? Maybe the inverse of what I had originally suggested, where the parent task is collected as a task, and the context is preserved in the original checkbox structure. For example:

## TODO
- [X] Major task A
  - [X] Minor task 1
  - [ ] Minor task 2
    - [ ] Patch task i
    - [x] Patch task ii 
## LOG

becomes

## TODO
- Major task A
  - [ ] Minor task 2
    - [ ] Patch task i 
## LOG
- [X] Major task A
  - [X] Minor task 1 
  - Minor task 2
    - [x] Patch task ii 

What happens if you change the text of the parent task (if there is some semblance of continuity)

I don't think anything happens until the next time a collection action would run, right?


I attempted the idea of embedding a blockref of the parent and it embedded the task and subtasks (see Major Task A):

## TODO
- [ ] Major task A ^major-task-a
  - [ ] Minor task 2
    - [ ] Patch task i
- [ ] Major task B
  - [ ] Minor task 1
  - [ ] Minor task 3
## LOG
![[#^major-task-a]]
  - [X] Minor task 1 
  - Minor task 2
    - [x] Patch task ii 
- Major task B
  - [X] Minor task 2
- [X] Major task C

image

I'm not sure this is the desired behavior.

In my mind, the Collection feature is meant to collect tasks at a given point in time. However, it shouldn't gather non-completed items, but it should retain the context of nested checkbox lists in the above examples.

bbbco avatar Apr 03 '24 17:04 bbbco

In my mind, the Collection feature is meant to collect tasks at a given point in time.

This is exactly how I use it.

Management of subtasks is always dicey, because the more context I try to account for, the easier it is to get it wrong and really mess things up. Moving single line entries between sections: yes. Moving single line entries and their sub-entries between sections? yes. Moving some subset based on completion gets weird (what gets collected and what stays behind? How should or would it be regrouped when everything is completed again?)

Over time, I've adapted my workflow such that I don't worry about partial tasks/context in this way. When I'm planning my work, I end up pulling subtasks out/up into better scoped top-level tasks (sometimes marked with a prefix). My Log section ends up being a flat list that I can easily scan. Nested content is all notes related to completing that task. Prefixes allow me to group them together mentally. I could use other tools to group "list items starting with x" if I had to, but I've never found this to be necessary.

I guess, in thinking about how to solve this problem when I started the plugin, I landed on a place that simplified my notes and my workflow instead.

ebullient avatar Apr 22 '24 13:04 ebullient