Parent tasks can corrupt themselves when a subtask's title starts with a tag, preventing opening the parent task (traceback where n.firstChild is None, so has no attribute 'nodeValue') about gtg HOT 10 CLOSED

I think I found a way to trigger this:
Create (or modify) a task that has its contents like this:

This is a title
@foo @bar

And modify it like this to create a subtask with a different tag:

This is a title
@foo @bar
- @baz this is the title of some subtask

Upon pressing Enter, the subtask is created.
Then, if you close that stuff, exit the "Work view" mode and try to open the parent task, you won't be able to. You can only open the child, because of the traceback that occurs with the parent. In the parent task, you end up with:

<task id="147eae69-7d52-4bbe-bf0f-1ef9ad1f8ea0" status="Active" tags="@foo,@bar,@baz" uuid="dda00093-816a-496d-93d0-3d57a2bd341a">
        <title>This is a title</title>
        <duedate>2014-09-19</duedate>
        <modified>2014-09-14T14:22:45</modified>
        <subtask>b14b157f-6142-48f3-9840-5b3d30a66fa5</subtask>
        <content>&lt;tag&gt;@foo&lt;/tag&gt;, 
&lt;tag&gt;@bar&lt;/tag&gt;

 &lt;tag/&gt; this is the title of some subtask
</content>
        <task-remote-ids/>
    </task>

from gtg.

I hit the same exact traceback again today with the 0.3.1 version (haven't tested if the git version is still affected, but presumably with the instructions above it should be possible to test it) and wanted to add another way I triggered this:

1. I created a task titled "lorsque tous les comptes payés, email les états à Mich" tagged @finance
2. In there, I created a subtask "Request tous mes états de comptes"
3. While keeping the parent task open, I opened the subtask, changed its @finance tag to @accounting, and edited the title to prefix it with @phone, so "@phone Bob to request tous mes états de comptes".
4. Closed the child task, notice the parent task's subtask line didn't get immediately updated
5. Close the parent task, reopen it (sometimes it might need restarting the application, but it will keep happening)

from gtg.

This happens in master too. Did some digging and it seems like it's getting confused the second time you open it. It parses the tag in the subtask as a tag of the main task and writes some incorrect xml.

	<task id="4d722e50-bea7-419e-8f7a-53b3687465c7" status="Active" tags="@something,@phone" uuid="e77a4c38-f7bc-4524-8bbc-4820c4c80b42">
		<title>Test</title>
		<addeddate>2020-03-21T21:29:30</addeddate>
		<modified>2020-03-21T21:30:01</modified>
		<subtask>d90eab25-a0a5-4309-aa4b-9c1f13a3b212</subtask>
		<content>&lt;tag&gt;@something&lt;/tag&gt;

 &lt;tag/&gt; subtest

</content>
		<task-remote-ids/>
	</task>

from gtg.

I can confirm this bug happens when adding a tag in a subtask. From the point of view of the parser, it's a gtkTextTag inside a gtkTextTag. @ploum It doesn't look like this is supported at all in the serializer?

from gtg.

It should work (and it has worked) but it's a bug that comes back from time to time. The serializer is very fragile because it serializes to XML and sometimes serializes twice so it becomes XML serialized in XML.

To be honest, I think that one big big work at some point would be to replace XML backend by sqlite. We choose XML so we could manually tweak our files and save them easily when we started developing. In the long term, it was a bad idea.

from gtg.

Funny some time ago I was looking at the filtering and search code thinking "this looks like SQL queries in python" :)

We should evaluate that change in the future for sure. Maybe we could improve performance doing all the filtering and sorting in SQL.

from gtg.

As a straightforward solution has not been found for this yet, and since the issue is not a regression (it was already present in 0.3.x at least), deferring this to the 0.5 release milestone (tentatively)...

from gtg.

I ran into this again today with the git version. As an additional data point, here's the similar-looking traceback:

  File "GTG/gtk/browser/main_window.py", line 940, in on_edit_active_task
    self.app.open_task(tid)
  File "GTG/gtk/application.py", line 413, in open_task
    editor = TaskEditor(requester=self.req, app=self, task=task,
  File "GTG/gtk/editor/editor.py", line 190, in __init__
    self.textview.insert(f"{texte}")
  File "GTG/gtk/editor/taskview.py", line 279, in insert
    self.unserializer.unserialize(
  File "GTG/gtk/editor/serialize.py", line 173, in unserialize
    success = self.parsexml(content_buf, ite, element.firstChild)
  File "GTG/gtk/editor/serialize.py", line 222, in parsexml
    text = n.firstChild.nodeValue
AttributeError: 'NoneType' object has no attribute 'nodeValue'

...and here's how I did it: I had a task titled "Visit Iceland", with two levels of parents above, and 6 subtasks (some two-levels deep). At some point, while the rest of the task windows were closed, I edited one subtask to have it start with a tag in the title, "@phone Björk". Later, when I went back to the "Visit Iceland" task and hit Enter below the title to add a description to the task, "Forget about Norway!", the corruption then occurred when I closed/saved that task. Afterwards, GTG refuses to open the task editor for that task, producing the traceback above.

Inspecting the xml flie and comparing it to the previous backup, I see the same suspicious <tag/> present at the beginning of the line of the incriminating subtask, instead of <subtask>the_task_id, as we can see in this visual diff (broken version on the left, previous working version on the right):

If I manually repair, as a workaround, the contents of the content tag for the task that refuses to open, like so:

		<content>&lt;tag&gt;@travels&lt;/tag&gt;

Forget about Norway!
→   &lt;subtask&gt;47@1&lt;/subtask&gt;
→   &lt;subtask&gt;48@1&lt;/subtask&gt;
→   &lt;subtask&gt;50@1&lt;/subtask&gt;
→   &lt;subtask&gt;ed18a2ba-4490-4e6e-bb5b-c2c6f962d25c&lt;/subtask&gt;</content>

...and then start GTG, then the task happily opens without causing a traceback when you open it:

However, as soon as you close that task editor window, it will corrupt itself again in the same fashion.

The only way to not have the problem is to not have the tag starting the title of that first subtask. So instead of that other task looking like this:

	<task id="47@1" status="Active" uuid="fe0dac3f-4607-441e-8fb9-6285401d8cbb" tags="@travels,@friends,@phone">
		<title>@phone Björk to agree on a meeting</title>

It must now look like this:

	<task id="47@1" status="Active" uuid="fe0dac3f-4607-441e-8fb9-6285401d8cbb" tags="@travels,@friends,@phone">
		<title>phone Björk to agree on a meeting</title>

...which, combined with the repaired parent task like previously, will prevent the corruption from happening in the parent task.

I'm wondering if it has anything to do with the fact that this task was the first in the list right after the description...

Anyway, with these detailed instructions, I think that someone smarter than me could probably find the way to solve this bug :)

from gtg.

This is already fixed in the new taskview widget since we go on a loop line-by-line and don't add additional tags when a line has a subtask. Therefore there are no nested text tags (except for the checkbox maybe). So this bug can't happen anymore

from gtg.

Oh great I didn't know you already had a fix pending! Then that'll be something to close when that branch lands. Also if you branch has automated tests, this is definitely something that would benefit from having one, because it took years to troubleshoot and narrow down what was causing this nonsense :)

from gtg.