Potential breaking change in GitHub permissions: Command is not configured for the user's permission level 'none'

[aaron-lane]

trafficstars

Hello! In the middle of yesterday (2021-09-21), our dispatch actions across multiple repositories suddenly started refusing to run when triggered by members of the repositories' admin teams, citing a permission level of none. There were no changes to our action configurations and no change to the teams as far as I can tell, but the solution was to directly add individual members of the admin team as admins on the repositories. As there were no changes to v2 of this action for the last 20 days, I'm guessing that GitHub quietly changed their permissions model yesterday, but I thought I would open this issue in for awareness or in case some one knows what is going on.

Failing action output from a member of the admin team running /destroy on a pull request:

Run peter-evans/slash-command-dispatch@v2
  with:
    token: ***
    reaction-token: ***
    commands: test
  destroy
  help
  
    permission: maintain
    issue-type: pull-request
    event-type-suffix: -command
    reactions: true
    allow-edits: false
    repository: hashicorp/terraform-azurerm-terraform-enterprise
    dispatch-type: repository
Using configuration from yaml inputs.
Command 'destroy' is not configured for the user's permission level 'none'.

Passing action output from the same member added directly as an admin running /destroy on the same pull request:

Run peter-evans/slash-command-dispatch@v2
  with:
    token: ***
    reaction-token: ***
    commands: test
  destroy
  help
  
    permission: maintain
    issue-type: pull-request
    event-type-suffix: -command
    reactions: true
    allow-edits: false
    repository: hashicorp/terraform-azurerm-terraform-enterprise
    dispatch-type: repository
Using configuration from yaml inputs.
Command 'destroy' to be dispatched.
Command 'destroy' dispatched to 'hashicorp/terraform-azurerm-terraform-enterprise' with event type 'destroy-command'.

[peter-evans]

Hi @aaron-lane

Thank you for this report. I think you are right that this is GitHub making changes to the permissions model. I already have an open ticket with GitHub support about this issue, which I imagine is related. I'll try and find out from GitHub what changes have been made and what I can do to align this action to the new changes.

Just a couple of questions:

• What is the repository permission level for the user that owns the PAT used for the token input?
• What scopes does the PAT have?

It's possible that they have increased the permission level requirement for the user that owns the PAT. If you wanted to experiment you could try giving the user that owns the PAT admin access, for example.

[aaron-lane]

Thanks for the fast response, @peter-evans!

The user that owns the PAT has admin through the same team as the users that are trying to dispatch commands.

The PAT has the public_repo scope.

I tried removing the redundant roles for the admin testers and added the PAT owner directly as an admin; no change in the permission detection occurred. The only workaround seems to be that the testers are directly assigned maintainer or greater permissions, as per the permission: maintain in our configuration.

[PSchnurbus24]

Is there any news on this as we are experiencing the same problem?

[peter-evans]

The support ticket I made with GitHub is still open with no new response. I'll follow-up.

I think they made changes to the permissions model and I was hoping GitHub would be more forthcoming about what the change was so that I could work around it. It looks like I might need to go digging to figure it out myself. I just haven't found time to do it yet.

[peter-evans]

I have a response from GitHub.

Given that you have org-repo, org-repo-team, and a non-org repo-admin user, repo-admin can only see members directly added to the repo. They cannot see membership to the repo granted via org-repo-team, regardless of whether that team is visible or secret.

The change was bringing the API in line with the github.com website. Prior to this, the API showed team memberships to outside collaborators, but github.com did not.

Adding repo-admin to the org grants the ability to see full membership list in the website. Afterwards, creating a PAT with read:org permissions grants the same ability for the API.

Summarizing the current behaviour Team membership is only shown to org members, not to outside collaborators or PAT without read:org permission. This behavior is consistent with teams documentation and Outside Collaborators documentation on the github.com website.

The solution for the user account on which the PAT has been created:

For the user, ensure they are a member of the org being checked, and make sure their PAT includes read:org access.

@aaron-lane @PSchnurbus24 Please let me know if adding the read:org permission works for you and I'll update the documentation. The PAT must be created on a user that is also a member of the org.

[PSchnurbus24]

Hi, I don't use a user PAT, but a Github App for this. I gave the app the read:org permission and it seems to work. Thanks alot!

[peter-evans]

I've updated the docs: https://github.com/peter-evans/slash-command-dispatch/commit/df55ff2c7db7f2b65a19db2c8b63b16e3a2d62a6

I think we can close this now.