rvgate | 2024-06-27 14:34:03 UTC | #1
I've noticed quite an interesting bug while maintaining genesyscloudtaskmanagement_worktype resources that include statuses with terraform.
When someone renames a status within the UI on resources that are managed through terraform, terraform thinks it should recreate all the statuses. Removing the old ones and re-creating everything from scratch.
This becomes impossible to change when there are workitems assigned to the worktype statuses, and in our usecase the workitems are constantly incoming and therefor never able to recreate statuses. Thus making it impossible to manage through terraform.
This all while changing statuses in the UI works absolutely fine, so it feels like the terraform module does not care about the order or id's for the existing statuses.
Steps to reproduce:
terraform apply
resource "genesyscloud_task_management_workbin" "TerraformWorkbin" {
name = "TerraformWorkBin"
}
resource "genesyscloud_task_management_workitem_schema" "TerraformWorkitemSchema" {
name = "TerraformWorkitemSchema"
}
resource "genesyscloud_task_management_worktype" "TerraformWorkType" {
name = "TerraformWorkType"
default_workbin_id = genesyscloud_task_management_workbin.TerraformWorkbin.id
schema_id = genesyscloud_task_management_workitem_schema.TerraformWorkitemSchema.id
statuses {
category = "Open"
name = "New"
}
statuses {
category = "InProgress"
name = "Assigned"
}
statuses {
category = "Waiting"
name = "Paused"
}
statuses {
category = "Closed"
name = "Resolved"
}
}
Then using the UI, rename one of the statuses, in this example I renamed New to Open.
Using terraform, see if it is tracking this change properly, without any changes in the terraform resource, i would expect a rename from Open back to New. But instead it wants to recreate all the statuses.
terraform plan
# genesyscloud_task_management_worktype.TerraformWorkType will be updated in-place
~ resource "genesyscloud_task_management_worktype" "TerraformWorkType" {
id = "a79c4b55-c215-4c6f-9afc-dd4f4eb6a627"
name = "TerraformWorkType"
# (14 unchanged attributes hidden)
- statuses {
- category = "Closed" -> null
- destination_status_names = [] -> null
- id = "31944af3-829b-4493-af01-d05774af05de" -> null
- name = "Resolved" -> null
- status_transition_delay_seconds = 0 -> null
# (3 unchanged attributes hidden)
}
- statuses {
- category = "InProgress" -> null
- destination_status_names = [] -> null
- id = "48c9b864-8b94-460a-9825-e7f9bc7bd2c3" -> null
- name = "Assigned" -> null
- status_transition_delay_seconds = 0 -> null
# (3 unchanged attributes hidden)
}
- statuses {
- category = "Open" -> null
- destination_status_names = [] -> null
- id = "8182e945-bd73-45a0-b632-cd9986044b00" -> null
- name = "Open" -> null
- status_transition_delay_seconds = 0 -> null
# (3 unchanged attributes hidden)
}
- statuses {
- category = "Waiting" -> null
- destination_status_names = [] -> null
- id = "eff3eea7-e2c8-446d-8690-8edf07c210e8" -> null
- name = "Paused" -> null
- status_transition_delay_seconds = 0 -> null
# (3 unchanged attributes hidden)
}
+ statuses {
+ category = "Closed"
+ destination_status_names = []
+ id = "31944af3-829b-4493-af01-d05774af05de"
+ name = "Resolved"
+ status_transition_delay_seconds = 0
# (1 unchanged attribute hidden)
}
+ statuses {
+ category = "InProgress"
+ destination_status_names = []
+ id = "48c9b864-8b94-460a-9825-e7f9bc7bd2c3"
+ name = "Assigned"
+ status_transition_delay_seconds = 0
# (1 unchanged attribute hidden)
}
+ statuses {
+ category = "Open"
+ destination_status_names = []
+ id = (known after apply)
+ name = "New"
+ status_transition_delay_seconds = (known after apply)
+ status_transition_time = (known after apply)
# (2 unchanged attributes hidden)
}
+ statuses {
+ category = "Waiting"
+ destination_status_names = []
+ id = "eff3eea7-e2c8-446d-8690-8edf07c210e8"
+ name = "Paused"
+ status_transition_delay_seconds = 0
# (1 unchanged attribute hidden)
}
}
Plan: 0 to add, 1 to change, 0 to destroy.
Because it is not allowed to remove statuses that are in use, it is impossible to manage the workbin in terraform anymore.
This bug also applies when renaming a status within terraform. it will ALWAYS want to recreate all the statuses.
It looks like it does not care about previously created statuses and simply removes everything if the current order of status objects do not match anymore.
Any way to work around this?
John_Carnell | 2024-06-27 23:44:19 UTC | #2
Hi Rene,
Thanks for the detailed write-up. I will get a ticket created on this for someone on my team to look at. The status logic in worktype is pretty gnarly so I hopefully we can reproduce this pretty quickly and try to figure out what is going on. We typically go on a two-week sprint schedule and we are right in the middle of one now so I will need to check with the engineers and see if we can slip this.
Really the only workaround at this point is to either manage your worktype and statuses in Terraform or the UI but not both.
Thanks, John Carnell Director, Developer Engagement
rvgate | 2024-06-28 00:02:08 UTC | #3
The workaround to only work in Terraform does not work, even then it will try to recreate the statuses. Note my comment in the original post:
This bug also applies when renaming a status within terraform. it will ALWAYS want to recreate all the statuses.
John_Carnell | 2024-06-28 19:29:41 UTC | #4
Hi Rene,
I talked with our engineering staff today. I have a developer lined up to look at this. They have to finish one other bug and then they will start looking at it. We will post to the room with an update. Thanks again for writing up the detailed description. This helps tremendously.
Director, Developer Engagement
Declan_ginty | 2024-09-03 14:29:21 UTC | #5
Hi @rvgate,
Apologies for the delay, we had to make some changes to the worktype resource to fix the issue here due to restrictions in terraform and the design of the API's used.
Independent Worktype Status Resource
We have moved worktype statuses into their own resource to allow for the proper management of statuses via terraform.
resource "genesyscloud_task_management_worktype_status" "worktype_status" {
worktype_id = genesyscloud_task_management_worktype.example.id
name = "Open Status"
description = "Description of open status"
category = "Open"
destination_status_ids = [genesyscloud_task_management_worktype_status.status1.id, genesyscloud_task_management_worktype_status.status2.id]
default_destination_status_id = genesyscloud_task_management_worktype_status.status1.id
status_transition_delay_seconds = 86500
status_transition_time = "04:20:00"
default = false
}
Attributes removed from genesyscloudtaskmanagement_worktype
With worktype statuses becoming and independent resource we have removed the statuses attribute from the genesyscloud_task_management_worktype resource. We have also removed defaultStatusName from genesyscloud_task_management_worktype and instead the default status will be set by setting default to true on a status resource.
Regards, Declan
system | 2024-08-01 14:53:33 UTC | #6
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 26980