[DO NOT MERGE] Alternative fix for timezone issue [Issue 2094] by daragh-kearney · Pull Request #2180 · MyPureCloud/terraform-provider-genesyscloud

daragh-kearney · 2026-03-02T13:11:03Z

Added new attributes callable_time_column_name / contactable_time_column_name and deprecated the old time_column fields.
Updated expand/flatten + set hashing and added a small CustomizeDiff to smooth migration.
Updated tests/helpers to use and assert the new column_name fields.

bbbco

As we spoke about on our call last week, this issue is due to the Genesys Cloud API change to the contact list endpoints. Namely, they are migrating off of using the callableTimeColumn on the phoneColumns and contactableTimeColumn on the emailColumns fields in favor of the callableTimeColumnName and contactableTimeColumnName fields.

While we were on the call, we determined that the API currently still accepts the callableTimeColumn and contactableTimeColumn fields on creation/updates to the API, but when reading this API, these fields are only showing up on the callableTimeColumnName and contactableTimeColumnName fields. However, the purecloud Golang SDK hasn't updated with these fields yet, so we have to implement some workarounds.

I think we need to determine what the plan for addressing this interesting state. Please take a look at my comments and maybe work with @HemanthDogiparthi12 or someone on the CX as Code team to determine the best path forward. It will be important that this is handled in a correct manner, or we risk breaking the ability to sync these resources in the various BCP implementations.

bbbco · 2026-03-03T15:18:56Z

genesyscloud/outbound_contact_list/resource_genesyscloud_outbound_contact_list.go

 			return retry.NonRetryableError(util.BuildWithRetriesApiDiagnosticError(ResourceType, fmt.Sprintf("failed to read Outbound Contact List %s | error: %s", d.Id(), getErr), resp))
 		}

+		// The SDK model for phone/email columns does not include the API-returned `*TimeColumnName` fields.


You should probably include in this comment a link or JIRA to the corresponding fix for pulling this field into the SDK with instructions to remove this code after the SDK has been upgraded with support for the new field.

I've now added a TODO with a link to the Go SDK repo to remove this once the SDK models include TimeColumnName fields.

bbbco · 2026-03-03T15:34:44Z

genesyscloud/outbound_contact_list/resource_genesyscloud_outbound_contact_list_schema.go

+					return d.Get("automatic_time_zone_mapping").(bool)
+				},
+			},
+			`callable_time_column_name`: {


So, I don't know if its absolutely necessary to add a new field to the schema. Basically, there are two approaches you can take:

Add a new field to the schema that matches the name of the new API field, with a deprecation message (what you have implemented in this PR) plus adding a migration path (see the routing_queue resource for how a migration was handled in the past)

Pros: Keeps the provider fields 1:1 aligned with the API fields

Cons: Requires the user to make changes/modifications to their Terraform code / output via a code migration.

Retain the callable_time_column field. Update the flatten/build functions to read/write to the callable_time_column_name field for this schema field.

Pros: Seamless experience from the user's perspective. No migrations or updates to their code necessary.

Cons: Deviates from the API so that the field names don't match up 1:1 (callable_time_column does not match callableTimeColumnName). A comment on the description of the field could clarify this aspect for the user.

You should check in with your team leads on which approach is desired.

After discussing with Hemanth we determined that Approach 1 was desired: I've added the new _time_column_name fields, deprecated the old _time_column fields, and provided a migration path via StateUpgraders using the routing_queue resource as reference.

yes this wont break anything for the end user immediately, (thanks to the deprecation) and we can remove this in the later releases. api fields 1:1 aligning with the terraform schema will make sure of consistency in the long run.

bbbco · 2026-03-03T15:35:05Z

genesyscloud/outbound_contact_list/resource_genesyscloud_outbound_contact_list_schema.go

+				Optional:     true,
+				Type:         schema.TypeString,
+			},
+			`contactable_time_column_name`: {


Same as above comment for this field.

bbbco · 2026-03-03T15:36:46Z

genesyscloud/outbound_contact_list/resource_genesyscloud_outbound_contact_list_schema.go

 				Optional:    true,
 				ForceNew:    true,
 				Type:        schema.TypeSet,
+				Set:         hashOutboundContactListPhoneColumn,


If you hash these values, how is the provider supposed to read the values back?

Fixed set behavior so hashing is only for stable TypeSet identity, and ensured flatten/build keep state consistent:

Flatten now uses the same hash function as the schema Set: function.

Flatten writes both legacy and new time_column fields so config/state don’t drift and match correctly.

bbbco · 2026-03-03T17:39:23Z

...cloud/outbound_contact_list_template/resource_genesyscloud_outbound_contact_list_template.go

Great work identifying that this would be impactful to the contact list template too! Same as we decide to do with contact list should also be done here.

I've now applied the same approach to the contact list template as well.

bbbco · 2026-03-03T20:49:51Z

genesyscloud/outbound_contact_list/resource_genesyscloud_outbound_contact_list_schema.go

 )

+func normalizeOutboundContactListTimeColumnFields(_ context.Context, diff *schema.ResourceDiff, _ interface{}) error {
+	// Backfill the new *_column_name fields from the legacy *_column fields at plan time.


This isn't exactly backfilling as you expect. All it is doing is manipulating the diff output so Terraform doesn't see the differences between the two fields as a change. The state is not getting updated, which is what would happen in an actual backfill. However, that should happen within the confines of a schema migration. See my comment further down to determine if that is the approach you want to take.

I've now implemented a schema/state migration: bumped SchemaVersion and added StateUpgraders so existing state is actually upgraded.

bbbco · 2026-03-03T20:54:37Z

genesyscloud/outbound_contact_list/resource_genesyscloud_outbound_contact_list_utils.go

+		if callableTimeColumnName, ok := contactPhoneNumberColumnMap["callable_time_column_name"].(string); ok && callableTimeColumnName != "" {
+			sdkContactPhoneNumberColumn.CallableTimeColumn = &callableTimeColumnName
+		} else if callableTimeColumn := contactPhoneNumberColumnMap["callable_time_column"].(string); callableTimeColumn != "" {
 			sdkContactPhoneNumberColumn.CallableTimeColumn = &callableTimeColumn


So I think the API is at a point right now where it allows setting the CallableTimeColumn but only getting on the CallableTimeColumnName.

This is fine logic if you are using Option 1. from above, but not needed if you are using Option 2. until the API completely decommissions the CallableTimeColumn field.

daragh-kearney added 2 commits March 2, 2026 12:57

initial commit

6a728c7

initial commit

48cc6a4

daragh-kearney requested review from HemanthDogiparthi12, carnellj-genesys, shrutisuryawanshigenesys and sureshperiyappan as code owners March 2, 2026 13:11

bbbco suggested changes Mar 3, 2026

View reviewed changes

daragh-kearney added 2 commits March 9, 2026 16:31

attempting approach 1

e502bed

attempting approach 1

8cda83a

HemanthDogiparthi12 approved these changes Mar 12, 2026

View reviewed changes

Conversation

daragh-kearney commented Mar 2, 2026

Uh oh!

bbbco left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants