Option to limit visibilty of users in Azure DevOps - azure-devops

Our main Azure DevOps Organization is linked to our Azure AD. We need to invite customers to specific projects as stakeholder only, and with this, they are added as external users in our AD. We found that within a customer project also, all other external users are visible, e.g. via mention with # anywhere in the text or assignment drop-down, although these do not have access to that project. Our only workaround so far is to create new non AD linked customer specific organizations, but this is really not the right way to go (licencing, management etc.)
Is there any option to prevent this and to restrict visibility to only those users, which are part of a project (or planned)?

I tested and found the same issue as you said. It is by design, you can raise a problem in the Developer Community
https://developercommunity.visualstudio.com/spaces/21/index.html
Besides, since there is a workaround that works now, continue on this basis. You can create different AAD for the customer specific organizations, then add the customers to these AAD. Thus, these users will be invisible because they are in different AAD organizations.

Related

What permissions does an Organisation Owner have in Azure DevOps?

We've been using Azure DevOps but I'm wondering what the Organisation Owner does? Do they have extra permissions in Azure DevOps or is it just a 'for info' type field so people know who to speak with about any DevOps queries / change requests with the setup.
Thinking ours may need to change but just looking to see what the impact is in changing that - i.e. what permissions would the existing person lose (and what would a new person gain) if that was to change to someone else.
Generally, there aren't extra permissions for the owner account, so, just feel free to change owner. For the new owner, he has the admin permission.
On the other hand, you may just add the new user to Project Collection administrators group, then this new user will has admin permission too.
From the docs
An administrator or organization Owner can give you access to select
features or functions, or change your permissions. In this article,
learn how to look up administrators or organization Owners.
and here are the rights or things that organization owner can do.
Generally, as an organization Owner, you are the administrator of your DevOps service and you have super permission. You can manage your project, includes:
Add users to your project
Grant or restrict permissions
Share your project vision and support collaboration
Remove unused services from the user interface
Set code, test, and other policies
Define area and iteration paths for work tracking
Customize work-tracking processes
Review and update notifications
Add teams to scale your organization
Install and manage extensions
Set up billing
Detailed information, you can refer to the following link:
https://learn.microsoft.com/en-us/azure/devops/user-guide/project-admin-tutorial?view=azure-devops

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.

Github organization invite v.s. request membership

I am making a small Git / Github demo for first-time users and want to use Github Pages, for which I needed to create a new Github organization. During the 30 min I'll have to do the demo, users will need to create new Github accounts and join the organization. Since I'll have so little time, is it possible for users to request organization membership, rather than me having to invite each person manually by email lookup?
I've seen this before but only through third-party apps. Is there no way to do this directly within Github?
Directly with GitHub, I have seen no evidence of that feature.
Through third-party apps indeed, yes.
As an example: benbalter/add-to-org would automatically add users to an organization.
For smaller teams, this may not be possible. The feature that you have mentioned seems similar to user provisioning and is available for Enterprises through Okta /Azure Active Directory. This link has more details on the User Provisioning.

Exporting Users From Azure DevOps

Is it possible to customize columns in Azure DevOps --> Organization Settings --> Users page. Currently we have Name, Extensions, Access Level, Last Access. I need to add another column to show whether the user have code read-only access or contributor access.
This page can't be customized as fas as i know. What you want can't be displayed on that site if you have more then one project anyway. If you want to see this organizationwide a better way would be to organize the users in "Organization settings -> Permissions" in groups for readers and contributors

Azure DevOps and Teams - one Group group to control membership to both

I have been trawling the internet and clicking myself blue in the face! Hopefully someone has a definitive answer.
I want to have one Group (in either of Azure AD, Microsoft Teams or Azure DevOps). This group must have access to a DevOps project and a Team site. When I change the membership of the group, the membership must change for both the Team and the DevOps project. I want to avoid the overhead of managing the groups for both separately.
Is this at all possible? Thanks.
This is a really good question, and the answer is not obvious at all. Ironically we had the same exact problem in Microsoft Teams - when a user was added or deleted from the underlying Office 365 Group (which is mastered in Azure AD), it would take up to an hour, sometimes more, to be reflected in Teams, which has its own copy of the member list.
There is a way to do it, and it's how Teams does it: it relies on a relatively new feature in Microsoft Graph called subscriptions. You can find the documentation for it here: https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0.
Essentially what you want to do is create a subscription to the group: POST https://graph.microsoft.com/v1.0/subscriptions with the right message body and your endpoint will be called whenever there's a membership change in the group. Your endpoint won't know what changed, just the event and some IDs - you will likely have to make a separate call to retrieve the actual data (unless the IDs alone are sufficient).
There's a sample on GitHub that illustrates how to use Microsoft Graph subscriptions including more details on how to subscribe to group notifications specifically.
One thing to be aware of is that to use these APIs, your application will require fairly elevated permissions: Group.Read.All which means it has the ability to read not only the team/group members, but all of its messages too (among other things), for every group in your Office 365 tenant. We are working with the MS Graph team to support a less-privileged, per-group permission approach, but even after that's released for Teams Graph APIs, support for that will have to be added to the subscriptions APIs I just mentioned and that may not happen for a while.