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
Related
Since the process of one A/B test usually takes multiple sprints I would like to add another board in which I can add the A/B tests (as F.E. features). User stories for one sprint can then be added to a specific sprint for my team (which consists of a few specialists and a developer). This way I am able to overview the status (research phase, test , code writing, running, analysis, etc.) of all tests in one overview. I have not been able to find out how this is possiblie within Azure Devops, or if there is a work around. Can anyone help me?
My team also works in projects other than A/B tests, which means we cannot use the boards section.
Unless there is a hidden way to add another board to a team?
You could Copy or clone a work item to add the user stories or tests to a new boards. Open the user story you want to clone, then click Create copy of work item and choose whether to include exist links, attachments and child work items. After creating, change the Area and Iteration to your target boards.
Update
In Azure DevOps you can only create boards by creating a team. The team board is created as a side-effect of creating the team. Please refer to Manage and configure team tools and Configure and customize Azure Boardsfor details.
After creating and configuring a new team, you could see the boards in the dropdown list.
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 problem with configuration of AzureDevOps process.
My goal is simply automate work items - when work item changes state to done or is in state done on certain board I want to transfer it on other board.
I tried to achieve this by applying custom rules in my organization. Example:
I navigate to Organization Settings, select Process then I select process from list (is inherited from Scrum parent). Then I select bug (for example) and go to rules tab.
Here is screen of my configuration
Both Board no.1 and Board no.2 exist as Team Projects. I've added clearing assign to field and this one works properly.
I wondering if there is much easier way to automate moving work items through boards or team projects on status change.
I wondering if there is much easier way to automate moving work items
through boards or team projects on status change.
For this issue, I am afraid there is no easier way to achieve this requirement. Azure Devops has provided a built-in custom rule function to achieve this. This is already a very easy way.
In addition, we can also achieve this through the azure logic app, but this needs to be set in the azure portal. I don’t think it will be more convenient than custom rules.
To move work items to another project, you must be a member of the Project Administrators group or be granted explicit permissions to move work items.
I'm trying to configure and customize the Azure DevOps tool as per the requirement for my application development team. In the boards setting, I have selected the option "Bugs are managed with Tasks" to get a good view of my sprint items. However, my team reports post production issues as Bugs in the tool and enabling the above mentioned setting doesn't allow me to view these Bugs in the Kanban Boad. Reason is they are not linked with any User Story.
I have been exploring the options in Backlog levels options available in the Processes settings and found that the Backlog level "Stories" is tagged only for User Story.
My query here is can i try linking Bug and Task to the already existing "Stories" backlog level. Azure DevOps does gives option to create a custom backlog level and custom Work item type. I would like to customize the existing functionality to best fit my team. Please let me know if there is a work around.
Query regarding Backlog Levels in Azure Devops
This behavior is by designed and there is no way to fix it at present for the exists Work item type Bug.
Because there is only one requirement backlog and it cannot be removed, but can be renamed and edited:
There is an user voice about this request on the Developer Community.
As workaround, we could create a custom the Work item type and add it to backlog level, for example, I create a custom Work item type BugWithoutTask, then add it portfolio backlog:
Then go to backlog settings and enable new backlog:
Now, we could these BugwithoutTask in the Kanban Boad:
You could check this document for some more deails.
Hope this helps.
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.