trouble again with Team Foundation Server Power Tools 2012. I just installed VS2012 and the power tools. We use check in policies. My problem: when I associate a ticket with a check in (as my policy demands), the ticket is set to 'resolved'. I don't want this behaviour, does anybody know how to change it?
thank you
You should be able to use the process editor included in power tools to make that change.
Here is a blog post detailing several ways to make this change:
Changing the default Check-In Option
Check the WITD of the ticket (work item).
The XML will have Action="Check-in" under the transition "Active" To "resolved". Remove this action. That's it.
Related
As I understand it, the TFS Changeset Comments Policy may be set by any permitted user to require all team members to add a comment when making a check-in. Clearly, this must be a setting on the TFS server, rather than a local setting on the machine of the developer who makes the change. Yet my reading on this indicated that a curious notion. Prior to VS2013, this policy was not bundled with Visual Studio; rather it was in the Productivity Power Tools (PPT). Various references all indicate that each member of the team had to have PPT installed in order for the policy to be effective. One source wrote it as "if you don't have the Power Tools installed, you can still override the check-in policy". But if this is indeed a server setting, how would one be able to override it? That's part 1 of my question.
Part 2 of my question is now, with the advent of VS2013 that has the Changeset Comments Policy packaged in, I presume that the policy will just work. But what happens if there are some users running VS2013 and some running VS2012--does the same limitation still exist, i.e. that the VS2012 users with PPT can still override the check-in policy?
In TFS the checkin policies requirement are server side, but the checkin policies them selves are client side. So for users that don't have the checkin policy installed this policy will always be not fulfilled. the Comments policy is no exception. When you don't have the policy available on your computer you will just get a more cryptic failed checkin policy.
This goes for both standard/bundled policies and custom made policies. Note that you can always override failed policies. There is no way to refuse the developers the option of overriding, even for missing policies.
As a side note I can say that tfs power tools has a feature that allows for automatic distribution of checkin policies. But then you of course will have to make sure that all developers have tfpt installed. for TFS/VS2012/13 this feature might be included, but I'm not sure. You can have a look at this blog post if this is relevant
http://blogs.msdn.com/b/youhana/archive/2011/03/27/distributing-custom-check-in-policies-amp-wit-controls-using-team-members.aspx
Does anyone here know what could cause a new feature to not show up in the SharePoint UI?
The solution it is part of has been correctly deployed to the GAC and shows up in the central administration list of deployed farm solutions, the feature appears in the FEATURES folder of the 14 hive, yet the feature itself does not appear in the features list for the site collection, either in the UI or in PowerShell using Get-SPFeature.
Yes, the feature is correctly scoped, and no, it is not hidden. :)
Any thoughts or pointers would be very welcome!
Answer supplied on sharepoint.stackexchange.com, with thanks to Simon Doy. https://sharepoint.stackexchange.com/questions/73871/sharepoint-2010-feature-not-appearing-in-ui
Somehow, something had gone wrong with the installation of the feature, and neither the UI nor commands like Get-SPFeature revealed its existence, although the Install-SPFeature -ScanForFeatures command emboldened below displayed the missing feature.
"Check that the feature has been installed. For example, if you are
performing Update-SPSolution and a new feature has been added between
solution deployments then the feature is not installed by default.
To check do the following:-
Run SharePoint 2010 Management Shell from one of the SharePoint
servers Type Install-SPFeature -ScanForFeatures This will show you any
features that are available in the SharePoint Root but have not been
installed. You can install any missing features using the command :-
Install-SPFeature -AllExistingFeatures
See the following TechNet
Article for more information.
http://technet.microsoft.com/en-us/library/ff607825(v=office.14).aspx"
Look in central admin to see what site collection the feature is deployed to. Make sure in that site collection the feature is turned on.
Also, check the deploy job status to see if it actually finished.
Is there a on install event receiver? If it errors out, the feature will not finish installing even after the DLL is copied.
Is there a way to export all of TFS 2008 Groups and Permissions for an Audit?
I looked at the TFS Permissions Manager mentioned in another answer and couldn't easily figure out how to use this for an audit of user permissions. That said I looked around and found a few other possible tools to help in this process:
Team Foundation Server Administration Tool - This can be used to produce a list of TFS groups, users & permissions on a per project basis. The utility uses a grid control to display the results and this can easily be copied and pasted into Excel, etc.
TFS Project Audit - This tool generates output in an indented text format. It too works on a per project basis however it lists the output grouped by TFS role.
I think both of the options I mention are more recently maintained than the TFS Permission Manager at the time of this writing. Also, keep in mind that for purposes of a security audit I believe that the local & domain administrators groups in Windows Server have the ability to override any of the TFS permissions (at least with TFS 2008).
I'm the guy who wrote TFS Project Audit and I'd like to clarify a few things about my tool. First, it works on a project basis for TFS 2008 or a collection basis for 2010. It can report on a specific collection or all collections on a TFS server. These are enhancements I made in the newest version, released only a few days ago. Also, the output can be restricted to a specific group, Project Administrators, for example, across a project, collection, or the entire server.
I am always soliciting but rarely receiving feedback on this pet project of mine, so please feel free to leave suggestions for future releases! I have plenty of ideas in mind but it would help to know where my time is best spent, because this projectis hardly all I do with my days.
To prove it is really me, I'll give Saul a shout at tfsprojects.codeplex.com. Thanks a lot Saul!
Have you looked at this?
http://blogs.microsoft.co.il/blogs/srlteam/archive/2006/11/27/TFS-Permission-Manager-1.0-is-Finally-out.aspx
We have a number of database driven apps we'd like to build out within SharePoint 2007 (the data will need to stay within SQL Server and not SharePoint). Can anyone recommend some robust visual tools that support doing this within SP 2007, but also allow for business rules such as "if the user is in this group then they can see this, if they database value = this then show this, but not this and don't let them edit this."
Any thoughts would be appreciated.
Seems like a job for Forms based authentication here (SqlMembershipProvider), combined with audiences / SP usergroups. Most can be done through the Web UI... Not really seeing the relation to workflows here.
I applied the MOSS infrastructure upgrade w/o applying the WSS one before it -- uh, help!
Quoting:
Infrastructure Update for Microsoft Office Servers (KB951297)
Other Relevant Updates It is strongly recommended that you install the Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) before installing this update on any of the Office Servers listed in the system requirements section above.
Therefore not applying first Infrastructure Update for WSS seem to be not recommended but not unsupported
I believe that is a supported, but unrecommended configuration. You should be able to get help from microsoft :)
I am assuming that you have also run the Configuration wizard after you applied this and brought your system online? If you have not, you are in a much better position, as you can apply the WSS upgrade - then run the wizard and you should be fine.
If you have run through the wizard - and brought the system back online - its not the end of the world. What you will want to do - is go back and follow the steps to upgrade your system just as if you had not done anything. The infrastucture update makes some significant changes and improvements to portal search - so once you start trying to configure that, you'll see some errors in crawling etc - as the indexer (which has been updated) tries to crawl content (which has not).
Apply the WSS bits, then reapply the bits for MOSS, then run the Config wizard and bring everything back. You should be okay at that point.
Obviously, before you do anything, backup all systems and take them offline.
Hope this helps.
Sounds like time for a full restore. The MOSS upgrade steps did explicitly ask for a restore, didn't it?
The TechNet article Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007) has a dicussion on this in the community content section. Someone commented that the WSS update must be run first. There is no suggestion for what to do if you don't or what the consquences are.