I’m experiencing the same limitation that the author of this topic reported a few months ago. The topic has been closed, but the issue still exists. Is there a Tasks bug forum that I could use to report it?
The issue is that with a recurring task with a custom status, when the follow on task is created it is not created with the same status.
For example I want the workflow to be:
[b] → - → [b]
i.e, when the original bookmark task is completed is it closed, and the new recurring task is setup with - instead of - [b].
Sorry for breaking the URL. There appears to be a rule to prevent adding links to posts, which makes it impossible to reflect on other topics. I looked in the FAQ but couldn’t see any rules or reasons that forbade me from doing it, and I didn’t want to reproduce the content of that topic here verbatum.
In most cases a task with any status character is considered completed, and as such is not ready for recurrence. And further more, it’s kind of natural for it to be entering the todo state of " ".
However, you might have some luck if you set the next status of that particular status within _Settings > Tasks > Task Statuses > Custom Statuses > “[b] > …” _, and change that to actually be [b] => [b] ?
If that doesn’t work, I would suggest posting an issue on Tasks github page, or possibly in the Tasks channel on the OMG Discord server. The author of the mentioned plugin frequents that channel often.
It could be your workflow would need some additional coding to allow for it to trigger the recurring if you click on it somehow.
Sadly, I’ve not encountered any tools so far which can maintain sequences, especially when you passing by a common task status, like [x]. There is no knowledge stored anywhere as to what was the previous state, which would be needed in order to determine the proper next state.
The behaviour that I’m looking for is for a new task to retain it’s previous status if it is created from a recurring task that has been marked as done.
Yeah, I understand that, but once you set a new status of a task, it has forgotten the previous state it was in. (With exception of the volatile editing history in the current editor)
If the code that creates the reoccuring task does that before closing the task then it has access to the pre-existing status. I guess it’s just a feature that the author could be pursuaded to consider.
Hence why I hopefully suggested to use [b] => [b], as that could have triggered a status change, which also could have caused the recurring task to actually reoccur. Since this didn’t work, I suggest that you go to the github page of Tasks and suggest such a workflow as a feature request.
It kind of make sense, that changing the task to its own status should also trigger the reocurring procedures.