-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
14
-
Severity 3 - Minor
-
Issue Summary
The customer is experiencing an unexpected behavior while refreshing their sandbox with production data, the custom fields are not being refreshed in the sandbox.
"when I viewed in Sandbox the custom fields, I found that there are still custom fields previously created in Sandbox that remained despite the refresh."
Steps to Reproduce
- Create a Sandbox
- Create a custom field in the production instance and Move it to the trash
- Copy data from production to sandbox
- Then, the custom field that was moved to the trash on the production instance will appear as active on the sandbox instance.
Expected Results
After the copy data from production, the sandbox should have the same data as the production instance, which means that if a custom field was moved to the trash in production it should appear as moved to the trash in the sandbox.
Actual Results
The custom field that was moved to the trash on the production instance appears as active on the sandbox instance.
Workaround
Permanently delete the trashed custom field in the production instance or even in the sandbox instance, if the copy from production was already done.
- relates to
-
CLOUD-10910 Sandbox environment for Cloud (see sub-tasks for specific features)
- In Progress
[CLOUD-11264] Trashed custom field in Production become Active in Sandbox after Data Copy from Production to Sandbox
Atlassian!!! 😔
This is pretty annoying. You want us to use Jira as an enterprise wide application, and we do. It's a critical part of so many work streams. It's a big and complicated environment with more moving parts than 1 person can manage.
With most critical and complicated work environments you make changes in a sandbox and then push those changes up into staging, and then production. Basic best practice. And we're trying so hard to implement that in our organization but then there's these basic functionality issues that really impede the process. We've already got to supplement the process using 3rd party tools, can we please get the basics right and not duplicate deleted things back out of the trash.
Thank you 🙃
Just take a look at this one: https://jira.atlassian.com/browse/CLOUD-11498
We all are getting it wrong. The actual purpose of the copy to sandbox is to wipe your sandbox data and copy half of it over. It is by design to be frigging useless. Reviving your deleted custom fields is just the tiny cherry on top.
I was about to create a ticket with Atlassian Support in this regard, but it was deflected by Service Management's Knowledge Base on offering this issue.
So, consider a +1 on the Support reference count ** custom field. Thanks!
In our instance multiple custom fields were "Trashed" in Prod, and were removed from all Screens in Prod. With the Data Copy feature, when copying all projects (JSM and Jira) with Attachments, the Trashed custom fields were still on all the Screens in the Sandbox. If the fields are trashed in Prod and not used anywhere any longer in Prod – my vote is they don't even show up Trashed in the Sandbox. UNLESS they have the exact same "Deleted on" dates from Prod in the Sandbox and will be permanently deleted in the Sandbox on the same dates as the Trashed fields in Prod.
Trashed Prod custom fields persisting on Screens they were deleted from in Prod is a Bug in the Data Copy feature.
This will cause considerable confusion for organizations that use their Sandbox for end user UAT of new customer build/new Atlassian features in the Jira/JSM Sandbox Preview Release track.