-
-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] ClosedDate is set to Null and will revert to the current date on save! #1959
Comments
Hello, i can reproduced the issue. The Problem is that the field Microsoft.VSTS.Common.ClosedDate is readonly at the target. The check of the State in this Line (Current Master Branch Line No. 474 ): if (!_ignore.Contains(f.ReferenceName) && returns false and the Field in the target can't be set. State Values: Source: DevOps Server on premise |
This is great work. If What we need to figure out is what is causing the |
Could you be clearer as to the source and target version? Which versions are TFS (on-prem) and which are ADO (cloud)... p.s. I just call everything on-prem TFS as it avoids confusion... |
On-Prem it is the latest Version of DevOps 2020.1.2 with Patch 9. |
And this is the test config of my WorkItemMigrationConfig Processor: |
Hello, I hope all is well! I wanted to check in and see if there's been any progress on the bug. Any updates or tips would be super helpful and much appreciated. |
@Slawisch thanks for getting in touch. We have not been able to identify a pattern either... I've raised it with the product team, and added additional logging to see what the issue is. It would require some debugging in Visual Studio to really find the issue. There are some instructions above if you can! |
Hello again. I think I found why it happens. Why it happens: |
Im not sure I 100% follow your workflow there... could you update it to make it clearer? It will help me understand if I can 1) make a code change to fix it, or 2) replicate it locally. Can you specify exactly what the order of revisions is on the source? if I can replicate it here, I can try some cod-itzu (code+jujitzu) to get this resolved. |
_n - number of revisions, so that Rev.: n, for example, is the last one. Scenario when bug happens:Rev.: n-2 Rev.: n-1 Rev.: n Result: closed date not set on target Scenario when bug does not happen:Rev.: n-2 Rev.: n-1 Rev.: n Result: closed date set on target only on last revision |
OK, so based on @Slawisch's awesome work here it looks like we could work around this by injecting a new revision in the Bug Senario to turn it into No-Bug Senario! |
For that we need to detect the scenario when building the revisions in the |
I made some changes locally just to make it work already. Sure it could be done better, but I just needed it to be done somehow, so here what I did so far: Created new function to copy last revision and push it with some minor changes:
And calling it in
|
I also have some offtopic question, @MrHinsh, we may get |
The error is comming from ADO and not from our code. We can only migrate work items that we can open. 🤷♂️ |
Hi again, is there any news on a fix? |
There is no fix on my end for this. It's an Azure DevOps OM issue... |
Sorry, I mean ClosedDate fix, with pushing one extra revision |
Hey👋 Just wonder, if you meant ClosedDate bug or "work item cannot be found" error in your latest comment? |
In both v14.4.6 and v14.4.7 I receive the additional warning logs on these "ClosedDateIsMigrationDate" work items:
2024-02-26 15:32:18.078 -06:00 [WRN] The field Microsoft.VSTS.Common.ClosedDate is set to Null and will revert to the current date on save! 2024-02-26 15:32:18.078 -06:00 [WRN] Source Closed Date [#nnnnnn][Rev4]: "2022-04-20T14:04:02.1230000-05:00"
The History tab on the source work items has the Closed revision data showing: Closed by, Closed Date, Board Column (new and old), Reason (new and old), Resolved By, and State (new and old).
Originally posted by @t-anderson in #1747 (comment)
Somehow between these two breakpoints the value is lost!
https://github.com/nkdAgility/azure-devops-migration-tools/blob/855c55cefb23b27ae62aedca45127a6430c65103/src/VstsSyncMigrator.Core/Execution/MigrationContext/WorkItemMigrationContext.cs
HELP NEEDED - We are unable to replicate this! But it does happen!
Can someone with this error please run a specific work item that they find has this issue through the tool and do one of the following:
Option 1: Generate and attach Log - if you are non-technical this is your option. It might provide us with enough info to diagnose, but may only result in more asks.
LogLevel
toDebug
.Option 2: Debug in Visual Studio - This option is best but requires some developer experience.
Create a comment below with the results of your investigation!
The text was updated successfully, but these errors were encountered: