Per service static_fields

[telenieko]

Hi,

From this talk: https://youtu.be/zl68asL9jZA?t=1377 (22:57) it appears you can set static_fields per service, though I don't see that in the documentation.

But, if I do the same it does not work.

The only place in the code I found usages of static_field is in db.py:syncronize though it appears it only uses that settings from [general] but not from the services definition. Am I correct?

Anyway, this is a feature request to be able to set static_fields per service instead of general.

thanks

[nblock]

Do you mean something like this:

jira.description_template = {{ jiraid }}: {{ jirasummary }} [{{jiraissuetype | lower }},{{ jirastatus | lower }}]
jira.project_template = companyname

The project attribute in the above example is a static field with the value companyname for this particular service. The description is updated dynamically. See the last paragraph in this document: https://bugwarrior.readthedocs.io/en/latest/common_configuration.html#field-templates

[telenieko]

As far as I see: static_fields means that, in your example, description would only be calculated on task add, but never again updated (ie: on gmail I always change the description on taskwarrior, so the field needs to stay untouched on further pulls). But on Github it is ok to have the description updated.

So, for github my static_fields would be blank, for gmail it would have 'description' on my setup.

As far as I've seen, this can't be done, static_fields is a global parameter.

[ryneeverett]

The example of using description as a static field is particularly problematic because it is the only required field to add a task in taskwarrior. Leaving other fields blank when we initially add tasks is fine, but we are forced to add a description, so I'm pretty sure using description in the global static_fields would fail at the moment.

It would take special logic to support this and it's not clear exactly how it would operate. When we initially add tasks we could make the initial description <placeholder> or something or set it to the remote description and then never update it. Either way I think it would take a significant refactor of the way static_fields works at the moment.

Perhaps a separate option, e.g. editable_description=True, would make more sense since it couldn't behave identically to other static_fields anyway? Is there still any interest in this?

[ryneeverett]

I'm actually thinking we might run into this issue with any of the core attributes. Maybe per-service static_fields just doesn't make sense and we'd need to implement something like editable_fields.