My client has a couple of multi-year projects with a large number of defects (thousands). I have just added some custom fields to help with analysis and populated them with the respective values (via the Bulk Edit capability). Some of the defects have not been touched in a significant time, but unfortunately, adding the analysis values has set the Last Updated field to yesterday (when I applied the field). I would like a way of updating records in a way that does not update the Last Updated field, or to reset it after I have made the change. This could be, for example, by adding an attribute to custom fields to indicate that they are not to update Last Updated (they fall into a non-core category, perhaps). en-US(C) Copyright 2006-2026 Inflectra Corporation.support@inflectra.com/Computers/Software/Project_Management//Computers/Software/Quality_Assurance/KronoDesksupport@inflectra.comhttp://www.inflectra.com/kronodesk/forums/threads120/Support/Forum/announcements/rants-raves/2952.aspxthreadId=2952Colin Main (colin.main@cmat.co.uk) My client has a couple of multi-year projects with a large number of defects (thousands). I have just added some custom fields to help with analysis and populated them with the respective values (via the Bulk Edit capability). Some of the defects have not been touched in a significant time, but unfortunately, adding the analysis values has set the Last Updated field to yesterday (when I applied the field). I would like a way of updating records in a way that does not update the Last Updated field, or to reset it after I have made the change. This could be, for example, by adding an attribute to custom fields to indicate that they are not to update Last Updated (they fall into a non-core category, perhaps). Wed, 17 Jul 2024 12:57:04 -04002026-05-20T08:11:02-04:00/Support/Forum/announcements/rants-raves/2952.aspxmessageId=6824David J (adam.sandman+support@inflectra.com) Hi Colin Im afraid for audit purposes that is not possible through the UI or the API. You would need to make any such updates directly in the database (which is not officially supported, but would work in this case). Regards David Wed, 17 Jul 2024 14:55:21 -04002024-07-17T14:55:21-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply6824messageId=6948Kenneth Hume (macdonaldfrench7286566@gmail.com) You can execute raw SQL queries to update the fields directly without affecting the timestamps. This method bypasses the ORM and its automatic timestamp handling: UPDATE your_table SET custom_field = value WHERE condition space waves Wed, 21 Aug 2024 01:54:46 -04002024-08-21T01:54:46-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply6948messageId=6949Ilia Poliakov (ilya.polyakov@edetek.com) I have similar problem. We have some technical fields that are updated from git/quality control tools. First of all, they brake Spiras entity history as it becomes not readable. Second, yes, I wish Last Updated field not to be changed. So, I would like to be able to exclude some custom fields from being tracked in a history and from changing Last Updated field. Wed, 21 Aug 2024 07:26:51 -04002024-08-21T07:26:51-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply6949messageId=7014elliot zucker (elliotzucker1@gmail.com) It is possible to update the record in a way that does not update the Last Updated field or reset the field after making changes but the history may still be retained fish eat fish Tue, 29 Oct 2024 07:51:27 -04002024-10-29T07:51:27-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7014messageId=7015Kat A (elise.brooks@inflectra.com) Hi Elliot, As David said, for audit purposes that is not possible through the UI or the API. You would need to make any such updates directly in the database (which is not officially supported, but would work in this case). Regards, Kat Tue, 29 Oct 2024 13:56:53 -04002024-10-29T13:56:53-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7015messageId=7157Laverna Whitaker (joellenkimball@hotmail.com) It seems like your client is facing a significant challenge with managing large-scale defects effectively, especially with the unintended update of the Last Updated field. Here are a few potential approaches that might help you resolve this: Field Category Setup ( cluster rush ) : Some platforms allow you to designate fields as non-core or informational. If your current tool supports categorization, you could mark certain fields as exempt from triggering updates to the Last Updated timestamp. Using API or Scripting: If the platform youre using has API support or scripting capabilities, you could design a custom function that updates specific fields without modifying the Last Updated property. This would bypass the issue entirely. Configuration Options: Explore whether your tool offers settings to exclude particular fields from influencing the Last Updated field. Its possible this feature exists but might require enabling or configuring under advanced settings. Manual Timestamp Adjustment: If no automated options exist, you could potentially update the Last Updated field back to its original value manually after bulk edits. While time-consuming, this may be viable for smaller batches. Engage Tools Support Team: If none of the above options are available, contacting the support team or community forums for your defect management tool could provide insights on handling this issue or even suggest future enhancements. Fri, 21 Mar 2025 09:40:38 -04002025-03-21T09:40:38-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7157messageId=7201Jarrett Cantwell (thuhinn1233@gmail.com) I found this to be a very practical and useful share in project data management. Mass updates that change the Last Updated field can indeed cause confusion about the revision history. Thu, 24 Apr 2025 06:21:48 -04002025-04-24T06:21:48-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7201messageId=7203Jarrett Cantwell (thuhinn1233@gmail.com) Quithard1941 I found this to be a very practical and useful share in project data management. Mass updates that change the Last Updated field can indeed cause confusion about the revision history. Thu, 24 Apr 2025 11:38:14 -04002025-06-05T12:23:55-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7203messageId=7212Michael Arrington (michaelarringtony@gmail.com) Mass updates, even for adding valuable custom analysis fields, shouldnt inadvertently skew this important data point. Tue, 29 Apr 2025 07:58:05 -04002025-06-05T12:24:02-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7212messageId=7256Kent Chandler (roycarlson56@gmail.com) Thats a great point. Bulk edits for analysis shouldnt necessarily alter the Last Updated timestamp, especially for long-term tracking. A non-core or metadata-only flag on custom fields sounds like a smart solution. Alternatively, having an option to suppress timestamp updates during certain bulk operations would be really useful. Hopefully the team considers this for a future release-it would definitely help maintain historical accuracy in large datasets. Tue, 20 May 2025 09:52:36 -04002025-06-05T12:28:51-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7256messageId=7269straightforward forward (straightforward.newt.yedd@letterprotect.com) The issue Colinmain raises is important for maintaining data integrity! The Last Updated field is often used to track progress, identify missed bugs, or bugs that need to be revisited. Having it updated incorrect by simply by adding analytical fields, would distort the overall picture of bug status. Wed, 28 May 2025 07:53:24 -04002025-06-05T12:29:14-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7269messageId=7280Hailey Nelson (haint.kaia@gmail.com) You could suggest adding a silent update option in Bulk Edit or field settings, allowing changes to non-critical fields without modifying the Last Updated timestamp. Thu, 05 Jun 2025 08:48:04 -04002025-06-05T12:29:22-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7280messageId=7329Ilia Poliakov (ilya.polyakov@edetek.com) We also need a silent update for fields, defined by system admin. Those updates shouldnt affect artifacts history. Wed, 23 Jul 2025 08:54:54 -04002025-07-23T08:54:54-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7329messageId=7651Donald Carte (Stevendavid1754@hotmail.com) A possible workaround is to use a bulk update method that allows suppressing audit/timestamp changes (if your tool supports APIs or background jobs), or to store these analysis values in a separate metadata/analytics layer instead of the core defect record. Otherwise, you may need to re-derive Last Updated from actual issue activity history rather than field edits. Wed, 20 May 2026 08:11:02 -04002026-05-20T08:11:02-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7651messageId=7170Daniel Craig (melted.wildebeest.iidt@letterhaven.net) Hi Colin, You mentioned using Bulk Edit to populate the custom fields, do you find the current Bulk Edit functionality sufficient for your needs otherwise, or are there specific improvements youd like to see there as well to support your analysis workflow? Wed, 09 Apr 2025 08:55:11 -04002026-05-28T05:36:17-04:00/Support/Forum/announcements/rants-raves/2952.aspx#reply7170