How to hide field from Stakeholders in Visual Studio Team Services - azure-devops

Is there a way which permits to hide certain fields from the users which possess Stakeholder access level licence or belong to certain groups?

No. All fields are visible to anyone who has access to view the work item.
This applies to both the work item form and the REST APIs.

Related

Azure Devops permissions - can one area be visible to one team and invisible to another

In my Azure boards, I have a hierarchical structure of the areas. In the team settings, all teams have areas being set, just like described here: https://learn.microsoft.com/en-us/azure/devops/boards/plans/safe-configure-boards?view=azure-devops#configure-area-paths
Is there a way for one team to see only the area it is set to, but no other areas? Currently, in Boards>Work items any member of any team can see everything, even User stories that do not belong to his area. How can I restrict this?
Edit: it might be from Security options of an area, add a group to it and make work items invisible, see this screenshot from Azure documentation.
But, even as an admin, I don't have such option to add! Why is that?
The UI has changed. There is no add option in the security settings page now.
You can directly search for the Team Group in the Search box and change its permission settings. See below screenshot.
Okay, in addition to Levi's answer:
First, every new user added to a project is also added by default to one of this project's groups: Contributors, Readers, Admins. I'm not considering admins here.
If we want to make one area visible to only one team, we need to do the following:
Either modify Contributors or Readers rights so that the "View project-level information" is set to Deny, and then for each new user, add it to a team and for that team set this option to Allow for the area needed
or (better)
Create our own groups for which "View project-level information" is set to Deny (for ex. Developers, QAs, etc.), and then for each new user, remove it from Contributors or Readers and add it to the corresponding group. Then add the user to a team, and for that team set the "View project-level information" option to Allow for the area needed

Consequences of adding a user to a project but not to an organisation

I am trying to understand the complete purpose of organisations in ADO. What I have understood is that an organisation groups projects, defines resources, extensions, billing, etc. that is related to the organization.
I am struggling with the user part of an organization. I can add users to an org giving them an access level. But I can also add users directly to a project without adding them to an organization at all.
What is then the consequence of this? Is then access level by default stakeholder for those users?
Thank you
You can add people to projects instead of to your organization. Users
are automatically assigned Basic features if your organization has
seats available, or Stakeholder features if not.
For this please refer to the Note of this document.
When you add members to projects and you don't have billing set up, Basic access is automatically assigned, until you run out of seats available. When you add members to projects and you do have billing set up, Basic access is assigned only if your default access level is set to Basic. Otherwise, project members are assigned Stakeholder permissions.
You can refer to Add members to projects or teams for details.
If you add an user to a project that user will be added to the organisation as well. At least when the said user first logs in. The user will get the access level you define as default.

What group does one have to be member of to add new User Stories and Bugs on the board?

Currently users are members of the Project Administrators group.
Is that the minimum group membership required to add new User Stories and Bugs to the Boards interface?
Update
Area path permissions let you grant or restrict access to edit or modify work items, test cases, or test plans assigned to those areas. You can restrict access to users or groups. You can also set permissions for who can add or modify areas or iterations for the project.
You define both areas and iterations for a project from the Project Settings>Work>Project configuration.
1) Choose (1) Project Settings, expand Work if needed, and choose (2) Project configuration and then (3) Areas.
2) Choose the ... context menu for the node you want to manage and select Security.
More details please take a look our official link.
This is not only based on which group you are in.
Note:
Limitations to select features are based on the access level and
security group to which a user is assigned. The Basic access level and
higher supports full access to all Azure Boards features. Stakeholder
access level provides parti
So to add new User Stories and Bugs on the board, you need to meet both permissions and access for Azure Boards.
For Permission:
Boards present work items as cards and support quick status updates through drag-and-drop.
You could also use single permission to restrict users with Agile Boards. For if you want a simply solution, you could add them to Contributors Group directly.
Note: According to Azure DevOps permission setting, most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.
For Access Level:
Agile boards
Includes limited access to Kanban boards. Stakeholders can't add work items, can't drag-and-drop work items to update status, and can't update fields displayed on cards.
Conclusion: The minimum should be Contributors Group and Basic Access Level
No, the Contributors permissions it's enough:
More info about the board/work items permissions you can find here.

Restrict User Access to Board from Azure DevOps

As a DevOps administrator I want to give restricted access to the backlog of our project to a user.
I want to limit his access. Meaning that the user can only see Work Items he has created in the backlog, nothing else.
Is their a way of doing this?
the user can only see Work Items he has created in the backlog,
nothing else
I am afraid that this feature you want is not feasible.Boards is visible to all members of your organization.
You can only set the member to Project Readers at most, so that members only have read permissions but no modified permissions.
You can set the Assign to filter condition in the Filter of the backlogs to see the work items assigned to a specific person, but it can't prevent the user from viewing the work items assigned to others. In addition, there is no filter condition to see who created the work items.

Dynamics CRM 2011 custom code

I'm struggling to find much documentation on Dynamics CRM 2011 and have a problem. I'm not looking for code more a pointer as to the correct method of approach (workflow, dialog, custom HTML web resource etc)
I basically want something that does the following:
Go to Contact list
Select some contacts
Ribbon action opens a box that allows me
to select a custom role from a drop down list (source is a dynamics
entity)
Select a radio box for either add or remove role
Save the changes, this will add or remove a role from the contact and also send an email to that contact
I know how to get a list of selected recordIDs but I am not sure if I should be calling a dialog or a custom HTML page with JS.
Can anyone point me in the right direction?
This may not work at all for your scenario but it is worth thinking out of the box sometimes. This would only work if you have a small number of roles and the roles don't change that often.
Add checkboxes on the Contact, one for each role. Build workflows that fire on update of those checkboxes that send your emails. Now users can quickly edit lots of Contact Roles by using the Multi-Edit feature.
The benefit of this approach is it is a "no code" solution and it is very easy for the User since it uses out-of-the-box functionality. The downside is that you need to maintain those checkboxes. But it may be easier than writing a bunch of web resources and javascript!
I have assembled a list of bookmarks on the subject here. I hope the link works.
Gareth Tucker's site is specially interesting.
In the end the solution was to create a Ribbon item that accepted the selected Guids from the contact list.
Then read those in from a web resource (Silverlight) which called into the sdk and created / removed the records accordingly

Categories