Feedback on permissions


#1

Integrations come many options for granular permissions. If you think a permission category is missing or not quite suiting your needs, let us know. Particularly, if you still feel you have to request more permissions than you actually want to gain the access you need.


#2

Is there anyway to add additional permissions at a later time? I’d hate to have to re-create an integration because I forgot to check the correct box.


#3

Upgrading permissions for an existing integration is a terrible idea because your users have no control over what you request during the upgrade.


#4

As far as I see there is currently no way to iterate over the git tree for a given repo (the endpoint is blocked).

The /repos/:owner/:repo/contents/:path endpoint comes close but is terribly inefficient as it doesn’t include the content of subdirectories.


#5

It’s not a terrible idea. OAuth applications already have an existing method for request additional permissions. Right now users don’t have any control, but that could be added.

My real problem is that during development of an integration, I’m not 100% sure what permissions I have. If I’m the only user of my integration and I need another permission, I need to delete the integration and create a new one.

What if you can change permissions for internal integrations? Or you can change permissions for integrations that have no active installations?


#6

Great question @kyleconroy. Before we move to a full general release of Integrations, we do plan to add the ability to edit your Integration’s permissions. When we implement this functionality it will have users in mind to ensure that an Integration can’t increase its permissions without a user/organization admin accepting the change.


#7

What permissions set is necessary for creating issues with ‘assignees’ and ‘labels’ are set to some values when acting on behalf of an integration?

I tried with r/w ‘issues’ access, then with r/w ‘issues’ and r/w ‘content’ accesses both, but issues created w/o any labels and w/o assignees.


#8

Hi Josh!

We’d like to receive Push events without Code read access. At the moment you must have code read access to receive these events, whereas creating a non-Integrations webhook currently allows receiving Push events without any access to code.

This is a blocker for us with the new Integrations. We need to receive notifications when customers have pushed new code without being able to see the code itself. If we can figure this out then we’re raring to go!

Thanks!


#9

When using OAuth you are able to request permissions to read/write to all private repos that user has access to (including org repos), however when using Integrations the user can only install on their own repos (not org repos). For our application we need to be able to access (allow the user to install on to) all repos that user has access to.

Our application does not need or want write permissions to any repo so I’m stuck between using OAuth which allows us access to all repos a user can access but forces us to ask for write permissions when we do not want it, or using Integrations which allows us read-only access to private repos but doesn’t give us access to org repos that user has access to. It seems like it should be possible to do this with Integrations by simply emitting an “integration_installation_repositories” event when said user gets removed from an organization.


#10

Workaround: It’s possible to assign developers and add labels using separate API endpoints (which ends with ‘assignees’ and ‘labels’). ‘Issues’ access is enough.


#11

I’d like for a customer to be able to lock our integration to a particular file or file type, not just have repo-level permissions.
(GHE as well as GitHub.com)


#12

Hey @Totktonada

This was a bug on our end, you should now be able to create an issue with labels, milestone, and assignees with just the issues write permission on an integration.

Please let me know if you run into any issues.

Thanks!


#13

That’d be fantastic.


#14

Adding and removing permissions is a much needed feature, especially when developing the integration you need to delete the current one and create a new one with extra permissions (so you will need to update some data in your code like integrationId, privateKey etc)

When can we expect to see some system to change permission (even only for development as a start)?


#15

When using an installation token with git the installation token does not respect the “Allow edit from Maintainers”, meaning that I not only need the integration to be installed on all the repository I’m interesting on having it, but also I need to ask all the contributors to activate the integration on their fork. Which is a bit annoying.

Could the git endpoint also respect the allow edit from maintainers when using a token from an integration with the right permissions ?

Thanks.


#16

Allowing the integration owner to tweak permissions (and users to accept) sounds like a great plan @jmilas.

I am also wondering about supporting changing permissions driven from the user.

For our case we need full repo contents read/write to provide 100% of our functionality. However, there is still a large feature set that could be provided with only repo read. And some customers may prefer to do a read-only integration.

So one way it may work is for the integration to declare a minimum and maximum set of permissions and let the user decide what to opt-in/opt-out of.

I suppose we could work around this by providing two integrations: a read only and a read/write. But this seems less elegant. What do you think?


#17

For our case we need full repo contents read/write to provide 100% of our functionality. However, there is still a large feature set that could be provided with only repo read. And some customers may prefer to do a read-only integration.

Ah that’s an interesting situation, @clintam. Thanks for sharing the use case and request. Based on the initial functionality we plan to ship around editing permissions, two separate Integrations would be the way to achieve this.

As we evolve this functionality, we may look to implement a more seamless way to achieve something like this. While it’s not something we have planned yet, I’ve created an internal note to consider this request in the future.


#18

It looks like you’ve shipped the ability to change installation permissions - thanks for that @jmilas and co.

Two bits of feedback on the email that installation owners get sent:

  1. The link HTML is being escaped, so appears as an tag in the email rather than being rendered.
  2. The link works for personal installations, but is invalid for org installations. For org installations you need to add "/organizations/<org-name>" between github.com and /settings/installations/<id>/permissions/update

#19

Also, if you remove permissions, installation admins still get an email asking them to accept the update. I imagine you could just auto-accept (possibly with an after-the-fact notification) if permissions are only downgraded.


#20

Just clicked through to update the permissions for an integration and saw the following:

The permission update that should have been shown is a request for webhooks for issues. Guessing it’s a bug that it’s not there? I also didn’t receive an email (yet) about the request for updated permissions.