Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly escape task title #733

Closed
mrossinek opened this issue May 25, 2020 · 5 comments
Closed

Properly escape task title #733

mrossinek opened this issue May 25, 2020 · 5 comments
Labels

Comments

@mrossinek
Copy link

Description

I am a little bit unsure on how to report this issue since it is a very specific problem that is unlikely to pop up for anyone else.

I am having problems with this specific issue: GothenburgBitFactory/taskwarrior#2193

As you can see, it includes several keywords which taskwarrior reacts to and I thus observe the following error in my log every time bugwarrior-pull is run:

INFO:bugwarrior.db:Adding task depends filter does not work with IDs [#2193 issue]
ERROR:bugwarrior.db:Unable to add task: b'Configuration override rc.json.array:TRUE\nConfiguration override rc.verbose:new-uuid\nConfiguration override rc.confirmation:no\nConfiguration override rc.dependency.confirmation:no\nConfiguration override rc.uda.gitlabtitle.type:string\nConfiguration override rc.uda.gitlabtitle.label:"Gitlab Title"\nConfiguration override rc.uda.gitlabdescription.type:string\nConfiguration override rc.uda.gitlabdescription.label:"Gitlab Description"\nConfiguration override rc.uda.gitlabcreatedon.type:date\nConfiguration override rc.uda.gitlabcreatedon.label:"Gitlab Created"\nConfiguration override rc.uda.gitlabupdatedat.type:date\nConfiguration override rc.uda.gitlabupdatedat.label:"Gitlab Updated"\nConfiguration override rc.uda.gitlabduedate.type:date\nConfiguration override rc.uda.gitlabduedate.label:"Gitlab Due Date"\nConfiguration override rc.uda.gitlabmilestone.type:string\nConfiguration override rc.uda.gitlabmilestone.label:"Gitlab Milestone"\nConfiguration override rc.uda.gitlaburl.type:string\nConfiguration override rc.uda.gitlaburl.label:"Gitlab URL"\nConfiguration override rc.uda.gitlabrepo.type:string\nConfiguration override rc.uda.gitlabrepo.label:"Gitlab Repo Slug"\nConfiguration override rc.uda.gitlabtype.type:string\nConfiguration override rc.uda.gitlabtype.label:"Gitlab Type"\nConfiguration override rc.uda.gitlabnumber.type:string\nConfiguration override rc.uda.gitlabnumber.label:"Gitlab Issue/MR #"\nConfiguration override rc.uda.gitlabstate.type:string\nConfiguration override rc.uda.gitlabstate.label:"Gitlab Issue/MR State"\nConfiguration override rc.uda.gitlabupvotes.type:numeric\nConfiguration override rc.uda.gitlabupvotes.label:"Gitlab Upvotes"\nConfiguration override rc.uda.gitlabdownvotes.type:numeric\nConfiguration override rc.uda.gitlabdownvotes.label:"Gitlab Downvotes"\nConfiguration override rc.uda.gitlabwip.type:numeric\nConfiguration override rc.uda.gitlabwip.label:"Gitlab MR Work-In-Progress Flag"\nConfiguration override rc.uda.gitlabauthor.type:string\nConfiguration override rc.uda.gitlabauthor.label:"Gitlab Author"\nConfiguration override rc.uda.gitlabassignee.type:string\nConfiguration override rc.uda.gitlabassignee.label:"Gitlab Assignee"\nConfiguration override rc.uda.gitlabnamespace.type:string\nConfiguration override rc.uda.gitlabnamespace.label:"Gitlab Namespace"\nConfiguration override rc.uda.gitlabweight.type:numeric\nConfiguration override rc.uda.gitlabweight.label:"Gitlab Weight"\nConfiguration override rc.uda.githubtitle.type:string\nConfiguration override rc.uda.githubtitle.label:"Github Title"\nConfiguration override rc.uda.githubbody.type:string\nConfiguration override rc.uda.githubbody.label:"Github Body"\nConfiguration override rc.uda.githubcreatedon.type:date\nConfiguration override rc.uda.githubcreatedon.label:"Github Created"\nConfiguration override rc.uda.githubupdatedat.type:date\nConfiguration override rc.uda.githubupdatedat.label:"Github Updated"\nConfiguration override rc.uda.githubclosedon.type:date\nConfiguration override rc.uda.githubclosedon.label:"GitHub Closed"\nConfiguration override rc.uda.githubmilestone.type:string\nConfiguration override rc.uda.githubmilestone.label:"Github Milestone"\nConfiguration override rc.uda.githubrepo.type:string\nConfiguration override rc.uda.githubrepo.label:"Github Repo Slug"\nConfiguration override rc.uda.githuburl.type:string\nConfiguration override rc.uda.githuburl.label:"Github URL"\nConfiguration override rc.uda.githubtype.type:string\nConfiguration override rc.uda.githubtype.label:"Github Type"\nConfiguration override rc.uda.githubnumber.type:numeric\nConfiguration override rc.uda.githubnumber.label:"Github Issue/PR #"\nConfiguration override rc.uda.githubuser.type:string\nConfiguration override rc.uda.githubuser.label:"Github User"\nConfiguration override rc.uda.githubnamespace.type:string\nConfiguration override rc.uda.githubnamespace.label:"Github Namespace"\nConfiguration override rc.uda.githubstate.type:string\nConfiguration override rc.uda.githubstate.label:"GitHub State"\nThe expression could not be evaluated.'
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/bugwarrior/db.py", line 422, in synchronize
    new_task = tw.task_add(**issue)
  File "/usr/lib/python3.8/site-packages/taskw/warrior.py", line 683, in task_add
    stdout, stderr = self._execute('add', *args)
  File "/usr/lib/python3.8/site-packages/taskw/warrior.py", line 476, in _execute
    raise TaskwarriorError(command, stderr, stdout, proc.returncode)
taskw.exceptions.TaskwarriorError: <unprintable TaskwarriorError object>

I get a notification for the new task every time but it is never properly created due to the above error.

I believe the title of the task is not properly escaped causing this issue. I am unsure whether this is a problem on bugwarrior's side or whether taskwarrior is actually incapable of handling such a scenario correctly.

If this is an "unfixable" problem I would be glad to have either of the following options:

  1. postpone the notification until successful task creation
  2. a configuration option to exclude tasks from being created based on (e.g.) a regex to match against the title (this is quite manual though that would be fine for me in a case like this)

If you need more information, please let me know. I am happy to provide. Thanks for the awesome work!

System Information

  • Arch Linux
  • kernel 5.6.13-arch1-1
  • bugwarrior version: 1.7.0-2 (installed from the AUR)
  • taskwarrior version: 2.5.1 (installed with pacman: 2.5.1-2)
  • Python version: 3.8.3
@ryneeverett
Copy link
Collaborator

Somewhat related: ralphbean/taskw#110. I'm fairly sure this is going to end up being a taskw bug.

ryneeverett added a commit to ryneeverett/taskw that referenced this issue Jun 6, 2020
Similarly to ralphbean#134, passing description via description:{description}
doesn't appear to be documented and can lead to problems.

See GothenburgBitFactory/bugwarrior#733 and consider the following scenario:

$ task --version
2.5.1
$ task add description:"depends filter does not work with ID"
The expression could not be evaluated.
$ task add "depends filter does not work with ID"
Created task 1.

I've tried variations of the previous with various quoting and shells
and have gotten the same result.
ryneeverett added a commit to ryneeverett/taskw that referenced this issue Jun 6, 2020
Similarly to ralphbean#134, passing description via description:{description}
doesn't appear to be documented and can lead to problems.

See GothenburgBitFactory/bugwarrior#733 and consider the following scenario:

```sh
$ task --version
2.5.1
$ task add description:"depends filter does not work with ID"
The expression could not be evaluated.
$ task add "depends filter does not work with ID"
Created task 1.
```

I've tried variations of the previous with various quoting and shells
and have gotten the same result.
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this issue Jun 6, 2020
See GothenburgBitFactory#733. I don't foresee
this being fixable from bugwarrior but could be worked around in
taskwarrior.

I confirmed that this does pass with ralphbean/taskw#135.
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this issue Jun 6, 2020
See GothenburgBitFactory#733. I don't foresee
this being fixable from bugwarrior but could be worked around in
taskw.

I confirmed that this does pass with ralphbean/taskw#135.
@ryneeverett
Copy link
Collaborator

See ralphbean/taskw#135 and #737.

@khaeru
Copy link

khaeru commented Jul 13, 2020

I also ran into The expression could not be evaluated.

The culprit was a GitHub milestone with the literal name "end June 2020", which led to bugwarrior, via taskw, trying to subprocess a command with b'githubmilestone:"end June 2020"' as one of the tokens/arguments. When I change the quoted text to another value (b'githubmilestone:"foo bar"'), the error does not occur.

Note that, unlike the description, this can't be resolved by giving githubmilestone positionally.

The mitigation is to not use the word "end" at the start of milestone names; or, more generally, probably not any Taskwarrior built-in attribute name (i.e. description, status, project, priority, due, recur, until, limit, wait, entry, end, start, scheduled, modified, depends) at the start of any value that gets assigned to a Bugwarrior string UDA. For instance, I tried throwing in b'githubbody:"recur foo"'; this triggered the same error.

As for a fix, no clue from me.

@wookietreiber
Copy link
Collaborator

There is also id. The short name of my company is iDiv and I often write it without caps. Hence, I've been replacing id with myd so it becomes mydiv for quite a while now, see here. Not pretty but it works for me ;)

ryneeverett added a commit to ryneeverett/taskw that referenced this issue Dec 7, 2020
Similarly to ralphbean#134, passing description via description:{description}
doesn't appear to be documented and can lead to problems.

See GothenburgBitFactory/bugwarrior#733 and consider the following scenario:

```sh
$ task --version
2.5.1
$ task add description:"depends filter does not work with ID"
The expression could not be evaluated.
$ task add "depends filter does not work with ID"
Created task 1.
```

I've tried variations of the previous with various quoting and shells
and have gotten the same result.
ryneeverett added a commit to ryneeverett/taskw that referenced this issue Dec 8, 2020
Similarly to ralphbean#134, passing description via description:{description}
doesn't appear to be documented and can lead to problems.

See GothenburgBitFactory/bugwarrior#733 and consider the following scenario:

```sh
$ task --version
2.5.1
$ task add description:"depends filter does not work with ID"
The expression could not be evaluated.
$ task add "depends filter does not work with ID"
Created task 1.
```

I've tried variations of the previous with various quoting and shells
and have gotten the same result.
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this issue Apr 27, 2022
See GothenburgBitFactory#733. I don't foresee
this being fixable from bugwarrior but could be worked around in
taskw.

I confirmed that this does pass with ralphbean/taskw#135.
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this issue Apr 28, 2022
See GothenburgBitFactory#733. I don't foresee
this being fixable from bugwarrior but could be worked around in
taskw.

I confirmed that this does pass with ralphbean/taskw#135.
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this issue Apr 28, 2022
See GothenburgBitFactory#733. I don't foresee
this being fixable from bugwarrior but could be worked around in
taskw.

I confirmed that this does pass with ralphbean/taskw#135.
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this issue Apr 28, 2022
See GothenburgBitFactory#733. I don't foresee
this being fixable from bugwarrior but could be worked around in
taskw.

I confirmed that this does pass with ralphbean/taskw#135.

I've also confirmed that it passes with now that I've upgraded to
taskwarrior-2.6.1. It seems that everyone, including myself, who
reproduced this issue in the past was using taskwarrior-2.5.1.
@ryneeverett
Copy link
Collaborator

#737 now passes with taskwarrior-2.6.1. I haven't tried any other versions but it looks like we were all using taskwarrior-2.5.1 before.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants