fix: flatten project falls back to organization default template ID

[wwmoraes]

The Azure DevOps API does not guarantee a process template ID will be returned when getting a project detail. This seems to be caused for projects which use the organisation default template. As such, the lookup logic should allow to fallback to that value, if none is present at the project level.

The changes introduced allow an empty work item template parameter, which will force a lookup on the organisation level. The default value is kept as Agile for compatibility and design choices.

Fixes #199

All Submissions:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.
• I ran lint checks locally prior to submission.
• Have you checked to ensure there aren't other open PRs for the same update/change?

What about the current behavior has changed?

Issue Number:

Does this introduce a change to go.mod, go.sum or vendor/?

• Yes
• No

Does this introduce a breaking change?

• Yes
• No

Any relevant logs, error output, etc?

(If it’s long, please paste to https://ghostbin.com/ and insert the link here.)

Other information

[xuzhang3]

@wwmoraes this issue is still not fixed, fallback to ORG default template may set the wrong template result in a state diff.

[wwmoraes]

@wwmoraes this issue is still not fixed, fallback to ORG default template may set the wrong template result in a state diff.

Thank you @xuzhang3 for the review! I've updated the code to remove the hardcoded Agile template and instead use the organisation default. This means a breaking change for a subset of existing customers that both:

• don't set work_item_template explicitly on their resources
• have a work item template set on their organisation different than Agile

This also has the side-effect that future changes on the organisation default template will cause all resources without work_item_template explicitly set to trigger a recreation. For such cases, the best practice is to set it.

[xuzhang3]

@wwmoraes I do not think change the default value to empty string and set it to the default organization process template is the best choice

1. The default value will be changed via the organization default process template.
2. The default is not clear to users, it will set to the default process template of the organization, not the empty string defined in the schema.
3. Breaking changes. The template cannot be found, this could be a permission issue not the APIs, though this fix can be a workaround for this issue.

[wwmoraes]

@xuzhang3 thank you again for reviewing it 😄

The default value will be changed via the organization default process template.

This is exactly how the upstream service works: the organization itself has a default. Having a custom hardcoded value here means this provider has a distinct behaviour than the upstream service, which increases cognitive load. Mitigating an eventual recreation diff seems like a poor reason to do that. Besides, infrastructure-as-code is meant to be declarative, so a customer is prone to uncontrolled changes for things they do not explicitly configure, which seems fair.

The default is not clear to users, it will set to the default process template of the organization, not the empty string defined in the schema.

I've updated the docs mentioning that the default is the one set on the organization. The empty string on the schema is due to the "offline" approach used for its creation. We could change the schema during initialization using the configure context function, but that wouldn't solve the declared empty string you're referring to.

If you mean the upstream service documentation is unclear about this then that's a problem of the upstream service provider.

Breaking changes. The template cannot be found, this could be a permission issue not the APIs, though this fix can be a workaround for this issue.

If you mean the original issue, #199, then its not a permission issue: one of the users that tested it is the organization owner.

[xuzhang3]

@wwmoraes thanks for your feedback, I would like to keep the default type to Agile not set it to empty string and fall back to organization default template. Keep it clear and visible to users when run terraform plan. Agree with fall back to organization default template when template not found.

[wwmoraes]

@xuzhang3 would you be so kind as to review it again? I've reinstated the Agile default value, and configured an empty string to trigger the organisation fallback. 😄

[xuzhang3]

@wwmoraes LGTM 🚢