You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking into this deprecation notice which I keep getting emails about, it turns out preflight doesn't actually listen to those webhooks.. great news!
Unfortunately preflight really should be listening to those webhooks in order to figure out what repositories it, and the users who use it, have access to. At the moment we sync accessible repositories, in order to populate the dropdown for new checklists, when users log in to preflight. This ends up working out ok because the only time we care about preflight getting access to new repositories is when a user logs in to add a checklist to that repository anyway. But nevertheless it feels a little icky, and there are undoubtedly a bunch of edge cases that this approach doesn't handle.
The "right" thing to do here is probably to listen to these installation and installation_repositories events, and update accessible repositories at that time. Sadly we still need to keep track of repositories the user has access to, the simplest way being to continue to fetch them on login, in order to not show them only repositories they have access to the in dropdown.
The text was updated successfully, but these errors were encountered:
Looking into this deprecation notice which I keep getting emails about, it turns out preflight doesn't actually listen to those webhooks.. great news!
Unfortunately preflight really should be listening to those webhooks in order to figure out what repositories it, and the users who use it, have access to. At the moment we sync accessible repositories, in order to populate the dropdown for new checklists, when users log in to preflight. This ends up working out ok because the only time we care about preflight getting access to new repositories is when a user logs in to add a checklist to that repository anyway. But nevertheless it feels a little icky, and there are undoubtedly a bunch of edge cases that this approach doesn't handle.
The "right" thing to do here is probably to listen to these
installation
andinstallation_repositories
events, and update accessible repositories at that time. Sadly we still need to keep track of repositories the user has access to, the simplest way being to continue to fetch them on login, in order to not show them only repositories they have access to the in dropdown.The text was updated successfully, but these errors were encountered: