JIRA extra_fields override description_template
#1075
Comments
Very odd. Since you have My hunch is that the underlying cause is a configuration parsing error. Could you run |
|
Certainly! Turns out it was a bit of a process, so I'll include that as well in case it's helpful for bugwarrior in general. I can't quite figure out how to make the configuration parser happy to run that last 1. (FYI bugwarrior was installed yesterday by pulling the latest 2. Seems like I was missing ini2toml, tomlkit and configupdater 3. Run 4. Run 5. Add service prefixes & re-run And here is where I'm stuck - I can't figure out how to make it happy. I double-checked the TOML docs and even asked ChatGPT, and the syntax seems correct. I also tried a bunch of permutations for the quotes in |
|
Sorry for the additional process, I had forgotten that ini2toml had dependencies which weren't included by default, but at least that part was self-explanatory. I'm assuming that between steps 3 and 4 you replaced the contents of your bugwarriorrc file with the output of You either need to revert your configuration file to what you had before copying in the ini2toml output, or rename it Unfortunately the ini2toml output doesn't give me any clues as to the original bug here, but it mostly rules out configuration parsing as the underlying problem. |
Correct! And as you expected, once I set up the toml config correctly the output was the same - |
|
We don't have a great way to test a configuration from end to end, but I tried to do so in two passes:
configuration file to parsed configuration
configuration file[general]
targets = ["eq_jira"]
inline_links = true
annotation_comments = false
replace_tags = true
static_tags = ["mgmt", "tl", "ic"]
static_fields = ["priority", "project"]
[eq_jira]
service = "jira"
base_uri = "https://example.com"
username = "<redacted>"
password = "<redacted>"
import_labels_as_tags = false
import_sprints_as_tags = false
query = "<redacted>"
extra_fields = "test_field:customfield_10019"
add_tags = ["{{test_field}}"]
description_template = "{{jiraid}}"
project_template = ""
default_priority = ""
log(Pdb) pp dict(self.config)
{'PAT': '',
'add_tags': ['{{test_field}}'],
'also_unassigned': False,
'annotations_template': None,
'base_uri': AnyUrl('https://example.com', scheme='https', host='example.com', tld='com', host_type='domain'),
'body_length': 9223372036854775807,
'default_priority': '',
'depends_template': None,
'description_template': '{{jiraid}}',
'due_template': None,
'end_template': None,
'entry_template': None,
'extra_fields': [JiraExtraField(label='test_field',
keys=['customfield_10019'])],
'id_template': None,
'imask_template': None,
'import_labels_as_tags': False,
'import_sprints_as_tags': False,
'label_template': '{{label}}',
'mask_template': None,
'modified_template': None,
'only_if_assigned': '',
'parent_template': None,
'password': '<redacted>',
'priority_template': None,
'project_template': '',
'query': '<redacted>',
'recur_template': None,
'scheduled_template': None,
'service': 'jira',
'start_template': None,
'status_template': None,
'tags_template': None,
'target': 'eq_jira',
'templates': {'description': '{{jiraid}}', 'project': ''},
'until_template': None,
'urgency_template': None,
'use_cookies': False,
'username': '<redacted>',
'uuid_template': None,
'verify_ssl': True,
'version': 5,
'wait_template': None}parsed configuration to the record inserted into taskwarrior
insertion of record into taskwarriorMy tentative conclusion is that bugwarrior is trying to insert the correct data into taskwarrior and that is where the problem is occurring. Bugwarrior currently uses taskw to do this, which ultimately uses the command line. This generally works really well but some characters aren't always properly escaped and the result is often that taskwarrior misinterprets the arguments. In your case, it appears that I kind of suspect the pipe or colon in your test_field are causing the problem -- perhaps at the point in the shell command where it is inserted as a tag. You could get some confirmation of this possibility by removing the |
|
Thank you for the detailed follow-up! Here's my own :) Pipe symbol as a potential root causeI got really excited when you mentioned this! But then I remembered the original fields I was using didn't have pipes either :( I ran a test using the issue type (Epic/Bug/Story/Task etc.) to make sure and indeed, same result
|
Great! I think that confirms that we're looking in the right direction.
Unfortunately there isn't a great way, no. You could do |
|
Hello again! I took some time over the last couple of days to set up a debugger and follow the data. TLDR I don't think this is a bugwarrior issue, as you initially suspected. In my understanding bugwarrior is behaving correctly, i.e. at no point is it overriding The problem appears when the list of changes is created here:
It simply seems like
The only question I have is whether the non-standard argument that appear in the command being executed are supposed to be part of the command. Given the involvement of Ok, this is entirely outside of bugwarrior but just to provide closure: I don't know C++ very well, but if I follow the code correctly this seems like a case of "reasonable approach to unknown arguments causing an unintended consequence in my specific case" in taskwarrior.
@ryneeverett given that I was ultimately trying to do the same as #826, is there some UDA configuration darck magick I can perform to prevent my custom field from being regarded as an "unknown" one? If not, I can pick up the mantle of #826, at this point I'm way too invested to give up 😉 |
|
Hahaha well, turns out it was very simple - just define a UDA for the specific custom field I want to integrate. In And in And now it works like a charm :D @ryneeverett I think the lesson here is that I should update this section of the docs to clarify a bit. Does that seem like an ok solution? |
Yes, sounds good! It would also be nice if we could add a validator to the |
Hello!
I just started using taskwarrior & bugwarrior and they're really neat. I'd like to use the JIRA integration to pull the assignee's email and assign it as a tag, but I'm encountering some funky behaviour - it seems that as soon as I define
jira.extra_fields, the dict of extra fields overridesdescription_template, and I'm wondering if there are any known workarounds.Without
extra_fields: description worksWith
extra_fields: description is overwrittenIn this setup it seems like the map of extra_fields overrides the description?
Other notes
jira.add_tags: as long as I don't addextra_fields, just using tags doesn't override the descriptionjira.extra_fields.Any help appreciated!
The text was updated successfully, but these errors were encountered: