We are using the custom process which inherited from the standard Agile process and is using Bug work item type to permit users to log the bugs. We create a new WIT: "Bugs in UAT". And there is a group of users - "UAT Testers". We can grant them either Stackholders or Basic Access Level licenses.
Would you be so kind to advise how is better to accomplish the following tasks:
UAT Testers group members should only be able to use "Bugs in UAT" WIT to log bugs. I.e. UAT Testers should have no access to anything except "Bugs in UAT".
Other users will need to use all WITs, including "Bugs in UAT".
Thank you very much for your help, in advance!
You can't.
Work item permissions are not per-work item type, and there is no way to make them be. Permissions can be assigned at the area path level, and anything under that area path is visible to anyone who has access to it.
Honestly, having "Bugs" and "Bugs in UAT" seems like a big red flag to me. "UAT" should be a column on your backlog board, not a separate work item type. A bug is a bug.
Related
In Azure DevOps, we have created Epics to group features together.
Now we would like to make some of them visible to a specific group of users. They would be in read-only mode.
How can it be done ? We know it is possible to create rules to make some fields read-only, but it goes as far as that. Also, is it possible to make all fields read-only instead of going through each of them.
But most importantly how can we hide all epics but these specific ones for that group of users ?
Your requirements should be able to be achieved through the area settings.
Project Settings -> Team configuration -> Areas-> Security
Put the Epics you want only some people to see under an Area, then put some people you don’t want to see these epics into a group, and set "View work items in this node" to Deny . Then users in this group will not see these epics.
As for setting some epics as read-only, please create a new Area and set "Edit work items in this node" in the above figure to Deny to prevent users in this group from modifying these epics.
I want to pin a chart to the Azure DevOps Services dashboard that shows how many bugs in the current sprint have a linked test case or not.
I have been able to put up a query for the same but it appears that such queries can't be charted out. Is there an alternate way?
Here's the error that I get while creating a chart out of my query
Additionally, I would also like to know if there is a way to ensure that when I Resolve/Close a bug workitem in AzDo services, I can check if there is at least one associated test case work item with the bug. I have explored Bug rules but can't find out a clean way to get the link types associated with the work item. How can I achieve this?
Thanks
I have been able to put up a query for the same but it appears that
such queries can't be charted out. Is there an alternate way?
As for the error you got, it's one open issue here in our feedback forum, the product team is considering about it. But there might be some time before the feature comes true. You can track the issue to get notifications if there's any update. Sorry for the inconvenience.
Is there an alternate way?
If you just need a widget to display the results of the query, you can consider using Query Results widget, if supports tree or direct links. But if you do want the pie chart for WITs, I afraid it's not supported for now when using tree or direct links. You can check the related extensions here.
I have explored Bug rules but can't find out a clean way to get the
link types associated with the work item. How can I achieve this?
As I know we don't have such option in Azure Devops Boards.
If we close/delete one workItem, it won't display a prompt or what that tells us the related workItems are still active.
But I think that would be a great idea, so I suggest you can post one feature request here to share your idea to product team. Then we can share the feature request link here and people who interested in that would vote for you! Hope all above make some help :)
My company is moving to DevOps and Azure Boards from our previous environment in JIRA and we've encountered a very big issue with permissions.
At the moment, we have configured various Areas to support our development teams; we also have an Area dedicated to the Product team, where business requirements are first input and then reviewed. Each team has permission to edit work items in its own Area and it can't edit work items in other areas.
So, basically this is our structure:
Engineering: the main Area of the project; only administrators can edit work items
Engineering\Mobile: child area for the Mobile team; only members of the Mobile team and administrators can edit work items
Engineering\Backend: child area for the Backend team; only members of the Backend team and administrators can edit work items
Engineering\Device: child area for the Device team; only members of the Device team and administrators can edit work items
Engineering\Product: child area to review business requirements that are then moved to the appropriate area; everybody can edit work items
Now we're trying to give anybody from any team the permission to comment (aka. use the "Discussion" section) a work item regardless of the Area where it is, but it looks like the ability to comment is strictly related to the permission of editing the work item… In other words, we haven't been able to enable the Discussion section without giving the permission to edit a work item, which isn't ideal.
Is there a way to enable the Discussion section for anybody while keeping editing restricted?
Unfortunately, it's not able to do this in Azure DevOps at present.
Unless you give the users permission "edit work items in node" permission, otherwise he will not be able to comment in the discussion field separately.
There is already a user voice here--Add support for for/not rules in the inherited process model
According to our PM's reply:
We currently do not have any plans enable field level security. But we
will continue to track this suggestion. If we begin to see more votes
we will take it under further consideration.
You could vote that ticket and track the process. Sorry for any inconvenience.
I can't figure out if it possible and how it can be done to allow certain users in a Visual Studio Team Services project to see only the work items they created, instead of them all.
Thanks in advance for all your help.
For now, there is no ways to set permissions for a user to only view work items which were created by oneself.
It's only available to set permission based on Iterations and Areas for now.
But there has an user voice field level security permissions which suggest similar feature, you can vote and follow up.
And the features in below two user voices have already added in our backlog, when the features are archeived, it can also benefit the situation you met:
Hide Work Item Types (WITs) based on permission/security group
Add ability to hide/mask fields in a work item based on security/permissions
This is not supported. It used to be in the on-prem product a long time ago in the "Work item only view", but that has been removed in favour of the Stakeholder view.
I have a bunch of custom user groups. I need to change the permissions for one of the user groups so they don't see "Turn editing on" button or link. I figured out a way to do this in a reports section. I can't figure out a way to do this for course section.
I deactivated manage blocks and manage activities and that removed the button on all of the sections except courses. I tried to deactivate update course and a bunch other course related capabilities with no luck. Did not see any sort of manage courses capability.
Any help would be appreciated as I just inherited this site and have had no previous experience with Moodle.
Totara version 2.7
Moodle version 2.2.11
Do you want to this by code or configuration? If you want to do this, simply by configuration, just make a new user group for them "Site administration->User->Permissions->Define Roles", give them the ones you want them to have. Then assign the users in question this role. They should not see the buttons in question.