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.
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 have a User Story against which there is an impediment faced in current sprint. Due to this impediment, we are not able to complete the US in this sprint. However we cannot also close it or mark it resolved. Since its open without any action, its also interfering with the burndown charts.
Can I get an advice on how we can handle impediments in Azure DevOps and thereby set that work has been halted/suspended on a particular user story? I was reading the related article here: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/manage-issues-impediments?view=azure-devops.
Thanks and Regards,
Satheesh Vijayan
As stated in the documentation:
You use issues or impediments to track items that may block work from
getting done. In general, you link these items to user stories or
other work items using a Related link type.
So as a workaround ,you can try customizing impediments tracking ,through this you can customize the item state,add a special state to impediment item . For details, see Customize an inheritance process.
Organization Settings -> Process -> Inheritance process -> Impediment ->State -> New state
Note: only inheritance process can be customized.
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.
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.