Unable to fetch user's repositories by organization membership


#1

I am not able to list all repositories that a user has access to by organization member affiliation. I am using a query that fetches all repositories a user has access to, but only repositories that I am an owner or collaborator of appear in the results. This seems like a new regression, as the query I am using hasn’t changed in quite a while and this only started becoming an issue a in the last couple of days. This is the query I am using:

query AffiliatedRepositories($first: Int!, $after: String) {
  viewer {
    repositories(first: $first, after: $after, affiliations: [OWNER, ORGANIZATION_MEMBER, COLLABORATOR], orderBy: {field: PUSHED_AT, direction: DESC}) {
      nodes {
        ...RepositoryFields
      }
      pageInfo {
        hasNextPage
        endCursor
      }
    }
  }
  rateLimit {
    cost
  }
}

fragment RepositoryFields on Repository {
  id
  nameWithOwner
  description
  url
  isPrivate
  isFork
  isArchived
  viewerPermission
}

Appreciate any help + insight on this!


#2

I can confirm this regression. E.g. this query is not returning any organizational repositories for me anymore (it should and did before):

query { 
  viewer {
    repositories(first: 50, affiliations: [ORGANIZATION_MEMBER]) {
      nodes{
          nameWithOwner,
      }
    }
  }
}

#3

Hey @b-3-n and @attfarhan!

Sorry for the late reply - it’s been a busy week over here at GitHub!

I think I’ve tracked down the reason that you’re experiencing this regression, I’m reaching out to the team that made the change, I’ll keep you updated as soon as I hear more information.

Sorry for the disruption - I know how painful it can be when regressions like this happen.


#4

Hey again @b-3-n and @attfarhan!

After conferring with one of our engineering teams, it looks like this was due to a partial-release of some schema changes!

In order to allow for more flexibility between user permissions and viewer permissions, a change was shipped about a week ago that added an ownerAffiliations parameter to the Repositories connection. Unfortunately, this got held behind, and did not make it to our public GraphQL schema.

We’ve remedied the situation, and you should be able to reproduce the query results that you were looking for by adding affiliation arguments to the ownerAffiliations, in addition to what you’ve done with affiliations.

Again, we’re sorry for the trouble - if there’s anything that looks odd, or if you’re not finding the results to work properly, please respond here ASAP and I’ll make sure that we follow up.

Let me know if there are any other questions as well! I know it’s very disruptive when we create changes to our GraphQL schema like this, but in times of security and other usability problems, it may be necessary.


#5

Can you clarify what the difference is between ownerAffiliations and affiliations?

Is the correct fix to the above queries to pass both ownerAffiliations: [OWNER, ORGANIZATION_MEMBER, COLLABORATOR] and affiliations: [OWNER, ORGANIZATION_MEMBER, COLLABORATOR] or do we just need ownerAffiliations: [OWNER, ORGANIZATION_MEMBER, COLLABORATOR]?

Also, did this change ship with GitHub Enterprise 2.15.0?


#6

Hey @nicksnyder!

Before this change, the affiliations field was overloaded to mean both the affiliations that the viewer had with the specified repositories, as well as the affiliations between the user that the connection was operating on. This caused a host of issues in various places, and we opted to separate them out to allow for more flexibility.

In order to fix the above, the proper behavior would be to pass the full list of arguments to both connections, which should provide you all of the possible repositories.

This regression and following change did not ship in Enterprise 2.15