[BUG] Order subtasks by completed ignores ascending/descening

[jojoob]

Describe the bug
Order subtasks by completed alsways shows completed subtasks at the top of the list whether ascending or descending is selected.
And additionally, a little bit of a feature request: It would also be nice to have completed items at the buttom regardless of the otherwise selected sorting. Maybe similar to "order by", "then order by".

To Reproduce
Steps to reproduce the behavior:

1. Create a task with some subtasks
2. mark some of the subtasks as completed
3. go to the task list and "sort subtasks by... completed"
4. see the completed subtasks listed on top
5. switch ascending/descending sorting and see the completed subtasks listed on top still

Expected behavior
Ascending/descending sorting should have an impact on whether completed subtasks are displayed at the top or bottom of the list.

Device and version:

• Device: Samsung galaxy s10e
• Android version 12
• jtx Board version: 2.05.04.gplay (205040010)
• Downloaded from: Google Play

[patrickunterwegs]

Thanks @jojoob !
I'm currently on vacation, but I'll check this soon!

[patrickunterwegs]

Hey @jojoob !

I had a look at this, let's have a short discussion:

Basically the search result makes first two partitions: first entries with a completed date, then without. This makes sure that the completed entries always stay on top when you order by completed date. There was a discussion a longer time ago, I think it still makes sense to keep it like that.
The first partition is then ordered by it's completed date - ascending or descending. This basically works. There's one quirk: the completed date might only have a date set (without time). The logic would order by the date but cannot make a difference between the entries and would show them in the order as they are in the database.

So I think your issue is more about the partitioning here, right?

[jojoob]

This makes sure that the completed entries always stay on top when you order by completed date.
So I think your issue is more about the partitioning here, right?

Yes, that's true. I could reproduce what you explained. Why was the decision made to keep the completed items always on top? I find it a bit counterintuitive when using subtasks e.g. for a shopping list.

[patrickunterwegs]

You mean it's better to have the uncompleted ones always first, then the completed ones ordered by the date ascending or descending?

[jojoob]

Yes, but maybe not always first. But instead in dependence of ascending/descending ordering.
I.e.: Ascending: first all completed tasks in ascending order (oldest completed date first) then all tasks without a completed date.
Descending: first all uncompleted tasks then all completed tasks in descending order (newest completed date first).
... Or the other way around. I could argue for both ways but I like the one described above more.

[patrickunterwegs]

Ok, so let's try this. But I'd say
Ascending: first without completed date, then from the oldest to the newest.
Descending: completed date from the latest to the oldest, then entries without completed date.
That would also be the logic how the database would return the entries by default.

[foss-]

Hope I am not misunderstanding the discussion. From my understanding, the idea to sort due date by Ascending is to sort from "what's next todo" to what's on the agenda at a later point in time".

Considering that, subtasks with due take have higher urgency than subtasks without due take. Thus I'd argue, subtasks with due date should be listed first when sorting by Ascending. Or am I missing something in this argument?

[jojoob]

Hi @foss-, the discussion was about the completion date not due date. ;) but beside that I completely agree with you. And you have brought my attention to the fact that the partion thing is implemented for all sortable date fields. Meaning that tasks with an empty value for the selected sort by date field are always listed at the end independent of ascending/descending ordering.

@patrickunterwegs please consider the change for all sortable date fields. ;)

[jojoob]

Closed by mistake... Reopened

[patrickunterwegs]

For the sorting by completed I have removed the partitioning now. I think there it's okay.
Regarding the due date and other sort options, I'd say this partitioning should stay, for the reason as @foss- mentioned. It was also requested to be sorted like that, and for most cases it seems to be the proper way now.

[jojoob]

Thanks a lot @patrickunterwegs!
But why not keep it consistent (ascending from oldest to newest and then tasks without date) independent of the date field selected for sorting?

[patrickunterwegs]

Well, indeed, that would also be an option. Let's try that 👍

[patrickunterwegs]

Thanks a lot @patrickunterwegs! But why not keep it consistent (ascending from oldest to newest and then tasks without date) independent of the date field selected for sorting?

In fact, that's just how it's implemented in the current release version. So eventually there is no change.
So the partitioning would make a first partition with a completed date, the second partition without. The first partition is then ordered by completion either ascending or descending...

[jojoob]

@patrickunterwegs I'm a bit lost with what the status is of this issue. According to github the changes should be in version >5.5. I updated yesterday to 6.6 and nothing changed with subtask sorting.
Or maybe there is still a misunderstanding?

[patrickunterwegs]

Hi @jojoob , actually my understanding was that we came to the conclusion that no change was needed, so I reverted the change. Do you see this differently?

[jojoob]

A picture is worth a thousand words - and multiple screenshots...

Screenshots to illustrate the current and proposed behaviour

I marked the order I propose with red numbers.

Same again in text form

Due ASC

current

1. Do third, uncompleted
2. Do fourth, uncompleted
3. no due
4. Do first, completed second
5. Do second, completed first

my proposal

1. Do first, completed second
2. Do second, completed first
3. Do third, uncompleted
4. Do fourth, uncompleted
5. no due

From earliest to last, all items without a due date always at bottom! The order among items without a due date doesn't matter.

Due DESC

current

1. do fourth, uncompleted
2. do third, uncompleted
3. Do second, completed first
4. Do first, completed second
5. no due

my proposal

1. no due
2. do fourth, uncompleted
3. do third, uncompleted
4. Do second, completed first
5. Do first, completed second

From last to earliest, all items without a due date always at top! The order among items without a due date doesn't matter.

Completed ASC

current, this is already as I would have proposed it!

1. Do second, completed first
2. Do first, completed second
3. Do third, uncompleted
4. Do fourth, uncompleted

From earliest to last, all items without a completed date always at bottom! The order among items without a completed date doesn't matter.

Completed DESC

current
3. Do first, completed second
4. Do second, completed first
2. Do third, uncompleted

1. Do fourth, uncompleted

my proposal

1. Do fourth, uncompleted
2. Do third, uncompleted
3. Do first, completed second
4. Do second, completed first

From last to earliest, all items without a completed date always at top! The order among items without a completed date doesn't matter.

[patrickunterwegs]

A picture is worth a thousand words - and multiple screenshots...

Thanks @jojoob ! I'll have a look this weekend!

[patrickunterwegs]

Hi @jojoob ,

so I made a small change that facilitates any adaptions in this matter, but I'm not sure if I agree with you here.

Basically the current logic is always the same:
You choose a date to order by, the app will first make two partitions - one where the attribute is set, one where it's not set. Within the group where the attribute is set, the order is ascending or descending according to the setting.
Additionally when NOT sorting my completed, the completed ones are put at the bottom of the first partition, as done tasks are not really relevant to be amongst sorted due/started items.

So I think the current logic is still good and comprehensible. I'm afraid if I now change the logic, others will just came up and complain as they might see the current logic as the more intuitive one...

[jojoob]

You choose a date to order by, the app will first make two partitions - one where the attribute is set, one where it's not set.

Putting the partition with items where the attribute is not set always at the end is not what I expect when changing between ascending/descending. And basically this is what my original problem was about: I want an option to sort my items I already have in my shopping trolley (checked/done subtasks) to the bottom. ;D

the completed ones are put at the bottom of the first partition, as done tasks are not really relevant to be amongst sorted due/started items.

This may be true for a few scenarios but puts additional (hidden) logic to a simple sorting function and therefore contradicts the expected behaviour.
Maybe a "Then order subtasks by" would solve this problem?

[jojoob]

Ps: Even with your explanation of the logic the sorting shown in my first and second screenshot (order subtasks by due ascending/descending) does not make any sense to me.

[patrickunterwegs]

I have adapted the sort order for due and completed, I still don't see your proposal as a good approach. I did the following:

Due ASC

• Uncompleted
  -- due older
  -- due newer
  -- no due
• Completed
  -- due older
  -- due newer
  -- no due

Due DESC

• Uncompleted
  -- due newer
  -- due older
  -- no due
• Completed
  -- due newer
  -- due older
  -- no due

Completed ASC

• Uncompleted
• Completed older
• Completed newer

Completed DESC

• Completed newer
• Completed older
• Uncompleted

I will move this to discussions now to leave it open for any other feedback