Currently, I am trying to do a user audit to remove old accounts from our environment. I found this KB about removing users from Azure Devops. I could not find any information about what happens to the content they uploaded if they get removed. If I remove a user from the organization, will the code or any content they have uploaded be removed as well?
Does removing a user from Azure Devops remove the content they uploaded?
The answer is no.
The code or any content they have uploaded will be control by the source control git/TFVC. The source control tool only track the files changes and record the history of changes. But the users is not within the scope of the source control, it only record the uses name who make any change in the source control.
Besides, if remove a user from the organization will remove the code or any content they have uploaded, which will cause all code development will be aborted due to developer changes. This will be a disaster. And, according to that document, it indirect explain that:
After you remove a user from Azure AD, you can't assign artifacts to
that user anymore. Examples are work items and pull requests. However,
we preserve the history of artifacts that were already assigned to the
user.
So, do not worry about deleting users from your organization will delete the code or any content they upload.
Hope this helps.
No. It would be totally useless as a source control or work tracking tool if data was abruptly removed because a user was removed.
Related
UPDATE: I think this question was based on a fundamental misunderstanding. When creating the build pipeline definition, I would pick the saved service connection ("GitHub-iQmetrixService" in the screenshot), and then later Azure DevOps would continue to prompt for access to my personal account. This made me think that the build pipeline was linked to my personal account somehow, such that if my account is ever in the future gone or otherwise unable to access the repository, the build pipeline would stop working.
As far as I now understand, this is not the case. The build pipeline definition itself is in fact associated with the service connection, and the reason that Azure DevOps prompts for my personal login is because the integrated YAML editor is going to want to make commits back to the repo, and those commits need to happen "as me". When co-workers go to the pipeline editor, they too are prompted for their personal login.
I'm still a little bit nervous about this understanding, because I can't see anything in the UI that shows what service connection Azure DevOps is using primarily to process the build pipeline, nor can I see any way to change it should that ever be necessary.
When creating a new Build Pipeline, if I tell Azure DevOps that my repository is in GitHub, I am immediately redirected to GitHub to authorize access to my personal GitHub account (to which I have an ambient login). If I instead pick "Other Git", then the next step in the flow lets me say that the source is GitHub, at which point the screen says:
This authorization, set up by someone else in my organization, works just fine, and I can view all of the organization's repositories and set up a new pipeline. But then, if I close the window and try to re-open the pipeline editor, I am immediately redirected once again to the GitHub page to authorize access to my personal account. Editing the pipeline created based on the "GitHub-iQmetrixService" connection does not use the connection and instead wants to establish a new connection based on whatever individual accounts I have access to.
How can I edit the pipeline without creating a connection to the repository that is linked to my own personal account?
As work around, you can take advantage of the browser sessions and cookies.
Configure the browser to let it retain and keep the session. And do not clear the session and cookie data once you close the browser.
For me, I am using Edge. So, I go Settings -> Privacy and Security -> Choose what to clear, then disable the option
After configure this, I do not need input my account, password and Verification code again while I close the windows, re-open and re-edit the pipeline,
If you want to make some configuration changes on this pipeline, please go right corner-> three dots, and choose the Triggers.
After located to the Triggers page, please change to YAML tab.
Then you can do the modified on this pipeline
To provide some clarity, it appears what's going on here is that for YAML build definitions, Azure DevOps doesn't actually go to the build pipeline definition editor when you select "Edit". The YAML text editor it takes you to is in place of the build pipeline definition editor. But, the definition editor can still be reached. #Merlin Liang - MSFT's answer provides (after the horizontal rule) the steps to take to do this. I didn't understand why those steps, though. I created the following graphic to explain specifically the aspect that wasn't clear in my head:
I have been tasked with figuring out to solve this issue. I am working on a project that uses TFVC in Azure Devops and when a check-in is made the system adds that comment to the discussion thread on the work item. What setting can I change to turn that off?
UPDATED:
I created a test TFVC project in a separate DevOps account that I had with no extensions installed. Checked in changes, a link was added to the Development sections as expected but just like described above it was also added to the discussion, see screenshot. So this appears to be default behavior so how do we turn it off?
As far as I know, you cannot turn this feature off once you have linked the checkin with the work item.
Does TFVC in Azure DevOps automatically write the check-in comment to
the discussion for a work item?
For this issue, the answer is no. The comment added in Check in will be used as the title of the changeset(TFVC) and will not be automatically written to the discussion of the work item.
Changesets will be linked to the Development field of the work item to drive development.
Does TFVC in Azure DevOps automatically write the check-in comment to the discussion for a work item?
Obviously not.
Automatically write check-in comments to the discussion of work items is not applicable to all users, so MS does not add it as the default behavior.
And as test, I could not found this issue on my side, and you could also to check this issue on the other organization or new organization.
As a bold guess, your organization may have one extension installed and these behaviors are performed by this extension, like Work Item Autosave. But I could not sure it, you need to check your extensions one by one, Organization Settings->Extensions.
If you find that extension, you can disable or change the settings to disable this feature.
Hope this helps.
I want to check number of downloads for asset i have deleted. I can get release assets using API : GET /repos/:owner/:repo/releases/:id/assets, but this call doesn't list deleted assets.
Documentation doesn't mention any filters that might help me
Is there a way to list deleted assess via github API?
You can check with GitHub support, but I suspect the deletion of a release or an asset within a release is not something which can be undone or restored.
That means the asset deleted is not "kept" somewhere, and its associated statistics are not kept.
GitHub support confirmed, that it's not possible at this moment. And it seems like it won't be available anytime soon...
I'm trying to create a "Read-only" user account within Visual Studio Online. I've created the user and set all permissions to "Deny" except for "View project-level information", which is set at "Allow".
I've noticed that the user still has the ability to download the solution in its entirety and/or by directory. Is it possible to disable/prevent downloading functionality?
Ideally, I'd like only for this user to browse the solution's directory-tree and corresponding file contents.
Thanks for your help
There is a default Readers group (see https://your_account.visualstudio.com/DefaultCollection/your_project/_admin/_security).
Add the user to this group, and do not forget to restore the defaults permissions.
If people can read the files, then you can't prevent them downloading those files. In any case, even if you could, once the source is on screen people can always copy and paste the contents.
The 'Read' permission will only stop them from uploading any changes.
The problem i am trying to solve is where developers change files without going through the proper channels. The developer should be able to make the change himself but only after his work was approved, since the code is used in a lot of projects
I found this link that also describes my problem:
http://www.p4ideax.com/ideas/694/temporary-permissions
One way to do it is to have only the architects have access to the files and then granting the developer temporary access. Maybe the permission can be linked to a specific job in perforce. The only way i can see how to do that is by adding the files that the person should be able to change to a new field in the jobs template ( done by architect ). Then have a server app dynamically call p4 protect and manage the permissions table. Then when the job is closed the permission is revoked. The server app could be the bugtracker software.
Is there an easier way or even 3rd party software out there that can solve the problem?
I know that another way to solve it is to put these sensitive files in a branch and then only allow the architects permission to merge into this branch. This solution feels a bit heavy handed.
Any suggestions would be helpfull
This is something that could certainly be done with a pre-submit hook. There are examples at Perforce Depot.
My thinking would be to reject submits for files in that section of the depot that didn't have a job that was on the "approved list". You could create the approved list in a number of ways, although a simple one (if you're using Perforce globally) would be to put the job list into a file under repository control and then have that list be available only to the architects.
The pre-submit trigger would then basically need to:
- If the files being submitted aren't in the protected tree, let the submit happen
- Grab an r/o copy of the file from the depot
- Grab the job list from the submit
- grep the job against the list
- If the job is in the list, let the submit happen
- Reject the submit with an appropriate error message