I have created a new Team/Area under our project within Azure DevOps.
When I send the URL for the backlog, the team members are able to access the link but not see any of the work items.
I have tried the following:
Confirm the user has Basic licence.
Confirm the user has access to the project.
Added the user to the Team for that area.
Is there anything obvious I am missing?
I am pretty confident this is not a bug, but just something in the process of giving users access that I am not doing.
Any help very much appreciated.
Thanks,
Alasdair.
When I send the URL for the backlog, the team members are able to access the link but not see any of the work items.
This could be caused by multiple reasons which means we might need to check several setttings.
Choose the right team in BackLogs page:
check the Project Settings-Team configuration-Areas, make sure the target Team area has been added:
Check Project Settings - Permissions and make sure your team has
the right permission to see the BackLogs Itmes.
Is this something that I need to set every time I create a new team?
No, you don't have to set them every time. When you create a team,
the Permissions setting could be automatically inherited:
Related
I can view all features except Release pipelines which is showing empty screen for me as shown below. I have tried different browsers such as Google Chrome and Microsoft Edge, both showing empty screen. I have verified that I have full access permissions and Visual Studio subscription also. Let me know if you ever faced such issue and a solution for this. Thanks.
You could troubleshoot this issue by checking following steps.
Go to Organization Settings>>Users page to check if your access level, make sure that you are not StakeHolder.
Go to this Project Settings>>Permissions>>Users tab to find you, and check which groups that you belong to. Usually members of Contributors group can freely access to releases page.
Check if others in the same group have the same issue, or just you have this issue.
Try this in other computers to check if there are some plugins or extensions which cause this issue.
If you are behind firewall or proxy, please check if the requests are blocked. You could click F12 to check the browser network requests.
BTW, we find that there are service events, which might causes this issue, you could monitor it.
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'm trying to create a team that can only see a subset of the boards (e.g. their own area), which is to act as a communication channel between the development teams and other users; meaning, the developers can see/interact with all boards, but the external team can only see/interact with one specific board. But it seems that any team created gets access to the main board no matter what.
Has anyone attempted this before?
You need to configure the area security setting for the team.
Go to Project settings-->Project configuration under Boards-->Areas-->Select the Area which you donot want the team to view-->Click the 3dots-->Security See below screenshot.
In the security setting page-->Search the Team in the search box-->Deny the view and edit permission of this node for this team. See below screenshot.
Repeat above steps to deny the view and edit permissions for other team areas which the newly created team should not gets access to. Then the newly created team should only be able to access to the Team board which he have the view permission.
Azure DevOps Services:
I need to hide all WIs belonging to one of the teams (= their Iteration Path) from the rest of the project.
Yet the team will need to see everyone else's WIs in this project
What is a proper way to achieve that?
set 'Deny' on 'View work items in this node' for all 'Contributors' and 'Readers'? But if my team is in 'Contributors' (so they can see all the other WIs) their access will also be denied (by inheritance), even if i add them explicitly.
Area Path 'Security' settings
I hoped to google a ready solution for such a common request, but have not found one yet, unfortunately.
But if my team is in 'Contributors' (so they can see all the other WIs) their access will also be denied (by inheritance), even if i add them explicitly.
This is actually an expected behavior which you can refer to Permission settings, it says For most groups and almost all permissions, Deny overrides Allow., this means when one of the team members is denied from View work items in this node in one group(such as his team) and allowed in another group(such as Contributors), he can't see the specific team's work items since the Deny overrides Allow.
It's also simple to understand logically, user A will be allowed to see another team's work items when his team is denied from?
My opinion is that you should move the user A to another team which could see the work items in the specific team.
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