-
Notifications
You must be signed in to change notification settings - Fork 209
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
Comments
Somewhat related: ralphbean/taskw#110. I'm fairly sure this is going to end up being a taskw bug. |
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.
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.
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.
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.
See ralphbean/taskw#135 and #737. |
I also ran into 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 Note that, unlike the description, this can't be resolved by giving 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 As for a fix, no clue from me. |
There is also |
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.
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.
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.
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.
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.
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.
#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. |
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: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:
If you need more information, please let me know. I am happy to provide. Thanks for the awesome work!
System Information
5.6.13-arch1-1
1.7.0-2
(installed from the AUR)2.5.1
(installed with pacman:2.5.1-2
)3.8.3
The text was updated successfully, but these errors were encountered: