WorkItem programmatic migration query
I'm working on a set of migration apps at the moment to move issues from our existing issue tracking system into VSTS Work Items.
To maintain tracking information, there are various bits of information I'd really like to copy over such as "CreatedBy" and "CreatedDate" but these are ReadOnly fields in the WorkItem class.
I know I could create yet more custom fields to hold this information, but then I end up in a situation where existing issues look different from new issues in my ongoing set of Work Items. Is there any way that I'm missing that I could force these values to accept my input during this import ?
I've toyed with the idea of impersonating different users and reconnecting to VSTS to fake the CreatedBy. Would be a bit of a pain, but doable I guess, though it doesn't help me with the CreatedDate.
Any bright ideas (or promises of future relaxation of the readonly properties) ?
Cheers,
Martin
For the current Beta2 bits, there is no programmatic way of doing this. Post Beta2 we have implemented a feature where you can bypass all the workflow rules. In your case you can insert values for the read-only fields CreatedBy & Created Date. You should be able to do the update thro' proxy by constructing an update package where you can specify the Bypass attribute. We are also considering OM support for this feature.
Hope this answers your question.
I am happy to assist you if you have any further question regarding this.
-Sundar
Thanks for the swift reply Sundar.
I'm not sure whether I've read you right - are you saying that the 'bypass read-only' will be available within the UI for work items?
I guess to be truly customisable, it would be nice if all read-only attributes were able to be disabled through the XML definition for the Work Item Type, but in reality I can't actually see any cases (so far) in which I'd particularly want to bypass one except for initial population of the database.
I'm looking at needing to migrate around 30,000 items into Work Items so I'm definitely in need of some bulk-import approach to this. I'm not at all sure what you mean by "construct an update package". I've had a look around and the only two real options I've really come across, were writing my own import via the Object Model or doing some sort of mass import into Excel and then importing from there into VSTF. Am I missing an option I should have considered ?
Cheers,
Martin
In the post-beta2 code base today, we have a bypass rules attribute that's passed as an xml attribute to the update batch xml sent to the web service.
**The bypass option will get rejected if you're not a service account - it's specifically for migration scenarios by operations controlled accounts. Our converters will use this option**
Our OM is supposed to offer the bypass flag in save which will also not even send to the server if you're not a service account. I don't think that's in the code base today. *hint* *hint* Mareen if you're reading this :) That will allow a tool running under service account rights to write just about anything but corrupt data (must be valid node IDs, revs must increment etc...)
We will also offer a bulksave API in the OM and mid-tier. It was needed for office integration but is nice for migrations. Note that the bulk save can only bulk items in the same project per call.
thx
Hi Martin,
What is the tool that your projects' workitems are currently in? We are shipping with some conversion tools that can migrate from some existing products.
My understanding is also that we will be exposing sample code to do this, as part of the release.
Post beta2, there is support to "bypass" rules by coding directly against the middle tier. When we ship, the "conversion" tools mentioned above will have code that goes directly against the middle tier.
Like Bryan mentions above, there is also a plan to allow the object model to take a "bypass" flag. However, the bypass flag, if provided in the object model, will not quite behave the same as writing directly against the middle tier. This is because the object model does 3 things to interpret the workitemtype definition (that is part of the process template):
1. It gives the UI indications of how controls should be painted, contents in controls, etc.
e.g.: Whether a field control on a form should be read-only, what the allowed values in the dropdown for the field should be, etc.
2. It interprets the data in the workitemtype definition to set values in fields. (For example, an administrator may have defined that when the value of field State changes, the value of field DevelopmentGroup should default to "Joes group"). Changing values in a field, may cause rules to fire (if so defined in the workitemtype XML) that changes values in other fields. In a conversion tool, this behavior may not be appropriate, as data can get converted with values that were different from what was present in the source item.
3. When the workitem holds data that violates the contents of the workitemtype definition, it prevents the workitem from being saved into the database.
The bypass rule flag would allow "Service account" groups to bypass the 3'rd feature, and allow most data to be saved to the backend. However, it will still cause 1 and 2 to happen when going directly against the object model. So, depending on the situation, you may need to decide to go using the conversion tools, writing your own conversion tool using sample code, or calling the object model method with these caveats.
A standalone app that can write data to the database, and which can be used for migration data is a nice suggestion for a tool, and I will forward it to our program manager.
Thanks.
-Mareen.
Hi Mareen,
We currently maintain our issues in our own custom ASP/SQL2k system, so it's unlikely that any conversion tools for specific migrations will help me too much.
What might be useful would be if you had a tool which imported from a defined XML schema, which those of us with custom datasources could export our databases into.
What I'm actually developing is a tool which allows our project managers to load up existing issues either individually or in bulk by various categories, review them if they wish & migrate all marked issues into the VSTS database. Since it's a one-off migration effort which I'm happy to run several times before the final live run, I don't mind tweaking my data programmatically to ensure it doesn't break data constraints in your Step 2, but I really don't want all the issues to end up owned by 'System', so I'll be very happy to see Step 3 removed from the process.
I'll watch the release notes for the CTPs with interest!
Thanks,
Martin
I've haven't been able to find this much needed magical flag in the object model. Did it make it into the RC? I hope it applys to CreatedBy and CreatedDate.
Is there any update to this? We really need to progress with our tool for migrating our existing bug data.
If it missed the RC will it be in the RTM?
Thanks,
Hi
I have seen a couple of references that migration tools will be provided for work items, although so far can only find details on clearcase migration. Could you give details of which other existing issue tracking systems will have migrations provided? I guess the ability to import XML or CSV would be of most generic use..
regards
charly
Hi......
i'm also working on a special migration of Work Items into VSTS. Till today, I've hoped to find some new dlls or hints in the RTM Installation, about the unwriteable fields, like CreatedDate and CreatedBy. But i can't find anything.
Is there any possible given in the RTM Version of VSTS ?
If so - can you please give me an explanasion how to use it?
Pls answer ASAP. Otherwises my migration is sensless so it's very important for me !
Thanks for your help !
Its been a year since this thread was opened...
I would like to see an explanation of how doing the bypass trick too...
Thanks,
Roman
I am looking for the same thing -- importing WorkItems from an outside CM system without having to jump through hoops to set the State to something other than "Active".
I'm currently using the object model to do the importing. I'm considering doing this: saving all workitems as Active, then reopening the workitem and setting the State to the value I want -- unless, the value I want is "Closed", in which case I have to set it to "Resolved" first, then repeat the process, setting the state to "Closed"... not very spiffy.
I'm guessing that the "bypass" trick was left out and we are on our own. Any MS folks care to refute that?
The only way to "bypass" is to have permissions enough (project administrator IIRC) to alter the work item type definition to allow the transition you want (restricted to a particular user using the for syntax .. run your import.. then revert the work item type definition back to the original... however this would also bypass any workflow transition components that are already defined so you should pay attention to what "should" happen at each step in the process.
Depending on how you define it this transition may be invisible to the rest of the users.
Thanks for the reply!
The only downside of this approach is that you may only have ONE transition from the empty state at a time. So in order to import Active, Resolved, Closed and Duplicate work items from a different system, you have to import work items in groups, changing the work item type definition before each batch. Not great, but good enough! Thanks again!
