Thanks for checking this Brian, and glad to hear it is working in the internal client. You should be able to do everything in the internal client that you
are doing using the command line. We will address the external client issue in the next beta cycle.
As you point out, the work item association is done after the check in. This is because we need to get the revision number before associating the workitem.
I don’t think a single transaction is possible with our current interface model, but would need to do some additional research.
I think you had a previous subcase open with support, can you request to reopen so that we can document the details and revisit this and the command line issue
From: bryan.macmillan [mailto:email@example.com]
Sent: Wednesday, May 14, 2014 6:01 AM
Subject: RE: [Toad for Oracle - Beta Discussion Forum] Check in Associations not working with Team foundation Server 2013
RE: Check in Associations not working with Team foundation Server 2013
Reply by bryan.macmillan
After switching to the Internal Client, I can confirm the issues with multi nested folders in TFS is back to being functional again and I can check items back into TFS, and also associate work
items successfully**. Hence it would appear the issue is with the external command line client. Historically we have used the external client as older versions of toad supported more features in the external client than internal.
**One point I have noted about the work item check in association is that the work item association seems to be happening after the check-in and not at the same time/part of the check in, hence
toad will override any check in policies in force.
To demonstrate this, go into Visual Studio -> Team Explorer - > settings -> Source Control -> Check-in Policy tab ->add -> select work items -> click ok twice. You should be back at the settings
screen, so now turn on check in alerts; go to “Project Alerts” in the settings menu above (the web client will launch) and tick the “Anything is checked in” check box.
Go back into toad 12.5 (set up with internal client), check a source versioned object out, make a change to a comment, check in (do not specify a work item), note toad will check the item in
without warning about the policy.
Now repeat, this time specifying a work item. Check your email alert you set up earlier, and note that no work item association is mentioned in the email. Click on the changeset link in the
email and observe in the web client that there is indeed a work item associated.
Now check out the same file again in Visual Studio, change the comment again, and check back in using the “Pending Changes” dialog in visual studio. Note you will receive a work item check in
policy warning, now select a work item, add a comment and check the file back in. Now jump back across to your emails again, note that you will have received the check in email of your changeset, but this time the associated work item is mentioned as part
of this email.