feat: Make it possible to start/stop Jira tasks based on Jira status

[jhutar]

This is to reflect Jira status changes in Taskwarrior start/stop status.

Please take a look and let me know if it makes sense.

Known bug is if the task is completed in Taskwarrior, but In Progress in Jira, it will not be started in Taskwarrior until another pull.

[ryneeverett]

I agree that we should be able to support this workflow, but I hope we can find a more maintainable solution.

For one thing, db.synchronize is already probably the messiest part of bugwarrior and I'm generally hesitant to add anything to it when it's already in need of a refactor. That's not necessarily the main blocker but some background context on my thinking here.

My main objection at this point would be that it doesn't seem like the services in general, or even Jira for that matter, have fields which obviously and objectively map onto the "started" concept. My impression is that most services have a very limited set of statuses and leave this kind of thing for labels. It seems like everyone is going to have their own idea of how this mapping should work and it isn't going to be practical to implement all the possible mappings in bugwarrior in order to expose them via simple configuration options, which suggests that this a good candidate for hooks which can provide a more open-ended solution.

My first thought is taskwarrior hooks, which could be implemented as a on-add/on-modify hook. Since the status is already a UDA, you wouldn't have to make any changes to your bugwarrior configuration. (If you go this route, please share. We might need to add a "Recipes" page to the documentation.)

Alternatively, if there was a compelling advantage to implementing this as a bugwarrior hook we might need to add a post_import hook to support this.

What do you think? This seems like a carefully crafted PR and I'm sorry if it seems like I'm shooting it down.

[jhutar]

Hello @ryneeverett ! Thanks for looking into it!

I have nothing to say about if synchronize() needs refactor, but I assume that was not a Q on me. Yes, it is long and bit hard to understand.

I added that code to synchronize(), because I wanted to remove that fake _started field from issue_dict before we count task's changes.

Regarding how Jira (and other services) define what "started" is: Exactly. If I'm and engineer, status I care about might be something like "IN_PROGRESS" in one project or "ON_DEV" in another, if I'm QE it might be "ON_QE" or "IN_VERIFY", if I'm a product manager, maybe it is "REFINING". Also names of these states might be different for every project I'm in as in Jira you can define your own workflow. That is why I created that start_states list config value to allow user to specify specific states it considers as "started". I think similar approach could be used for other services. In GitHub issues, for some projects, that might involve looking into tags of the issue for example. The code would depend on a service I guess.

Regarding the TW hooks, I never used them/did not knew about them. Looks like it would be very easy to use that to achieve same effect. If above does not make you to change the opinion :), I'll try to implement it and share it back.

Thank you for pointers and great review!

[ryneeverett]

I assume that was not a Q on me.

I'm not familiar with this phrase but no, it's certainly not your fault that synchronize() is a mess and I don't expect you to fix it. However, it's largely a mess because we've been undisciplined about bolting on additional features without architectural consideration.

That is why I created that start_states list config value to allow user to specify specific states it considers as "started". I think similar approach could be used for other services. In GitHub issues, for some projects, that might involve looking into tags of the issue for example. The code would depend on a service I guess.

I think you understand my point but I'll make it explicitly for the record -- Configurability solves the problem that everyone is going to have different field values that correspond to "started", but it doesn't solve the problem that every service doesn't necessarily even have a single field that obviously maps onto the "started" concept.

I'd suggest the following as we continue to investigate how best to support this functionality:

1. First, is it easy to implement this with hooks? If so, I'd much rather document how to do that and then consider adding core bugwarrior support if the hooks become widely used. If we're going to add features like this that require adding complexity to the core of bugwarrior's execution flow, it would be best if they have popular demand. The other advantage is that we would be assured our design is generalizable across a variety of users and services.
2. If hooks are not viable and there is a real advantage to adding this to bugwarrior core, I think we'd need to look at a good number of services and think about whether there is really one and only one obvious field to use for this. If not, it's back to the drawing board.

[jhutar]

Cool, I'll implement this using hooks and will try to create a PR to the docs describing that.