Extended action

[Mossop]

Adds a new action that adds support for syncing the assignee and status of bugs over to Jira. The assignee is fairly blind, if the bug assignee exists as a Jira user who can be assigned to the ticket then it does so. The status is more complex as different projects have different statuses so this lets each whiteboard tag define a mapping from the bugzilla status to the jira status. In both cases we only attempt to update jira if the bug field actually changed (or if it is a new bug).

I'm a bit unsure over whether this should be a new action or just an addition to the default action. Certainly the status syncing can be disabled by simply not providing a map. Conceivably the assignee syncing could be made to be configurable. I know we want this in at least two projects, probably more. That also made me fail to come up with a decent name for the action!

[leplatrem]

Thanks! This is cool!

After a quick overlook, before going into deeper review, could you please:

• add some logging (debug) especially for situations where the action gives up (using struct logs like in Improve logging using context (fixes #73) #74)
• pass kwargs explicitly (eg. payload.map_as_comments(status_log_enabled=False, assignee_log_enabled=False) instead payload.map_as_comments(False, False))
• Add a paragraph of documentation in the README about this action

[Mossop]

@leplatrem Updated.

[leplatrem]

This looks good!

I noted a few nits, feel free to ignore them if you don't find them relevant.

Regarding the naming, extended is fine. Alternatives could be:

• an explicit naming like default_with_assignee_and_status
• additional parameters on the default action
• a refactor to execute multiple atomic actions instead of a single one

We can discuss this in a dedicated issue. We are learning on the way here :)

Note:
I started a big refactor of tests in #76 . But I'll merge this PR first and rebase the refactors on top of it

[Mossop]

This looks good!

I noted a few nits, feel free to ignore them if you don't find them relevant.

Regarding the naming, extended is fine. Alternatives could be:

* an explicit naming like `default_with_assignee_and_status`

* additional parameters on the default action

* a refactor to execute multiple atomic actions instead of a single one

I went with the different action since that was recommended to me as the thing to do for new behaviour. I actually think that syncing the status and assignee are likely to be such common needs (I've only talked to two teams using JBI but both of them want it) that unless you disagree I think we should just fold this into the default action. The status_map is already optional and I could just add an option for syncing the assignee defaulting to false so no-one is impacted at the start.

[leplatrem]

unless you disagree I think we should just fold this into the default action.

I think it makes sense to fold it in another iteration, especially if all use-cases use it :)

We can also discuss this in #77 (thanks for your input and comment there!)

[Mossop]

@leplatrem I think I've addressed all the comments and also renamed the action to your suggestion so its purpose is clearer.