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
Related
I know this looks like a dumb question, but I just found out that, last month, something terrible happened to my GitLab instance: someone signed up on it and became admin himself, without my invitation, as I was the only administrator. So he wiped off every internal and/or private project inside of it, groups too (and I don't even know whether he had stolen all of them before erasing or not, I'm worried because they were proprietary code). How did it happen? Does this have anything to do with, since the version was CE-13.3.0? If so, would version upgrading be enough to be safer, or should I make some particular configurations, such as disabling sign up page?
It is best to follow "GitLab instance: security best practices", which does include indeed:
Ensure open sign-up is disabled on your instance.
Open registration is disabled by default on self-managed instances with GitLab 13.6 and above installed.
If new sign-up is enabled and your instance is open to the internet, anyone can sign up and access data.
Administrators who would like to further restrict access on their instance can follow our documentation on how to configure user access.
Regarding the CVE mentioned, follow also "Action needed by self-managed customers in response to CVE-2021-22205", in your case: "CVE-2021-22205: How to determine if a self-managed instance has been impacted" (unless the log events have been wiped out as well).
I've been given oversight access to an azure account for our business.
I'm trying to see if there is a way to view the latest code updates and history.
Is there a way to do that in Azure?
An Azure Account might not be enough for that. A Azure Website usually doesn't contain source files (there are exceptions e. g. plain html sites). They contain build artifacts / binaries that are build from the source files.
The code for your Azure Website is probably under version control. That means that your developer are using a plattform to commit the code. An example is Visual Studio Team Services (VSTS), GitHub, etc...
You have to get access to the version control system used by your developers in order to view the latest code updates and history.
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.
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.
It seems that security setup is a bit of a nightmare with TFS --- particularily as it relates to TFS versus SharePoint versus Reporting Services.
Does anybody know of a tool that can validate the security setup --- because as it stands now, people can't create projects, because something is wonky with SharePoint --- yet all the farm administrators and site collection administrators seem to be set correctly.
One thing to try is to create a new Team Project logged in to the TFS server (AT) using the account that you used to install TFS (tfssetup).
If that still doesn't work then sounds like you might possibly have your Sharepoint Admin URL set incorrectly in TFS.
One thing you might want to try if the TFS Best Practices Analyzer which comes with the TFS 2008 Power Tools and will point out common configuration issues.
You might also want to try the tfsadminutil ConfigureConnections /View command to see if you can see anything there.
Good luck,
Martin.