Skip to content
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

Querying for already existing work items seems to ignore project #47

Open
tbergstedt opened this issue Dec 20, 2018 · 3 comments
Open

Comments

@tbergstedt
Copy link

We are in the situation where we have once successfully migrated a set of work items to a new team project in the same collection as the original project. When we now want to do this action again to another team project at a later time (short story: think of it as a way of "baselining" a set of work items and their states), the tool claims that a number of work items already have been migrated. So:

Migration 1: Original ==> Project 1, 10000 work items to migrate (success)
Migration 2: Original ==> Project 2, 11000 work items to migrate (only the 1000 new ones are migrated)

It seems as if the status check whether a work item already has been migrated is cross-project, and then returns those work items that have been migrated to the previous project.

@pelvark
Copy link

pelvark commented Feb 4, 2019

@tbergstedt
When the migration is done, all the migrated items are tagged. And if you perform another migration, these tagged items are not migrated again.

You could change the tag in the configuration file here:
// the tag to stamp on the work items on the source project // once the migration is complete. "source-post-move-tag": "6F078B6C-2A96-453B-A7C3-EACE6E63BB97", // the tag to stamp on the work items on the target project // once the migration is complete. "target-post-move-tag": "6F078B6C-2A96-453B-A7C3-EACE6E63BB97",

Or you could make a bulk edit of the items that have the tag.
This could be done by making a query for the tag, and targeting all the results with CTRL-A, right click and click edit. Then choose the option "Tags(Remove)" in the fields section and then write the tag in the value field and clicking OK.

@tbergstedt
Copy link
Author

tbergstedt commented Feb 5, 2019

We had chosen not to create any tags, neither on source nor target items. And we used different configurations in the two migrations, so I don't think any usage/removal of tags would have helped us.

Maybe I wasn't really clear about this earlier, but our problem was that we actually needed to migrate all items once again (to a new target project), regardless of whether they had been included in the previous migration or not. (In the example above there could have been ~6 months between the two runs).

We have managed to circumvent this with some local code changes, but these aren't really up for publishing atm. Hopefully, we might get the time for this at a later date, if requested.

@obvioussean
Copy link
Member

@tbergstedt Unfortunately the API used for checking for work item existence is not project scoped. With the latest updates to the REST APIs on AzDevOps I could support this, since they include the project in the url now. But that would be a potentially breaking change for existing migrations so I'll have to make it an opt-in type experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants