Modified postpone button behaviour with start date filters

[DanielTMolloy919]

⚠️ Please check that this feature request hasn't been suggested before.

• [X] I searched previous Ideas in Discussions didn't find any similar feature requests.
• [X] I searched previous Issues didn't find any similar feature requests.
• [X] I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• [X] I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

I have been using the postpone feature a ton since it was first introduced - its made organising my tasks 10 times quicker, so a huge thanks to everyone who has helped bring it to production!

My personal use of this plugin is slanted towards start dates, and I use them in the exact way outlined in the documentation. Namely if I can't work on a task today, I use the start date to hide it until I can.

Because of this, the main filter I use is starts on or before today. A really useful behaviour of this filter is that even tasks with no start date set will still show up. This behaviour is unique to start dates, and I've pasted the reasoning given in the documentation below.

When filtering queries by start date, the result will include tasks without a start date. This way, you can use the start date as a filter to filter out any tasks that you cannot yet work on.

This is the exact situation where I feel the need for the postpone button most acutely - I may have 30 tasks that show up from the start date filter, and I want to quickly defer the 10 or so I can't/don't want to work on today. Problem is, at the moment I need to remember to manually set start date to today for all the tasks in my vault, otherwise the postpone button won't show in the query results. This is despite the filter effectively assuming a start day of today for all my tasks where start date is unset.

✔️ Solution

My first instinct is that when the query is filtering start date, the postpone button should always edit the start date, and assumes a start date of today if none is set. This has the added benefit of solving #2573 at the same time, an unexpected behaviour I've also been caught out by.

I'm certainly open to other ways of approaching this problem, whatever is the easiest/most maintainable. For example, maybe it makes more sense to pre-fill the start date with today's date when a task is created (or be able to optionally turn this on in the settings).

Also just to say, if this isn't high priority at the moment, I'm more than happy to shoulder the burden of testing, documentation and implementation. Thanks again!

❓ Alternatives

No response

📝 Additional Context

No response

[claremacrae]

Hi Danny, thanks for the suggestion.

Are start date filters present in the query?

Regarding implementation, the important bit in your request is start date filters.

The rendering of query results is completely independent of the query execution code, and I would like to keep it that way - for maintainability and testability of the code.

The only way to control rendering via the query is via the show/hide commands.

I'm really not comfortable making behaviours of the plugin require parsing the query, other than explicit instructions in the query...

But hypothetically speaking, even if we decided to make rendering aware of the query, what would count as there being a start filter present?

starts on or before today is obvious. But what if it was part of a complex boolean combination, with the odd NOT thrown in. And what if there was filter by function?

What if users have several different queries open - some with start and some not... They would have to remember the source of the query in order to predict the behaviour of the button (or hover over the button every time to see the tooltip)

If no happens date present, still show Postpone button and edit startDate

Your reference to the docs of start is really helpful.

I do think there is a strong case for adding to the current behaviour so that:

• Show the Postpone even if there is no happens date on the task
• When there is no happens date, make it work on the startDate

Other options - more options on the context menu

I suspect that at some point there will be sub-menus added to the Postpone context menu, allowing control of which date is changed.

But this issue is about something more specific, which is what a single-click on the Postpone button does.

Other options - user settings

I'm resigned to having to add some user settings around Postpone at some point, because of the variety of requested behaviours coming in.

But I'll give it a few months before even considering doing that, to ensure a wide variety of inputs.

So for now, I'm looking for changes to Postpone that are reasonable defaults to use for everybody.

[DanielTMolloy919]

Thanks for that detailed writeup Clare, yes I can definitely see how that gets tricky. My thinking was simply that in the case of the starts on or before today query very specifically, its a pretty strong indicator that the user expects the postpone button to defer start dates. I would think the same would be the case for people using due on or before today and scheduled on or before today. But I completely agree that opens a pandora's box trying to decipher more complicated filters.

I personally would be happy having an explicit command a la 'show/hide' that allows me to set what date the button defers. maybe something like defer start or button defers start. I think this would work much better as a query argument instead of a global setting, because what date the users expect the button to defer differs a lot with the query.

As an example, I could definitely see a use case where users want to see what they could start on today in one query window, and what is due today in another. The user would then most likely want the defer button to defer start dates in the first, and due dates in the second. What are your thoughts on this?

Very excited for the date specific context menus, I think that'll be the final piece of the puzzle, allowing me to easily postpone due dates as well when I do use them. Especially on mobile devices however, being able to postpone start dates with a single click is so much quicker than a long press followed by a dropdown select for many tasks.

[claremacrae]

I personally would be happy having an explicit command a la 'show/hide' that allows me to set what date the button defers. maybe something like defer start or button defers start. I think this would work much better as a query argument instead of a global setting, because what date the users expect the button to defer differs a lot with the query.

That's a really nice idea.

One observation: It would tie the Postpone button to only being shown in Query results. It's currently only shown in Query results, so that's no great limitation currently.

I was preparing to eventually make the Postpone button available on tasks in their markdown files in Reading and Live Preview modes... 🤞

This suggestion would preclude the single-click Postpone option in that situation, as there is no query to control the behaviour. But I can live with that.

[DanielTMolloy919]

Awesome! I've done up a draft of the documentation for this, curious to hear what you think https://github.com/DanielTMolloy919/obsidian-tasks/tree/postpone-button-command

[claremacrae]

Thank you. Seeing the docs written up really helps make the feature clear.

I think it’s missing some of the nuance from your reasoning above, like why you might want to apply it to the start button rather than the other fields? Your link to the explanation of start was really helpful.

It also makes me wonder, if I only had a due date on a task, but set start in the query, I think I’m right that the due date would never be postponed. Is that right?

You had an example of why people might want different defaults in different queries - that’s probably worth mentioning too.

[claremacrae]

Do I read it right that there will only be a button add on undated tasks if you use this instruction?

Also, it will still be important to not show the postpone button if any of the dates on the task is invalid (because the task will be rewritten with the original date text replaced with the words ‘invalid date’.

[claremacrae]

I guess at this stage it’s really only the comments on actual behaviour that matter. The background can Altais be filled in later.

[DanielTMolloy919]

I think it’s missing some of the nuance from your reasoning above, like why you might want to apply it to the start button rather than the other fields? Your link to the explanation of start was really helpful.

Yes so as I was writing, I realised there was two separate changes

• manual overwrite of button behaviour for a given query
• Changing the default behaviour for when there's no dates set

I just wrote up the manual override to start with, since I wasn't sure if you were sold on start dates being the default for no date set. And that had less to do with start dates particularly, so I left out that detail. Happy to add in the documentation for both if you like, although I'm not actually sure the start date being the default would make sense for everyone (thats why I initially kept the issue to start date queries specifically)

It also makes me wonder, if I only had a due date on a task, but set start in the query, I think I’m right that the due date would never be postponed. Is that right?

Yes that would be the behaviour, should I make that more explicit in the documentation?

Do I read it right that there will only be a button add on undated tasks if you use this instruction?

I think this is asking if tasks with a predefined date (and therefore already have a pospone button showing) would get a second pospone button from this command or not. My thinking is no, every task in the query results gets a single button which defers the date set in the command. Let me know if I've misunderstood

Also, it will still be important to not show the postpone button if any of the dates on the task is invalid (because the task will be rewritten with the original date text replaced with the words ‘invalid date’.

For sure, I didn't remove that line in the 'Why is Postpone not shown on a particular task?' section for this reason

[claremacrae]

Thanks - very helpful. I need to think about it, but waned to cature an idea it gave me...

This is the relevant code:

https://github.com/obsidian-tasks-group/obsidian-tasks/blob/e65dd75aa6dd25682dfa44efb24493c7b8c13cd6/src/Scripting/Postponer.ts#L32-L46

And we are talking about changing that behaviour... And providing users with one fixed alternative way to change the logic.

Another idea is to provide this - and allow users to supply the logic they want. We could give examples of common policies in the docs:

postpone by function 'dueDate';
postpone by function 'startDate';
postpone by function 'scheduledDate';
postpone by function if (....) 

You have also persuaded me that the above code should default to returning startDate if the other fields are not presentm simply because of the docs of the start field.

[DanielTMolloy919]

And we are talking about changing that behaviour... And providing users with one fixed alternative way to change the logic.

Yes, and thats the function i've modified to get start dates to always be postponed in my own personal vault. So far it has worked great :)

Another idea is to provide this - and allow users to supply the logic they want. We could give examples of common policies in the docs:

Interesting, I can't even fathom what other logic you would use, but definitely curious if you have an example

You have also persuaded me that the above code should default to returning startDate if the other fields are not presentm simply because of the docs of the start field.

Sweet, I'm happy to add that to the documentation while you're having a think

[claremacrae]

Interesting, I can't even fathom what other logic you would use, but definitely curious if you have an example

The discussion in https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2573 has examples - like wanting to prevent start from advancing to later than due. So conditionals based on differences between start and due may be needed for some people's safety of peace of mind.

[claremacrae]

You have also persuaded me that the above code should default to returning startDate if the other fields are not present, simply because of the docs of the start field.

Sweet, I'm happy to add that to the documentation while you're having a think

I wonder about just doing the 'default to returning startDate' change for now???

The reason I say that is I'm feeling rather overwhelmed with the volume and difficulty of the remaining work on Dependencies.... At the current rate, it will likely be a month or more before the next Tasks release...

As such, I should really focus my time on that - and reviewing, testing and documentation copy-editing any non-trivial PRs often adds up to quite a lot of non-development time...

[DanielTMolloy919]

Yes sure, this isn't particularly urgent for me (so long as you don't refactor getDateFieldToPostpone too much 🙂). Let me know if I can help with dependencies, don't go back to uni for a few weeks so I have time spare

[claremacrae]

I wonder about just doing the 'default to returning startDate' change for now???

I've written that up in https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2651.

We now have the following smaller, specific requests for changes to Postpone and similar:

• https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2648
• https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2649
• https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2650
• https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2651

[claremacrae]

Hi @DanielTMolloy919 If the above were implemented, would this ticket still be relevant/important to you?

[DanielTMolloy919]

Hi @claremacrae, so I think that #2651 gets 80% of the way there. The issue comes with when I have a start date and a due date. #2648 would save some time by not having to open the modal, but I think there's still a fundamental issue of the expected behaviour of the postpone button, which is very important when postponing dozens of tasks at a time.

When I'm filtering so I see a list of tasks that start on or before today, it still feels really unexpected to have the due date postponed if it exists. From reading #2573 it seems like other people with a similar workflow to mine share this experience. For the time being, I've overwritten Postponer.ts to just always postpone start date, because I often forget to check for a due date first.

In the documentation about the postpone feature it makes reference to 'a Task list full of overdue tasks', 'and postponing 'so you can focus on the immediate priorities'. I think given this, the expected behaviour of the postpone button can be thought of as 'edit the date that means that I wont see this task in this query until tomorrow'. You've mentioned the difficulties with intepreting postpone intent from the query commands, so an override command was my next suggestion, but definitely open to another way to handle this.

[claremacrae]

HI @DanielTMolloy919, that really helps. I had wrongly thought that you only used start date, from our conversations when pairing previously....