Look for ways to prevent user modification of `task` objects in custom filters and grouping

[claremacrae]

Please check that this issue hasn't been reported before.

• [X] I searched previous Bug Reports didn't find any similar reports.

Expected Behavior

User error451 on Discord gave feedback that Tasks should disallow users from modifying Task objects via searches.

Current behaviour

They showed some code that did modify Task objects, and suggested a way to prevent that editing - possibly by converting to JSON and back again, perhaps to make a duplicate object.

See this message:

It is unfortunate that option isn't design for changing other task's parameters, so this can cause side effects, the most obvious is that (due to the caching of tasks) if you have another query that lists completed tasks, they will be replaced by link to the daily note too, but these problems do not exist with dataviewjs code i sent there

Steps to reproduce

Not known.

Which Operating Systems are you using?

• [ ] Android
• [ ] iPhone/iPad
• [ ] Linux
• [ ] macOS
• [ ] Windows

Obsidian Version

Not relevant

Tasks Plugin Version

5.0.0

Checks

• [ ] I have tried it with all other plugins disabled and the error still occurs

Possible solution

Possibly make the API use a copy of the data in Task objects.

[aubreyz]

I'm not sure I am following this well. There are only two ways to modify tasks from a query

• Toggling the checkbox
• Via the edit link

The latter can be hidden via query options So the rest of the answer seems to be along the lines of another recent feature request (to disable the checkbox in a particular query)

[claremacrae]

Hi @aubreyz, yes without a reproduction this is a bit cryptic.

Tasks stores a central array of Task objects. When a file is edited, the plugin does some checks to see if any task lines have changed, or things like line numbers have changed, and if so, the relevant Task objects in the array get overwritten with new Task objects.

error451 showed a way on Discord to use filter by function or group by function code to modify some of those Task objects, which are in-memory copies of data from task lines...

Those edits would 'stick' until the user made certain types of edits in the edited Task objects' Markdown files.

• At the best, it would prevent users from editing and updating their tasks
• At the worst, it might cause edits to save incorrect data back to Markdown files.

In some sense, I'm actually not that bothered about, because it's using an undocumented feature of the code, of which there are many. I take responsibility for the published features very seriously. But as free software, tracking all the undocumented ways that people can use is not feasible.

However, once more advanced users start publishing ways of using undocumented features like this, without a suitable warning and an explanation of the risks it causes, it gets more complicated.

And the reason there is no reproduction of the code here in this issue is that I grumbled about it being published, and error451 quite reasonably removed it. So by the time I'd logged this here, the example had gone...

[pcause]

I think this is an opportunity for a feature. I want a way to do scripting on tasks that are returned from a tasks query. If you added a call to take the changes to in memory copies and apply to the master copy we'd have that. For example, if I want to create custom status flows based on current status and perhaps tags or words in the description, this would allow that. Someone could build their own tasks/sub tasks handling. Turing this "possible bug" into a feature with a new call to move the changes to the master tasks. I suspect the code would be close to the code for what happens after the tasks modal is closed.

[claremacrae]

I think this is an opportunity for a feature.

I understand that it looks like this, but it is an opportunity for users to both break their Tasks searches and potentially corrupt the task lines in their vaults.

The fact that you are tempted to see this as valuable significantly raises the priority of this ticket in my mind!

I want a way to do scripting on tasks that are returned from a tasks query.

Me too...

If you added a call to take the changes to in memory copies and apply to the master copy we'd have that.

Yes, but the important thing to know here is that the Task class in the Tasks plugin is designed as immutable data - so an edit creates a new Task object. Changing the data inside a Task object by bypassing the immutability would fundamentally break the behaviour of the plugin, by invalidating assumptions in other areas of the plugin.

As luck would have it, I recently took the very first baby steps along the long journey of adding a robust and supported mechanism for what you describe... Please see the Motivation and Context section of this PR:

• https://github.com/obsidian-tasks-group/obsidian-tasks/pull/2495

[claremacrae]

The fact that you are tempted to see this as valuable significantly raises the priority of this ticket in my mind!

I feel I should clarify this, @pcause, in case it caused offence...

I was thinking that you are one of the main people who is kind enough to offer feedback on Tasks. So as you thought of this issue as a potential benefit, there are likely multiple others thinking the same and perhaps even trying it out, unaware of the risks.