POSSIBLE BUG: Sort by created is still subordinate to priority [misunderstanding of Created Date]

[Gnossos]

Code

Here is the code:

```tasks

not done
sort by created reverse
short mode

```

Expectations

What I expect: A list of all uncompleted tasks, sorted by the date they were created, with most recent at the top.
What I get: A list of all uncompleted tasks, sorted by priority and then within priority levels, the date they were created in descending order.

Questions:

• Is this a bug?
• If not, where is this behavior documented?
• Is there a workaround (aka "kludge")?

[claremacrae]

Hi @Gnossos,

Thanks for using Tasks.

Is this a bug?

Impossible to say, as there are no task lines supplied for me to test this out.

Here's my standard response in this situation...

There is content in your vault that is not provided as text for me to copy, so for reasons explained in the following post, I am unable to investigate:

https://publish.obsidian.md/tasks/Support+and+Help/Report+a+Bug

If you can provide full text, and full numbered steps for a reproduction, as per the above, I will willingly have a look when I have time.

Thank you.

[Gnossos]

Hi Claremacrae,

Sorry, I'm new here.

I've followed the instructions and created the test page linked below.

Test Page.md

[claremacrae]

Hi @Gnossos,

Perfect - the test page was really useful.

The sort by created instruction sorts tasks according to their created dates - such as ➕ 2021-04-09 in the task lines.

Your tasks do not have the Created Date emoji, so sort by created does not affect the sort order in any way.

I need to update the documentation on sorting as it has been wrong for a long time.

It says the default sort order is urgency - but in fact the following sort instructions are added after any that you add.

sort by urgency
sort by status
sort by duedate
sort by priority
sort by path

So that's what is going on.

You can read more about urgency.

[Gnossos]

Thanks for the explanation. I've tried to make a revised Test Page that takes into account the plugin's option to set a created date on every added task. I originally did this in the vault I'm working on, which always had the created-date option turned on. Then I copied and pasted the revised test text into a page in the sandbox vault. The results are still problematic. See the test page below.

Your note raises these concerns:

1. Aren't urgency scores based in part on priority? If so, then might sorting by urgency and then priority produce strange results? If in fact urgency were a very discrete variable, then sorting by priority within urgency levels might be sensible, even if the sort is overdetermined. But the urgency scores I've seen seem to be more or less continuous as the number of tasks increases. So I'm not sure sorting by priority within urgency is very meaningful.
2. As pointed out on the test page, the Properties page for the Tasks Plugin says one must restart Obsidian for the changes in the plugin's settings to take effect. But as I understand it, if one restarts a sandbox vault, all the plugins disappear. So, logically, it's impossible to test Plugin settings, such as including created dates on all tasks, in a sandbox vault. Catch-22!
3. So, I did not restart the sandbox vault. But in both the vault I'm using for actual development and in the sandbox, behavior of the created property is erratic, to say the least.

Your thoughts?

Test Page.md

[Gnossos]

Also, as I understand what you're saying. Here's how sort behavior should work.

Add the following code:
`

´´´tasks

not done
sort by created reverse
short mode

´´´
`
This should result in the following:

`

created date in descending order
urgency in ascending order
status in ascending order
duedate in ascending order
priority in ascending order
path in ascending order
`
Some comments:

1. What if the user wants to control some of the subsequent properties? For example, urgency in ascending order?
2. Where a property is likely to have lower-order values that affect the final sorting, such values should be included in the property. I'm thinking here of creation date. It's likely that multiple tasks are created on a given date, yet sorting by creation date won't sequence them properly because it's ignoring when tasks are created. I.e., time should be included in creation dates.
3. How about a way to tell Tasks to disregard the properties used in the final sort?

[claremacrae]

Hi, there are so many interrelated discussions going on here that I'm struggling to see how to separate all the points and reply in a reasonable amount of time.

I will try to clarify a few things...

Please read my final point before replying. Thank you.

Sandbox vault

As pointed out on the test page, the Properties page for the Tasks Plugin says one must restart Obsidian for the changes in the plugin's settings to take effect. But as I understand it, if one restarts a sandbox vault, all the plugins disappear. So, logically, it's impossible to test Plugin settings, such as including created dates on all tasks, in a sandbox vault. Catch-22!

Yes, that is true. The end result is:

1. don't use a global filter in the sandbox vault (but note that this affects the code that works out whether or not to auto-add a Created date.)
2. apply all your task settings before creating any tasks, and it will be OK
3. It is also OK to create an empty vault to experiment with. It's not critical to use the sandbox.

Invalid task lines in 2nd sample file

behavior of the created property is erratic, to say the least.

Please read this section of the documentation: What do I need to know about the order of items in a task?

So, in your new test file:

3. [ ] #todo A low priority task 🔽 ➕ 2023-10-03 *(On this one I manually inserted a creation date by bringing up the task dialog window)*

The comment after the creation date meant that Tasks no longer parses either the priority or the creation date.

Not all tasks having creation dates, after you enabled the setting.

See Adding Created date to tasks.

If you are using the Modal to create a task, and it does not add the Created date...

• then the original markdown line was already interpreted by Tasks as a task ...
• so Tasks view it as "previously created" - and no Created date will be added by the modal

Please read the changes in Tasks 4.7.1 - for how using a global filter affects this behaviour.

(Specifically, bug #2112 is now fixed since that release...)

Testing your emoji

A quick way to confirm that the emoji are correctly interpreted in your tasks is to pick a field and group by it.

For example, add this line to your query:

group by created

And see if any any of the tasks in the No created date section have a ➕, it's telling you that something else in your task was preventing the field from being read.

Another way is to search for:

description includes ➕

If the ➕ was read correctly, it won't be present in the final description. So that's another way to find your problem task lines.

Controlling the sort order

It's not possible to remove the 5 default sort orders. They are added at the end of any that you supply.

The way multiple sort lines works:

1. The first sort instruction is applied to all tasks matching the query
2. The second sort instruction only affects the order of tasks that had the same sort order in the first sort instruction

So if you don't like the default sort order, add more sort instructions in your own query.

The available sort orders are listed in Sorting.

How about a way to tell Tasks to disregard the properties used in the final sort?

That isn't going to be possible, as the order that Obsidian informs Tasks to read the files in your vault is not deterministic, and so not having a default sort order will effectively make the task order random in the search results.

---

What next?

I am happy to offer users support on the Tasks plugin, but large and rambling issues like this one take up hours of time.

If there are any more questions here from this point on, please:

1. pick one of the remaining topics
2. give me a small example - 1 or 2 tasks
3. ask one question about it..

Once that is resolved, if there are any more questions, pick the next most confusing one...

[claremacrae]

Also I just noticed that this is in the Development section, which is for developers of the plugin: "Discussions about programming for the Tasks plugin".

So I'm moving it to Q&A.

[claremacrae]

Once that is resolved, if there are any more questions, pick the next most confusing one...

5 days on, I'm assuming that no news is good news, and all is fine.... 😄