I am playing around with GitHub environments, specifically checking out on the actions approval feature.
I have created the related infrastructure in order to support this and I have also added a colleague as a collaborator to the project. I am trying to add them as a deployment reviewer as mentioned in this document, however the selection box in the related view does not list their name. As mentioned above, their access is set to collaborator and the doc states the following:
The reviewers must have at least read access to the repository.
So I do not think that this is a permission issue. Can anyone help with this?
Related documentation:
https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments#about-required-reviews-in-workflows
https://docs.github.com/en/actions/reference/environments
Nevermind, I figured it out. It seems that the input on the page needs the full name of a team member in order to assign them as reviewers. Simply typing part of it does not work and gives the impression that it cannot find eligible reviewers.
Related
I have an organization and want to add granular permissions for each repo. This does not seem possible and the docs send me to "Setting the base level permissions" which I do not want.
github docs
Answer is adding a person in the Settings of each repo. Should be in the docs.
Also, this is a stupid and dangerous way of adding people in an organization as I could easily add someone to this repo from outside the organization if I'm not careful. Very, very stupid. I should only be able to add people from WITHIN my organization, that's the entire f... point of having one in the first place.
We have hired a 3rd party to work on a project, we started by not creating any Repo on our Github, but they started with their Repo. So now it's time to transfer the repo. However, in order to transfer the repo, the developer is asking permission to create a Repo in our Org... but as far as I know, I can only invite him first as a collaborator, a member, before he can create any private repo in our Org... that means he can see our other repo...
I couldn't find any good answer online, please help. Thanks!
Have you tried using Github's Organization features? You can create an organization with your team members in it, and control who has access to what.
Here's a Github page that explains a bit more about how it works.
Do not add them as a member to your Org! (this is the only option today from Github, nor owners...of course). If you do so, this will give your external developer access to all of your repos.
The only way I found you can safely invite an external user is to create a Repo first, then add them in that Repo. By doing that, they will be invited only to that repo, and have no access to the others.
This is my workaround. If you have a better solution, please do comment. I am curious how the "transfer" feature works.
I have created a new Team/Area under our project within Azure DevOps.
When I send the URL for the backlog, the team members are able to access the link but not see any of the work items.
I have tried the following:
Confirm the user has Basic licence.
Confirm the user has access to the project.
Added the user to the Team for that area.
Is there anything obvious I am missing?
I am pretty confident this is not a bug, but just something in the process of giving users access that I am not doing.
Any help very much appreciated.
Thanks,
Alasdair.
When I send the URL for the backlog, the team members are able to access the link but not see any of the work items.
This could be caused by multiple reasons which means we might need to check several setttings.
Choose the right team in BackLogs page:
check the Project Settings-Team configuration-Areas, make sure the target Team area has been added:
Check Project Settings - Permissions and make sure your team has
the right permission to see the BackLogs Itmes.
Is this something that I need to set every time I create a new team?
No, you don't have to set them every time. When you create a team,
the Permissions setting could be automatically inherited:
I think the answer is no, but maybe I'm missing something: in most repos, you only have one or two admins, and a bunch of "collaborators". But it looks like the collaborators can't assign issues (eg, to themselves), nor can they label issues (even ones they created).
Bug? Design feature? I'm using it wrong? Are there any workarounds?
Looking at Issues 2.0: The Next Generation, this seems to be by design, and from the comments, this isn't the only "problem" users are facing:
It looks like issues can only be assigned to collaborators.
I'd still like to be able to assign an issue (or someone to claim one) to a developer who is not a repo collaborator. After all it is a very common workflow that collaboration happens with forks and pull requests.
One potential workaround (not tested myself) is for a user to fork the original repo, and reproduce the issue in the issue tracker of that new forked repo (that he owns):
the new issue would keep an html link to the original issue of the original repo
the user can assign and label issues.
Obviously that involves a bit of duplication, but for bugs a user wants complete ownership of, that can be worth doing.
Is it possible to completely remove an issue from the GitHub issue tracker?
No, the github API only allows you to open/close/reopen issues. Here's the Issues API docs.
You can edit an existing issue (let's say if it's a duplicate) and you can change the title, description and target milestone to be something completely different. That's as close as you can get to removing the ticket, AFIK.
Update Nov 2018: You now can delete issues if you are a owner of the repository!
See "Github - remove issues entered in error"
https://docs.github.com/en/github/managing-your-work-on-github/deleting-an-issue mentions:
People with admin permissions in a repository can permanently delete an issue from a repository.
For other people (without permission), questionto42's comment shows that you can ask to GitHub support for the issue to be deleted, as illustrated here.
At May 2018, original answer:
Three 8 years later, and closing issues remains the answer (still no deletion possible).
See "The Ghost of Issues Past", where GitHub advise to check and close:
issues opened over a year ago state:open created:<2013-01-01
the ones I'm involved with involves:twp state:open created:<2013-01-01
and those not updated in the last year involves:twp state:open updated:<2013-01-01
For posterity: Deleting issues would be a bad thing, since in general they can be targets of associations on github.
But if you are willing to sacrifice the collaboration info, here is a "whack it with a sledgehammer" approach:
Clone your original repo.
Copy your issues via the Issues API.
Delete the original repo; alternatively, chose a new name for your new repo.
Re-create a new repo based on your clone.
Re-create the issues you want to keep via the Issues API.
I imagine this could potentially lose a lot of other linking information as well such as forks, pull requests, etc.
Public feature request
I wrote to GitHub in 2014-08 and https://github.com/jdennes replied by email:
Thanks for the suggestion. It's only possible to edit/clear the issue content currently. However I've added a +1 to this suggestion on our internal Feature Request List.
confirming it was not possible.
Best workaround so far
set the title to something that will never conflict with any search, e.g. a single dot ..
This may not hide the history of your blunder entirely because of the automatic undeletable "changed the title to" comments.
make the body empty
GitHub staff has the power
If something is a security issue, contact GitHub staff, they usually reply quickly, and are able to remove issues for good as can be seen at: http://archive.is/OfjVt which has issue 1 and 3 but no 2.
You can delete the entire repo if it's really important.
Possible workaround
As of 04/2019 not all issues can be deleted current work around is to edit the issue then delete the edit history, the only downside is that the issue still exist and the old title could be seen.
You could by just asking to github to ban the user that created the issue 😁
Source: https://github.com/isaacs/github/issues/253#issuecomment-290944938
Users are unable to do this, including repository owner.
But issues can be deleted by Github support. One may contact them and request deletion. It may be delayed or refused but it is an available option that can be used.
Still impossible. Another workaround to the ones suggested in the other answers is to label the issue as "deleted" (or any other label you might fancy better), to be able to filter them out if you use the github API to retrieve them. Obviously you should use that specific label only for this purpose, setting the label when you close the issue.
You can create a new repository.
Transfer (yeah it is possible) unwanted issues to the new repository.
Then delete the new repository.