Which permissions to use for Issue actions (lock, label, close)?


#1

I’m a little confused if I should be using one of the Repository “viewerCan” fields or the Issue “viewerCanUpdate” field. It seems to me that “viewerCanUpdate” is about editing the root issue comment text. However all of the other “viewerCan” fields don’t sound like they represent the correct permissions.

Any hint as to what I should be using?


#2

Checking in to see if anyone has any idea how to pull this off. It looks like the V3 API has an is collaborator endpoint. I wish there were something like this to see if someone can lock/label/close an issue or PR. However, that doesn’t seem possible at the moment (unless I’m missing something).


#3

Why not use authorAssociation?


#4

@yakov116 that only shows the association of the Issue/PR author, not the viewer. I’m trying to make sure that based on whoever is viewing an Issue/PR we show/hide the appropriate editing controls.


#5

So then you can use
viewerCanDelete
viewerCanUpdate


#6

What I think maybe useful is viewerIsCollaborator but that you would have to wait for @github staff…
Or viewerCanLock etc…


#7

Where do you get viewerCanDelete? Both the Issue and PR docs don’t have this field.

viewerCanUpdate is specifically about the body text. If you authored the issue on a repo you aren’t a collaborator on, you can still update the issue, but you cannot edit the labels.

Agree, a viewerIsCollaborator would solve all of our problems.


#8

Never trust the docs :slight_smile:

Use the explorer and try the below

{
  repository(owner: "rnystrom", name: "GitHawk") {
    pullRequest(number: 649) {
      timeline(first: 100) {
        totalCount
        nodes {
          ... on IssueComment{
            authorAssociation
          viewerCanDelete
            viewerCanUpdate
            
          }
        }
      }
    }
  }
}

#9

Ah interesting. So that field does exist on the IssueComment object, but if an Issue/PR doesn’t have any comment timeline events, you still can’t get permissions about action on the root comment, which is where actions like lock/label/close would be performed.

Tested in the explorer and confirmed that this fails:

query {
  repository(owner: "rnystrom", name: "githawk") {
    issues(first:1) {
      nodes {
        viewerCanDelete
      }
	}
  }
}

Almost a good proxy though.


#10

One second that does not look right (the query)


#11

What about this?

{
  repository(owner: "rnystrom", name: "GitHawk") {
    issue(number: 1) {
      viewerCanUpdate
      comments(first:10){
        nodes{
          viewerCanDelete
        }
      }
    }
  }
}

#12

That still only works for issues that have comments. If they don’t, you still can’t access viewerCanDelete. For example, this query only gives you the root comment (of which the object doesn’t have a viewerCanDelete field).

query {
  repository(owner: "rnystrom", name: "githawk") {
    issue(number:455) {
      body
      comments(first: 10) {
        nodes {
            body
        }
      }
    }
  }
}

#13

viewerCanUpdate you are missing


#14

Like I mentioned above, if you are the author, you can update the root body text. That doesn’t mean you can add labels, lock, or close the issue. “Update” in this API means “edit the body”.


#15

Correct.

I guess use this for now

Side note: It looks like your making a github app. I am a maintainer on one too. Take my word for it DON’T switch YET to GraphQL. Wait until they fix it a bit. We learned the hard way :frowning:


#16

Haha ya, already regret being an early adopter. Parts of it are great, others are very frustrating (incl this).