Consider how to handle "subtasks when parent matches" (with --match)

[bjohas]

DIscussion in issue #4 noted:

When filtering against the --match word, we first check the parents, and only if the parent matches do we look in the child tasks of the parent. We could swap this over to also looking in those ignored ones, but it's a little tricky and we would need to decide what that would looks like. Such as a line in the output or something. Can let me know if we what to chase that one.

Atm, if the entry matches, it's processed. However, if the subitems do not match as well, they are dropped. We need an option that is something like this:

--subtasks process_if_parent_matches
--subtasks drop_if_parent_matches_but_subtasks_does_not
--subtasks keep_parent_if_parent_matches_but_subtasks_does_not

[bjohas]

Related to #19

[Resinderate]

I think I understand this one, I think this could possibly branch out into at least 4 different modes (if not more).

Things like:

• Simple tree matching search (current behaviour): Only look in sub tasks if parents match. Parents are included if they match by themselves. (I think covers "--subtasks keep_parent_if_parent_matches_but_subtasks_does_not"?)
• Deep matching search: All children are looked at, if the child matches the parent is included regardless. (As we need it to exists, and have the child in the sub_tasks.
• Parent only search: Only search against parents. If a parent matches, include all children without filtering. (Think matches "--subtasks process_if_parent_matches")
• Parent and Child combo search: Like #1 Simple tree matching search, but if a parent doesn't have any matching children, discard it.

Do you have some example parent tasks and their sub tasks for some context? It might give me some better initiative as to how it should behave.

The naming for this might be quick tricky, I think you're along the right lines that it should be a separate option. Perhaps something like --filter-mode might make sense as it's altering the behaviour of the filter. It might be a good idea to give them short aliases which can be explained further in the --help.

This one sounds like it might be a bit tricky to get right, and would definitely need some unit tests to ensure it's doing what we expect. Estimate: 3-4~ hours for the modes described above.

[bjohas]

I suppose we could look for the simplest path here, and initially just implement the most likely one? I think the one that's most urgent is:

Parent only search: Only search against parents. If a parent matches, include all children without filtering. (Think matches "--subtasks process_if_parent_matches")

I.e, the current behaviour is as follows. Task like this:

• Task 1 MATCH_STR
  -- SubTask A
  -- SubTask B

Only Task 1 is presented to the script, while SubTasks A/B are dropped. In the above case, either

1. The whole task (Task 1 + subtasks) should be presented to the pipeto (that's my preference, "--subtasks process_if_parent_matches")
2. Or: Task 1 should be presented to the pipeto, but should not be marked as done (as that leads to the loss of the subtasks, "--subtasks keep_parent_if_parent_matches_but_subtasks_does_not").

I would be happy to just implement "--subtasks process_if_parent_matches" (1) for now, as that's my preference. I imagine it's easier too?

I've reopened #19 to discuss subtasks there.

[Resinderate]

Yep makes sense. 1. is indeed easier so I've taken that path for now.

Added a new --match-mode optional argument which alters how the --match term is used. Default is default and matches the current behaviour. Added a new mode parent-match which will just match against the parents, and if the parent match will include all sub_tasks regardless of content.

Example usage:

./gtasks process --list "Another List" --match meetings --match-mode parent-match

[bjohas]

Great, this works!

I would propose to rename it. It's not really a 'match-mode', but decides what happens with the sub-tasks if a parent matches.

--pipeto-mode always-include-subtasks
--pipeto-mode parent-only

The first one should be the default. (The 2nd one can lead to data loss.... so should not be the default).