We just moved to use TFS 2012 which seems to be a huge upgrade for 2008 in usability with VS2012.
However, there is a very annoying feature with "My Work" feature if you connect your work with a certain task. After you have connected the task with your work item, any checkin to any branch will mark the task to "done" status. How can I disable this? I'd like to have the development branch so that I can make small commits during development but with this feature I cannot connect the task with my current work if I do so. The only way to do this (which I know) is to select the task for my current work just before I merge all small commits from my personal branch to master. Yes this is doable but it isn't as nice workflow as it may be.
With taskboard feature in scrum template moving tasks to done after work is done is anyway trivial and common part of workflow. Automatic done movement is pretty annoying automation which shouldn't be there.
So my questions are: How to disable this? Is this feature part of template or some much more deeper integration with TFS work item management?
We are using Scrum 2.0 template from Microsoft.
When you are in the Pending Changes panel ready to check in your fix and you associate you work item with the changeset you should change "Resolve" to "Associate" (or what ever it is in Scrum).
To make this the Default is more complicated.
You will need to edit the Work Item Template definition for the types of work items you are using (Bug, Task, etc.).
One option is to remove the "Resolve" option altogether, you can do this as follows:
Open the XML for your Work Item Type (or the GUI in the Power Toys if you prefer):
Find and remove the:
<ACTION> <ACTION value="Microsoft.VSTS.Actions.Checkin" /> </ACTION>
section from your template - it will be in the <TRANSITIONS> against a particular transition between 2 states.
Doing this means TFS will never transition your work item as part of your checkin, you will have to do it every time.
The other option is to add a new work item "State" (e.g. "Under Development") that doesn't have an ACTION of Checkin. You can then transition you work items to this state whist working on them and then back to "Assigned" (or whatever) before checking them in in and "Resolving" them.
The Professional Team Foundation Server 2010 book from Wrox will help with WIT editing.
There are probably more ways to do this, it all depends on the team and environment you work in :).
There is also another way to do this that only affects your client machine:
To make “Associate” the default action (instead of “Resolve”), set the registry key
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction to False.
N.B. Replace 12.0 (for VS2013) with 14.0 for VS2015, 11.0 for VS 2012 or 10.0 for VS 2010.
Now you can upgrade to VS2015 (if already didn't do so) and uncheck the new checkbox Tools > Options > Source Control > Visual Studio Team Foundation > "Resolve associated work items on check-in". After that, "Associate" becomes the default option and you won't need to change it manually on commit
In Visual Studio 2015, this can be done by unchecking 'Resolve associated work items on check-in' in the Options menu.
Tools > Options > Source Control > Visual Studio Team Foundation Server
edits: typos
Based on the answer of DaveShaw and in respect to VS2022, my answer does not contain new information. But in case you are not familiar with RegEdit and you are searching for an automated way for the roll out, use the reg file instead.
create a registry file with name e.g. "AssociateAsDefaultCheckinAction.reg"
add the text below:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction "="False"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\13.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction "="False"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction "="False"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction "="False"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\16.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction "="False"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\17.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction "="False"
execute the reg file on the developers system
After that, restart visual studio and check the result.
The state “resolve” is no longer visible on check-in
Related
HELP. I accidentally deleted a bunch of xpages and custom control out of my database and have no backup. is there any way of recovering those elements?
Presumably you don't have source control enabled. If not, there's one way, best done on the same PC where each design element was last edited.
Create a brand new XPage with the same name.
Go to the source pane
Right-click and choose Compare With... > Local History
If it was last saved recently on that PC, you'll see the previous version.
For the future, I strongly recommend using Source Control and outputting to the On Disk Project and committing frequently to a source control repository. I did a session and a Notes In 9 a few years ago on source control and the Show and Tell slides on my blog (accessible from your favourite search engine) show how to install Redmine (courtesy of Declan Lynch) or Stash (courtesy of me). Alternatively BitBucket allow private repositories accessible for up to five users. This is one of those cautionary tales of why source control is relevant even if you're not working in a team. There are DXL rouond-tripping issues with some edge case traditional design elements, which is another reason I tend to keep my XPages UI in a separate database from my design (which has the views, forms, agents etc).
There is no undelete for design elements (or documents). Sure you don't have a backup somewhere?
This is where source control is handy...
Sorry...
I'm having fun deploying some solutions to my SharePoint 2013 Foundation Edition. I'm checking out some eLearning Solutions, currently the SharePoint Learning Kit (SLK).
The solution comes with 3 Features:
SLK
SLK - Assign Self
SLK - Assign to Site
I guess I need the "SLK" Feature to activate the Solution but if I activate the other two features, I dont see any differences.
Can somebody tell me if I need to activate those two, that the solution works and what they are there for?
Thanks in Advance
-DaveTheMave
To simply answer your question - No, you don't need those 2 additional features, the SLK will work perfectly without them.
I don't have them activated myself.
Here is what the do:
Assign Self:
This feature add the "Assign To Self" menu item to document libraries. This allows the user to immediately assign an item to themselves and run it.
Assign to Site:
This feature add the "Assign To Site" menu item to document libraries. This allows the user to start assigning an item to the current site without having to choose the site to assign to. In effect it jumps straight to the Assignment Properties page for the current site.
As you are new to the SLK, I can highly recommend you this YouTube Tutorial on "how to get started with SLK".
We have a complex scenario which requires a timer job to run after content deployment to a SP 2010 site collection. The timer job automatically deactivates/reactivates a branding feature which is responsible for setting the master page for the site collection, among other things.
We have had several feature upgrades along the way, and neglected to call .Update() on the feature in that specific site collection. So all of the updated CSS, master page, page layouts etc. are out of date on that SC.
The strange part is that when I checked the version number of that feature in this SC, it shows as the latest version. The custom upgrade action clearly didn't run and update the files, because nobody called .Upgrade().
One of my colleagues suggested that the deactivate/reactivate process done by the timer job would update the version number, meaning that I can no longer call Upgrade()!
Is that true? Does a deactivate/reactivate cycle for a feature automatically update the feature version number?
Is there an easy way to fix this mess? Some way to decrement the version number programmatically, then call Upgrade()??
On 1: No. Feature deactivating / activating does not trigger an update. See this article by Chris O' Brian: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html
Feature upgrade does NOT happen automatically (including when the
Feature is deactivated/reactivated)! The only way to upgrade a Feature
is to call SPFeature.Upgrade(), typically in conjunction with one of
the QueryFeatures() methods. My tool which I’ll go on to talk about is
a custom application page which helps you with this part – note there
is no STSADM command, PowerShell cmdlet or user interface to do this
out-of-the-box.
Is your timer job cycling the feature activation with Force? Then, yes, it is triggering the feature upgrade/feature update see the following screenshot from SPFeature.Activate (see my yellow marking):
Why the feature version is incremented, I'm not sure. When you have a feature, install a new feature version and activate / deactivate, the feature version stays the same unless you run an Upgrade, see also this related question stating the same: https://sharepoint.stackexchange.com/questions/41476/feature-upgrading-question
I'm guessing your timer job is using force? Otherwise I'm not quite sure what is happening.
On 2: Don't know if it is possible to decrease the version number, but the safest way would be to just create a new version including a grand "clean up" feature receiver which sets everything correct, i.e. checks which steps of the feature upgrade have happened already (e.g. new list created, new content type added) and which haven't. Depending on that just execute the same steps again which have not executed yet. For the latter part you can fortunately use the existing code, so you would only need the "clean up" or checking code.
After some testing I found that simply deactivating and reactivating the feature will increment the version number and completely screw up your upgrade! I even watched the update come through in the content database. As soon as you deactivate/reactivate the updated feature, the new version number pops into the content DB. Of course the upgrade doesn't actually run, it just increments the version number.
This means that if you then call .Upgrade() it won't work because SharePoint thinks it's already been upgraded!!
To fix this I updated the row in the content database to set the feature version back to 0.0.0.0 for that particular web and then I could run .Upgrade() just fine....but that's not exactly a supported solution. If anyone else has a better idea drop a reply.
I am working with Visual Studio 2012 paired with TFS 2012. Right now I am building a custom workflow template and need to run an if statement to separate two invokeprocess's. The condition for the if statement needs to operate off of which build configuration I am running, I want it to operate like this C code:
if(Configuration == 'Debug')
{//run for debug}
else if(Configuration == 'Release')
{//run for release}
My problem is that I can't find any documentation or help as to how one would go about creating a conditional in workflow, and how I can use my build configuration as a value in this conditional. Hopefully a straight-forward question that someone has some insight on, if any clarification is needed please let me know! Thanks!
To answer your basic question about an "if" in a workflow, open the worflow xaml file in the designer. Go to View > Toolbox. Under the heading "Control Flow" there is an "If" activity that you can drag and drop into your workflow.
A workflow can have multiple projects and solution being built in multiple configurations. The workflow contains an argument, BuildSettings, which has a property called PlatformConfigurations. The default template will loop through all PlatformConfigurations for all projects in the "Compile and Test" sequence. You may just want to grab the platformConfiguration variable in that loop and get the Configuration and put the if either before or after the MSBuild activity or you may need additional logic for specific project you want to act on.
We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.