Add custom states to work item type

[Fredrik Arvidsson (Fresa)]

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.
• Have you checked to ensure there aren't other open PRs for the same update/change?

Description

Add custom state management for work item types with no inheritance. Work item types that has no parent are created with custom states implicitly. In order to manage these states state blocks are introduced.

Does this introduce a breaking change?

• Yes
• No

Test Result

TF_ACC=1 go test -v -run 'TestAccWorkitemtrackingprocessWorkItemType_' ./azuredevops/internal/acceptancetests/... -timeout 120m
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_DataSource_Get
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_DataSource_Get
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_Basic
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_Basic
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_CreateAndUpdate
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_CreateAndUpdate
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_States
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_States
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_Inherited
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_Inherited
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_StatesForbiddenOnInherited
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_StatesForbiddenOnInherited
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_StatesRemovedFromConfig
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_StatesRemovedFromConfig
=== RUN   TestAccWorkitemtrackingprocessWorkItemType_StatesWithNoChanges
=== PAUSE TestAccWorkitemtrackingprocessWorkItemType_StatesWithNoChanges
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_DataSource_Get
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_Inherited
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_CreateAndUpdate
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_StatesWithNoChanges
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_States
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_Basic
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_StatesRemovedFromConfig
=== CONT  TestAccWorkitemtrackingprocessWorkItemType_StatesForbiddenOnInherited
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_StatesForbiddenOnInherited (0.99s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_StatesWithNoChanges (3.17s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_DataSource_Get (3.30s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_Basic (3.86s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_Inherited (4.40s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_StatesRemovedFromConfig (4.54s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_CreateAndUpdate (6.18s)
--- PASS: TestAccWorkitemtrackingprocessWorkItemType_States (11.05s)
PASS
ok      github.com/microsoft/terraform-provider-azuredevops/azuredevops/internal/acceptancetests        11.064s
?       github.com/microsoft/terraform-provider-azuredevops/azuredevops/internal/acceptancetests/testutils      [no test files]

Related Issue(s)

Fix #1547

Other information

N/A

[Fredrik Arvidsson (Fresa)]

magodo (@magodo) let me know what you think when you have time!

[Fredrik Arvidsson (Fresa)]

magodo (@magodo) did you ever had a chance looking at this? We've been using this on a local build ever since, has worked great so far.

[magodo (magodo)]

Given we already have azuredevops_workitemtrackingprocess_state, why bother to include this additional API in the work item resoruce?

[Fredrik Arvidsson (Fresa)]

magodo (@magodo) When work item types are created with no parent, the Azure DevoOps API create some custom states implicitly. azuredevops_workitemtrackingprocess_state can only manage new custom states defined by a user, or at least I couldn't figure out a smart way of reusing that resource to support this use case; should the state be created or taken over if it happen to exist during apply.

[magodo (magodo)]

Can we introduce a azuredevops_workitemtrackingprocess_builtin_state (os something similar), which is the same as azuredevops_workitemtrackingprocess_state, except the Create will take over the existing state and the Delete will be an noop?

[Fredrik Arvidsson (Fresa)]

magodo (@magodo) Deleting one of these implicitly created states is one of the things we want to support, if you look at the linked issue.