GitLab maintains access to issue forks on git.drupalcode.org. www.drupal.org tries to keep track when web hooks are invoked or push access is requested. But people can leave projects in GitLab, be added as maintainers, etc. Instead of trying to keep our database in sync with GitLab, we can instead have the GraphQL request in issue-fork.js that gets GitLab project information also get the userPermissions.
Issue fork drupalorg-3348875
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
fjgarlin commentedNote that this MR only covers the "isMember" query. I wasn't sure if we'd want to fully remove "drupalorg_issue_fork_maintainers" table here or in a follow-up.
Needs review.
Comment #5
drummWe do use this table to populate the crediting & committing table, so we’ll need to keep it. The number of patches includes the number of pushes to the issue fork.
We should move this to front-end JS to keep response times lower. Any delay in GitLab’s response wouldn’t hold up loading the base issue page.
Comment #6
fjgarlin commentedThe checking is now done totally via JavaScript.
I've added a parameter to the "forkInformation" method to allow skipping the check before rendering. If that's the case, we'll show a button to get access by default.
Then, via JS, if the user has access to the fork, the button disappears with a message informing about it.
Same testing information as in #4.
Comment #7
fjgarlin commentedReady for review again at https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3...
Feedback in the MR was addressed.
Comment #10
drummDeployed, and production does not have the same unexpected GraphQL behavior as dev. So deploy removing that parameter.
Comment #13
drumm