We're using team system to control our developement (product backlog items, sprint backlog items etc). It's a pretty nice tool but we wanted to allow other users to be able add bugs and new feature suggestions WITHOUT letting them mess with the actual development bits.
I can set these guys up so they add the work items they need but I can't see a way to block access to the bits I don't want them to edit/view. Has anyone else seen this? Has anyone found a solution?
Are you using TFS 2010? If so, you can simply add them to the Work Item View Only Users group. This will grant them access to create new work items and to view/edit any work items they've created (but not others). Check out this link for instructions.
Related
I use VSTS/TFS for work and side projects and I wanted to setup a trigger/rule that would automatically move stories into a certain iteration when I move them from "New" to "Approved" or whatever column is associated with an active state. I know how to change the iteration manually but it would be way easier if there was a way to say something like this psuedocode:
if (workItem.State == "Active") {MoveToIterationActiveForTodaysDate();}
Ideally too, if this isn't too picky, I would like it to only run on initial move so I can reassign to a different iteration later if I wanted to.
If anyone has an easier way to do this too that accomplishes the same thing (moving items to an iteration without having to manually activate the story and move it to the desired iteration) that would work as well. I'm still figuring out the ideal way to manage VSTS/TFS. Thanks in advance
Using VSTS is able to customizable work item rules.
Whether it be automatically setting the value of certain work item
fields or defining the behavior of those fields in specific states,
project admins can now use rules to automate the behavior of work item
fields and ease the burden on their teams.
More details please refer this tutorial: Add a rule to a work item type
However, it works with fields in the work item, not able to move work item to different iteration or area directly.
There is no out of box feature could achieve your requirement with TFS and VSTS for now. You may have to customize TFS events/actions to achieve the same feature as right click the work item--select move iteration--choose iteration.
Moreover, you could also use some 3-rd party extensions/tools such as Giulio
suggested TFS Aggregator.
As of today, there is no built-in automation, so the community wrote some tools that react at TFS/VSTS events and run scripts.
I can suggest TFS Aggregator which is used by many organization throughout the world: I am one of the core contributor.
I've allowed my Stakeholders to create Work Items but I would like to restrict them to only be able to create bugs and NOTHING else. Currently they can create ANY Work Item type including Epics... I'm thinking there has to be a way to stop this but I can't seem to find it.
There is no setting for this. And there is already a similar feature request submitted on VSTS User Voice: Hide Work Item Types (WITs) based on permission/security group.
Not exactly like this - How to publicly share a Visual Studio Online Repository? - I am trying to share the source code repository (Git) from Visual Studio Online to registered stakeholders. They need to get at the latest stuff at the Master branch to eval it along with work items. How can I do that?
Thanks.
If you have people with a Stakeholder license they won't be able to see the code. The Stakeholder license only gives access to:
View team dashboards and portfolio backlogs
View, add, and modify items on the backlog
View, create, and modify work items such as stories, features, and bugs
View, create, and save queries
Create and receive alerts when changes are made to work items
Submit, view, and change your feedback responses.
For people to see the code, they will at least need a Basic license. If you then want to restrict their access, you can do so by creating a TFS Group and setting the correct permissions. In this case, you want to limit the Code permissions to only Read so they can't modify the code.
See Permission reference for Team Foundation Server for more information.
This means there is no free way to allow users to read your code. You do start with 5 free basic licenses however, so if that's enough you can assign those to your users.
I have an existing team working on one solution using Visual Studio Online. Now I have to add new developer to work on one of the projects. Due to security concerns I have to hide other team members' contact details and ideally names as well.
How can I accomplish this?
You're not going to be able to have everyone working in the same team project and keep this information hidden. There are ways to minimize the avenues through which someone can see the information -- for example, you could isolate the one developer into their own team, so names/emails wouldn't show up on the team's home page -- but if they're working on the same code in the same repository, they'll be able to see things like commit history, which will definitely have identifying details attached.
We're new to TFS and have some tasks set up in Team Explorer. It seems the History pane is the right/best place to add notes/discussions (although it's very different from other tools I'm used to like bugzilla, jira, redmine)?
But how can we set it up so interested parties get notified of new comments on a task, preferably by email? We're all making it up as we go along with no prior TFS experience but I'd hope my experience with other tools (the project hasn't used a proper issue tracker before) would help me figure things out but it all seems rather confusing.
If you install the TFS 2010 Power Tools (this is removed for 2012 as it's setup in the web interface according to this link although I've not played with this in 2012), under Team > Alerts Explorer you can add alerts for email notifications.
It's pretty simple, you can get alerts for when work items are modified, created under a certain path, assigned to you etc, they are basically configured in a similar way to the work item queries so it's quite easy to setup what you want.
They can be setup by any users, so you might want to let your users setup their own custom rules as they like, then you logon as a generic user (such as your admin user) to setup team specific queries, or else you might end up with users complaining about getting emails no longer relevent to them or need changing, when the user that set them up leaves/moves etc... Else you'll be hunting round to find who setup the original rules.