Within Azure DevOps Server, is there a way to limit the work items that can be tied to a given pull request to only those in the current project? Currently, when submitting a pull request Azure DevOps Server suggests and allows all work items within the project collection to be selected.
Yes there is a way to limit the work items from another project to be selected in current project. You can change the View, create, or modify work items Permissions within an area path. Check Restrict access to view or modify objects
So Let's say there are Project A and B. And Restrict work items in Project B to be selected from Project A. In order to achieve this, you need to set the permissions from Project B. Please refer to below steps:
1,Go the Project setting for Project B --> Click Project configuration under Boards --> Click Areas -->Click the 3dots of the root Areas of Project B --> Click Security
2, In the Search Box search for Project A team(or any team that includes all the users in Project A, if there isnot one, you can create a team in project A to include all the users.). Then set the permission to View work items in this node to Deny.
Then any user in Project A team willnot be able to add the workitems from Project B in a pull request.
Above steps will cause some problem if a user is also in other project team. But you can override the inherited permission for this user by following step 1 to allow the the view permission for this user.
If there are many projects in your collection, you have to set repeat setting above permission for each one of them.
However you can submit a feature request(click suggest a feature and choose Azure devops) that restricting view workitems permission in a Project Level to Microsoft Development team. Hope they will consider implementing this feature.
Related
I am looking for some guidance on how to best setup Azure Devops where multiple project teams can submit work requests to my team. My team would review the work request, size it up, enter the implementation date, etc...the other teams can view status updates once my team completes sizing up the request. Those requests would then be moved into our main Board to initiate dev work.
Here is a summary of the current process in place:
Other project teams would submit an intake request through a
sharepoint form.
My team would review the intake request, size it up along with any
other necessary info.
My team would than open a PBI in TFS with all applicable info from
the SharePoint intake request.
Complete the work and update the status to "Done" in TFS.
Go back to SharePoint form and update the status on the intake
request to Complete.
Notify the other project team that work is complete and deployed,
etc...
I'm looking to consolidate this process completely into ADO. My teams board should not have access to edit by other project teams. Perhaps something like a PBI can be opened by other project teams with a specific access to a limited number of State/Status options? This way my team can segregate PBI's by State (Status).
Any recommendations on the best approach to handle intake requests and consolidate everything into ADO with permissions in mind would be be appreciated! I'm open to different ideas.
The rough approach I would take uses area paths to control visibility. Under Project Settings -> Project Configuration, Areas tab, ensure that two area paths exist for your team: one for work intake from other teams, one for work tracking for your team (this may already exist if your project team has already been created).
Then, edit Security for the intake area path (options drop down for each area path). Add each other project team AND your project team, with "Edit work items in this node" set to "Allow".
Then, edit Security for the work tracking area path. Add each other project team, with "Edit work items in this node" set to "Deny". Your team should have "Allow" access here.
Your workflow then becomes that external teams will contribute work items to the intake path, and your team changes the area path to your work tracking area when it's time to prioritize and work them. External teams should be able to see the board, but not make modifications at this point.
I have an Azure DevOps project with a single team called "Software". Looking in Project Settings -> Team Configuration -> "Areas" tab, I can see that this team owns a single area - the "top-most" item in the project's area hierarchy, let's call this area "ProjectX". This has numerous child areas, which we use to categorise work items.
I have just created a new team called "Stakeholders", and a new area has been automatically created as part of this process, which this team now owns ("ProjectX\Stakeholders"). Am I right in saying that members of the new team will still be able to view and edit work items anywhere in the "ProjectX" area hierarchy? If so, what's the point of creating different teams?
What I'm trying to achieve is to allow members of the "Stakeholders" team to create new WIs and subsequently view/edit/delete those WIs. WIs created by members of the "Software" team should be completely hidden from the Stakeholders. Note also that the Software team needs to be able to edit/delete WIs created by the Stakeholders. Is any of this possible?
Am I right in saying that members of the new team will still be able
to view and edit work items anywhere in the "ProjectX" area hierarchy?
Yes.
If so, what's the point of creating different teams?
Each team will use each own product, sprint backlogs, and etc. As example: Configure Azure Boards to support SAFe.
What I'm trying to achieve is to allow members of the "Stakeholders"
team to create new WIs and subsequently view/edit/delete those WIs.
WIs created by members of the "Software" team should be completely
hidden from the Stakeholders. Note also that the Software team needs
to be able to edit/delete WIs created by the Stakeholders. Is any of
this possible?
Yes. You can use the Area Path Security to manage access to work items under different paths: Set permissions and access for work tracking
Currently we're only really making use of Project Collection Valid Users and Project Collection Administrators default groups in Azure DevOps but is unlikely to stand up to scrutiny an there's been a few requests for tweaks to this.
1 - Give 'standard users' access to view and work on only their projects but with the capability to create projects
2 - Give someone access to see all projects but not be able delete any existing ones (unless they're the project admin) or to be able to create new ones
As far as I've been able to tell I can't give someone permissions to view all projects without them being a project collection admin, and that means that they can create and delete projects which I don't want to provide.
Is there any way of overcoming this? The only thing I can think is I'd have to add this new permissions group to every project manually, which would be fine for a point in time, but I wouldn't be confident of adding the group to all projects, and it would likely go out of date when new project sites were created. I'd assume there's got to be a simpler way, and I may be overcomplicating things so thought I'd ask for some support.
Sure, you can accomplish this.
It'll take a few new groups and a new group rule within your Organization settings though.
To start, you'll want to create a 2 new groups within your Organization Settings > Permissions:
Project Creators: "Allow" - "Create Project"
Project Readers: No explicit permissions
Then, head to Organization Settings > Users and select the Group Rules tab. Within your group rules, select "New Group Rule".
Choose your Project Readers group within the "Azure DevOps or AAD Group" setting, select the default access level, select all projects, then choose "Project Readers" for their access level:
For a more step-by-step walkthrough on creating group rules, here's Microsoft's documentation on Group Rules:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/assign-access-levels-by-group-membership?view=azure-devops&tabs=preview-page#add-group-rule
I am evaluating Azure Boards / Azure DevOps and I wish to restrict what a Stakeholder (in this case, a customer) can see and do.
I have managed to limit what a Stakeholder can do, but is it possible to completely hide the Pipelines, Artifacts and Project Settings panes from Stakeholder?
Se the image. I want to completely hide the panes marked in red.
Image of panes to be hidden
I am not sure if we can show/hide the DevOps Services in top-level, based on a specific role. This is only available for the project level.
https://dailydotnettips.com/turning-azure-devops-service-on-or-off/
and these settings can only be controlled by the Project / Org administrator.
We cannot get rid of the Pipelines from the view for the stakeholders. Yes, we can turn off the pipelines service from the project settings overview page, thus the pipelines node will disappear from the view. However it's applied to entire project, that means all other users also cannot see the pipelines.
As a workaround you can manage security for all pipelines and Artifacts for each project, just deny all of the related permissions for the stakeholder.
In addition, I found a related suggestion ticket, you can follow and vote this ticket to get the latest news.
Is it possible to add members in bluemix track&plan with read-only access?
I want to limit the number of people who can add/modify work items into my project.
I understand your question that you want a more fine-grained access control for project members.
Can you not allow project members to edit work items? A short answer is no.
Check official website: https://hub.jazz.net/docs/projectadmin/
Project members have the fewest privileges and responsibilities. They can do these tasks:
- Add and edit work items
- Create Git branches for Git projects
- Create tags for Git projects
- Push and pull source code from the repository
- View and edit pipelines
- Add, edit, delete, and run pipeline stages or jobs
I think project members should have the access right to edit work items.
Bluemix track&plan is based on RTC(Rational Team Concert). I've been using RTC for team's project development for several years. It can be disturbing when someone removes a tag used in a query or changes work item to an incorrect status.
But the essence of track&plan is for team collaboration. Work item is critical to provide transparency and real-time status. Everybody on the team should have the right to add comments to the work item. My best practice is to use daily scrum meeting to review team dashboard and validate the work item status.
In real life, I seldom see team members deliberately update work items that don't belong to them. Instead, scrum master needs to motivate team to provide more update to the work items.
If you want to share the status to a stakeholder who's not in the project team, one doable option is to set your project as "public".
Try to access the link I created: https://hub.jazz.net/ccm51/quickplanner/jazzhub.html#items:projectId=_9b859SQ7EeesKZSRjqyxIQ&serverId=hub.jazz.net&planType=allwork&allIterations=true
Steps to set up your project as public:
1. Navigate to the Track&Plan dashboard. Click "Settings" icon
2. De-select "private" project checkbox & save