I have written a Sharepoint workflow that starts automatically when an item is created. It has two stages. The first stage sets a yes/no field to yes. then transitions to stage 3(Got rid of stage 2). The workflow gets stuck in stage 1. Any ideas?
The workflow might require the item to be checked out before it can update the yes/no field.
It would helpful to know what version of SharePoint you are running, along with how the workflow was created, (e.g. Designer or Visual Studio)
Related
I need to change the destination of an SSRS report in Visual Studio 2010 so that when I deploy it, it goes to the correct folder. There appear to be about 6 or 10 places where I can change options, I just cannot seem to find the right place to change these deployment options.
On this particular report, there are two subreports. I would like to deploy these two reports to a separate (subfolder) under the folder which contains the main report. I assume that the changes I make in #1 are for SSRS, not for a particular report (is that correct). If so, I will need to change the path for those subreports as well.
Once I have the reports deployed to the correct folders, how do I change the path to these subreports in the Visual Studio report designer? Right now, the reports render properly in the report designer, but when I go to the report server and run the main report, the subreports do not render properly.
I expect this report, along with its sub-reports to render properly from the report server.
You can only change the deployment path in the project properties, so this affects all reports. I did try to setup a similar scenario to what you want bit to be honest it was more trouble than it was worth.
What I ended up doing was having all subreport names start with an underscore and then running a quick bit of t-sql to hide them. I don't have access to the server now but the t-sql is something like
USE ReportServer
UPDATE dbo.Catalog SET Hidden = 1 WHERE LEFT(Name, 1) = '_'
The other way you can do this is to dump all the reports in the same folder but don't give users access to it. Then Create a new folder and add linked reports in there that point back to the original versions, you can do this using the Web Portal (report manage in older versions). It's a pain as you have to do each report individually. You could probably write a script to create the catalog items for you but I've not tried that so can't comment on how easy that would be.
So, saving the subreports to a different folder was straight forward, once I figured out where the project properties were located. Once I deployed those to subreports, all I had to do was change the path to those subreports in the design view of the main report.
Right click on the sub-report, select subreport properties and enter the full path to the sub-report.
I have several checkins related to a single work item. Is there a way to get a summary of all these checkins, so I can see the difference between files before I've started working on them (like, at the moment of changeset A), and their final form (changeset B)? I would use View history and compare the folders of changeset A and changeset B, but that will give me lots of diffs that were made by other people in different files that are of no interest to me.
Edit: As suggested by Patrick-MSFT, I tried to use TFS Sidekicks, but for some reason I don't seem to get any result whatever combination of filters I use.
You can achieve this by using TFS Sidekicks. You can search for your single work item and it will give you a consolidated view.
Install sidekicks for your relevant TFS version
Open side kicks and connect it to TFS (usual tfs dialogue)
Click Tools -> Code Review Sidekick
Click by Work Items and select the appropriate Project and Query (TFS explorer workitem query). Alternatively, you can search by
changesets
Select the appropriate work item.
This will show all the changes for that work item
In your case , you want to compare all of the changes to a file,
from its state before the first checkin of this workitem and the
last checkin of the workitem (collapse all of the changes)
enter code here
Right click the file you are reviewing, the one associates with the
highest changeset number, and select 'compare with previous (not in
view)' This will show you the complete difference in your VS configured
diff tool.
Note: If the file is new and has multiple checkins, select the
one with the maximum changeset it, and select 'compare with oldest
in the view'
You can use tf difference command to compare the changes between two changesets for a specified file.
tf difference /version:669~672 program.cs /format:Context
I don't want to use only Tasks in TFS Some times a Bug or a backlog Item are so small that there is no need to create tasks underneath it. HOw do i automatically make it Mark the Item as done in tfs when i check it in.
There is no way for me to make it relative in this case. Because it is a backlog Item as opposed to a Task.
Does anyone have a way to make this work?
If you use visual studio to checkin then it asks for a comment and a work item to associate with the checkin. There is a area where you can provide the state of workitem as Resolve or Associate after this checkin happens you can put the state to resolve it would mark the item as done.
I've created a new iteration in TFS 2010 and wan't to use it in a new story and query.
However, the iteration won't show up in the new story window, refreshing VS, restarting VS, switching to other project, nothing helps.
I'm a project administrator in the team project, and created the iteration with the same user that i'm trying to use it with. Permissions are not changed from default.
Tested on other workstation with other user with sufficient permissions also doesn't help.
Could I be doing something wrong?
Make sure "Team Foundation Background Job Agent" is running on the server hosting your TFS instance and it is running under a service account. See http://msdn.microsoft.com/en-us/library/ms252450.aspx for more information.
A little bit late but we encountered the same problem.
I tried to restart the "Team Foundation Backgroud Job Agent", without any effect.
But I found a solution, although I am not sure if it is a bug or not.
We are using the Scrum Template for this project, and I have not checked this with any regular Project Template but I quess it is the same. First add the desired new iteration by right clicking on the TFS project and selecting the "Team Project Settings" -> "Areas and Iterations...".
On the Iteration Tab, we have now 2 iterations (at least in our case) with multiple sprints within these iterations. You can add a sample Iteration if you have only one Iteration
After moving the new Iteration downwards, so its new position is beneath the existing Iteration, I was able to see and select the new Iteration in my Team Query. If the new Iteration is already beneath another Iteration, simply move up the new Iteration
This may be a bug, or the use of the Scrum template might interfere with any sync process but the above method worked for us.
In my situation this was caused by an alphabetization issue. In my Iteration Setup I added '2.11' at the bottom of the iterations and then looked in a Work Item and couldn't see the new iteration.
Turns out the work item template was sorting alphabetically and not obeying the Iteration setup. So my iteration was always there, it was just between '2.1' and '2.2' instead of where I expected to see it.
Is there a way to Link a WorkItem to a Label. Under "All Links" when I create a new WorkItem in Visual Studio I can select many diffrent Link Types, like Changeset, VersionedItem, etc, but theres no type for Label.
The reason why I want to do it is, that I label my releases (like Version 1.0, Version 1.1) and I want to associate a Bug to a specific version of my software.
Isn´t it support to link a WorkItem to a Label or how should I associate a Bug to a version of my software?
Update:
I´m following the Single Team Branching Model (one Dev and one Main branch) documented in the Visual Studio TFS Branching Guide 2010.
You cannot link to a label. However you can achieve your goal in other ways.
First of all, I suggest to use branching instead of labelling to keep track of multiple released versions. In my opninion using branches is a better mechanism then labelling. See also the branching guidance on codeplex
To link your bug to a version of your software, use the Iteration Path in the work item. This field is exactly for that purpose.
Using iteration path field is one option and it gives you the ability to track a work item between versions.
But if you want higher resolution, there is another way:
Team Build marks source code with a label before every build. The bug item type in CMMI project template contains fields called "Found In" and "Fixed In". In these fields you can select from build labels.
Use of these fields allow you to mark any work item with two specific builds. One for when it was found and one for when it was fixed.
Additionally Team Build updates "Fixed In" field of every work item with the label of the build, after the build completes successfully and all tests are ran without a problem.
If you don't have these fields on your work item type, you can always add them using the work item template editor that comes with TFS Power Tools.