* DONE Building a Task Manager: Tag Inheritance :blog:dev:tech:
CLOSED: [2024-10-01 Tue 10:30]
:PROPERTIES:
:ID:       mostr-tags
:CREATED:  [2024-10-01 Tue 10:30]
:END:
:LOGBOOK:
- State "DONE"       from              [2024-10-01 Tue 09:56]
:END:
I am building a Task Manager called [[https://forge.ftt.gmbh/janek/mostr][mostr]]
where I am testing a lot of surprisingly novel concepts.
Fundamentally,
all tasks are organized in a tree rather than a pretermined project/subtasks structure.
This allows tracking time by simply moving like through a directory tree.
The currently selected task is the one being time-tracked,
but also heavily influences the creation of new tasks,
which are automatically subtasks of the current task.

Furthermore,
you can attach tags to a task.
Adding a context to your session
then both filters for visible tasks with specific properties
but also adds these properties to any newly created task.

Now I am figuring out
how the selected task should affect the current task,
because there should be some sort of tag inheritance:
Usually subtasks would be annotated with similar tags as their parent tasks.
So initially I thought I could simply match all subtasks of a matching parent task (virtual tag inheritance)
or apply the tags of the parent task to the subtask (physical tag inheritance)
But while I do want straightforward and intuitive defaults,
I also want to maintain maximum flexibility
so that mostr can accomodate different power users.
But cases like this would not be handled well by the above options of inheritance:

#+begin_src
Mostr #pc #dev
|- Think about Feature #think
|- Write about Feature #pc #write
|- Implement Feature #pc #dev
#+end_src

When I work on mostr, I am generally on the computer,
which is why it has the pc tag.
But there are also tasks in that project
that do not necessarily happen on the computer.
And how do the task tags interact with an active context?

When entering a task, we have three cases to handle:
- no current context
- current context subset of task tags (common case, when navigating through the tree)
- mismatch of current context and task tags (when jumping to a specific task)

With that in mind, I came up with the idea of virtual tags.
When you enter a task and there is no existing context,
the virtual tags behave like a transient context,
both applying to filtering and creation.
If the context is a subset of the current task tags,
the extra tags only apply to creation of subtasks.
If there is a mismatch,
the current context is apparently obsolete,
so it is removed before proceeding as if there was no context.

So the remaining question is how to remove virtual tags
if you want to find or create a subtask
which only has a subset of those.
This touches the issue of storage:
The context is a list of tags and excluded tags
(tasks with these tags are hidden from view, not explicitly relevant here)
and I presumed I could derive the virtual tags from the selected task
without storing them separately.
But to allow removing a virtual tag,
I either need to track removed virtual tags
or current virtual tags.
This becomes even more tricky
when moving up and down with such tasks.
So when I enter mostr,
I have the virtual tags ~#pc #dev~ -
I remove them to enter the thinking task -
but then what happens when I move up again?
Per default,
the virtual tags would be active again,
unless the removal of virtual tags is also tracked in the context,
which might just be the most effective way.