wrong count when batch altering tasks

[kiil]

To report a bug...

• What command(s) did you run?

task test delete

• What did you expect to happen?

correct count of tasks that would be altered

• What actually happened?

"This command will alter 70 tasks"

but in fact only

"Deleted 4 tasks."

others:

Task 3ce8893c 'test server' is not deletable. Task 3bad08e4 'test server 2' is not deletable. Task 767b9e97 'test fra UI 2' is not deletable. ...

• Paste the output of the task diag command.

task 2.6.1 Platform: Darwin

Compiler Version: Apple LLVM 13.0.0 (clang-1300.0.29.3) Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64 Compliance: C++17

Build Features CMake: 3.21.3 libuuid: libuuid + uuid_unparse_lower libgnutls: 3.6.16 Build type: Release

Configuration File: /Users/kiil/.taskrc (found), 2707 bytes, mode 100644 Data: /Users/kiil/GD/MIS/.task (found), dir, mode 40755 Locking: Enabled GC: Enabled rc.editor: nvim

Hooks System: Enabled Location: /Users/lennartkiil/GD/MIS/.task/hooks Active: on-modify.timewarrior (executable) Inactive:

Tests Terminal: 230x63 Dups: Scanned 597 tasks for duplicate UUIDs: No duplicates found

[smemsh]

can you paste the task export for one of the tasks? eg

task 3ce8893c export | jq .

the code for CmdDelete::exceute() says is not deletable only if the test

if (task.getStatus () != Task::deleted)

fails

[kiil]

Thank you

 {
    "id": 0,
    "description": "test udråbstegn i tags +!t",
    "end": "20220511T085457Z",
    "entry": "20220511T085255Z",
    "modified": "20220511T085501Z",
    "status": "deleted",
    "uuid": "08e854d2-2cc5-41fc-adde-0c2a4b7c99f2",
    "tags": [
      "test"
    ],
    "urgency": 0.821918
  }

[kiil]

Note: It is the count given beforehand that is wrong, because it also counts deleted tasks - even though these are not altered by the delete command, since they are already deleted.

[smemsh]

The count is wrong yes, but at least the end behavior seems correct. Arguably, it shouldn't even attempt/note that the tasks are not deletable (even with high verbosity) since that's rather obvious if they are already deleted.

This might not have come up often because mostly people run a garbage collection after deletions or have automatic garbage collection enabled.

[kiil]

Agreed. But I do not purge my deleted tasks because I use taskwarrior also as a "reference system".

This is certainly not a huge issue :)

[smemsh]

I do not purge my deleted tasks because I use taskwarrior also as a "reference system".

wouldn't those be instead completed tasks you would keep for reference? at least in my workflow, deleted tasks are only those that were entered erroneously and never should have existed, or otherwise invalid.

This is certainly not a huge issue :)

I do agree that it's a bug, at the very least the count, but also I'd argue that those "cannot be deleted" should never surface as they're tautological warnings.

[kiil]

wouldn't those be instead completed tasks you would keep for reference? at least in my workflow, deleted tasks are only those that were entered erroneously and never should have existed, or otherwise invalid.

That would certainly render this specific issue invisible - vis a vis your second point :)

So I'll probably adjust my workflow.