Is it possible to add an extra field to the TFS check-in window?
I'm not searching for an extra field on the product backlog item, but a field for a certain value that i would upload to another app when the check-in occurs.
Assuming you're using TFVC, the answer is yes, they're called Check-In Notes.
That just handles the "adding an extra field to the information gathered during source code check-in", however. Actually triggering a down-stream event and retrieving that value will require using service hooks and most likely the REST APIs to retrieve the check-in note value from the changeset. I'm not sure if check-in notes are surfaced by the REST APIs or not -- if they're not, you'll end up having to use the old-school SOAP APIs.
Related
We use TFS2013 on premise. A request came up that when using Web Access, some members with Stakeholder access should only have limited rights when opening work items.
They should be able to edit Description, Acceptance Criteria, etc fields, but others should be read-only, such as Iteration, State, etc.
The only option I saw was about tags Create tag definition option under
Security >> Permissions, but that's not enough for me.
One idea was Customizing a process template, but this seems to be thin ice as our team doesn't have any experience with it and the things to avoid list is quite long.
The best workaround approach so far is to reference the TFS ClientLibrary from Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\ and create a custom website which implements only the required features (for example when opening a work item, State would be a Label instead of a DropDownList).
The drawback of this solution is that it would keep the whole WebAccess portal hidden, including its nice features.
So my question in short: is there a way to make certain fields read-only on the work item form for stakeholder members?
UPDATE
Eventually I went towards Template Customization using TFS Power Tools 2013. Now I have to following problem:
Applying rules for certain fields work just fine, but in case the field type is TreePath, saving the template gives the following error
TF26062: Rule '< READONLY for="[Global]\Stakeholders" />' is not
supported for the field 'System.AreaPath'.
There were validation errors. Continuing to save may cause the file to
become unloadable, do you want to continue?
According to this answer from 2009: "there are some particular fields which can't be applied rules for"
Any suggestions how to go on?
You can choose the work item types to make some fields read only.
You will never need to be careful to not mark field read only that are needed for adding items. That would include area and iteration. Use witadmin.exe to export the desired work item and add read only clauses only for those in the stakeholder group.
You would be better with a permissive model. Allow everything and tell them what bout to change. Then have an alert for changes to those fields by stakeholders.
I'm customizing the Work Item Definition Schema for the 'task' work item in TFS Server 2012. I've created a new field for hold a CustomerReference value. It works as I expected, but I would like add a UNIQUE restriction for security. I'd like add a rule than it makes imposible create two workItems with sme CustomerReference.
I think that none of the rules defined here http://msdn.microsoft.com/en-us/library/cc339553(v=vs.90).aspx achieve my target.
Any idea? Thanks in advance,
As a last resort there is a way to write a custom plug-in that can enforce this server-side. See this link for more info on creating an ISubscriber plug-in: http://nakedalm.com/team-foundation-server-2010-event-handling-with-subscribers/
Unfortunately, the plug-in model doesn't allow you to prevent changes; but it could allow you to detect when somebody has violated the rule and react. For example, it could send an email off to somebody, and possibly clear out the CustomerReference field from the duplicate.
is there a way to hide the content of a field based on a role?
I thought about creating a serverside plugin which empties the field if the user does not have permission to view the field and repopulate it on save. But I don't know how to do this, I did not find any event which I could use. Any idea?
My first intent was to use the EMPTY rule but this really clears the content and does not repopulate it. Also the READONLY rule is not acceptable for us. Do you have any idea?
I know this was already requested http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2088177-add-ability-to-hide-mask-fields-in-a-work-item-bas but I need the functionality now.
I also thought about creating a workitem where the hidden fields are stored in and linking it to the other work item but this is not the solution I want ...
The only way to do this is by creating a custom work item control. That control can then only display the contents of the value if the user has the correct permissions. What it does not prevent though is to see/update the data via other tools like Excel, Work Item Query or Bulk Update.
As the suggestion on User Voice suggests, it is not possible today in TFS. So please vote and make sure the Team Foundation Server team knows it is high priority for a lot of our customers.
Ewald Hofman (Program Manager, Team Foundation Server)
In VS 2013 when u use the Empty Rule, the field disappear! You can see that in Scrum Template when you change de WIT state to Done the Remaining Work field are hidden
Does TFS 2010 have the concept of checking out work items and checking them in. This action would lock the item for edit by other users while it is checked out.
I know I can do this for files under source control, but what about regular work items?
I haven't yet come across any documentation around this. If it's possible, does someone have a code sample?
That is not possible. In TFS11 we have added 'merge on save' so there are less conflicts when saving a work item.
Would love to know why you want this feature though.
You could achieve a lock mechanism on work items if you write a custom control that allows or denies saving based on the result of some query you make to a custom service.
You would want to create a visual studio plugin that sets and resets the lock per work item.
While you're at it, you could write a server plugin that persists a serialized copy if the work item to disk or to the version control system.
I know it's a lot if work, but it should give you what you asked for.
You can limit "Check-In Policy" rules via the "Custom Paths" policy. But the "Check-in Notes" tab doesn't seem to fit in to the same system. Why isn't "Check-In notes" just another "Check-In policy"??
I'm using Team Foundation Server 2008 SP1
We had a similar problem some time ago. For some sub tree we wanted to require entering a code reviewer. I ended up implementing a custom policy and used the Custom Path Policy to restrict it to certain folders. That works well, except that you have to deploy your policy assembly and TFS has no built-in mechanism for that, yet.
That's an interesting question - the short answer is you cannot.
I have ran into the issue myself a lot where people get check-in notes and check-in policies confused because, while very different in implementation on the server, they often serve similar purposes.
Check-in notes are bits of structured meta-data that you want to collect on every check-in to a Team Project. They can be thinks like who was the code reviewer or a reference to a ticket in an external CRM system or something. You can make them required, or just have them defined for people to optionally fill out.
Check-in policies are bits of code that run on the client at the point of check-in that get a say if the check-in should be allowed or not. These are useful for checking things like you have associated a check-in with a work item, given it a comment or the code you are check-in in passes certain key static code analysis rules (such as basic checking for SQL injection attacks etc). If a check-in policy fails in the evaluation of the check-in then the user gets alerted and they get the ability to fix the problem or check-in anyway with a check-in policy override than can easily be reported on or alerted for by the TFS administrator.
Both check-in notes and check-in policies are defined and scoped at the Team Project level. However, Microsoft got feedback that some people would like check-in policies would like to be applied to specific paths in version control rather than just the Team Project and so the Custom Path Policy was invented.
The Custom Path Policy is a bit of a hack that allows you to wrap check-in policies inside the custom path policy. The custom path gets evaluated on every check-in and if it contains files inside the defined path then the wrapped check-in policies are evaluated for those files. The Custom Path Policy ships in the TFS Power Tools and is not part of the "Out The Box" TFS experience.
So, to answer your question a different way - I suspect the answer is "because that's the way it was designed and not enough people have asked for it to be changed".
If you wanted to leave feedback at http://connect.microsoft.com/VisualStudio I know they take customer feedback very seriously.