-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
OAuth: Connect Project
to RemoteRepository
automatically
#9437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is it okay to move this to the backlog or bump out a sprint? I agree these are good use cases to polish though, I'm just doing some housecleaning on our sprints. |
I'm moving this to the backlog. This issue completes the work I've done in #8229, but it's definitely not a priority currently. |
I've been received a few support requests on Read the Docs for Business from users having troubles to re-connect their GitHub repository after it was renamed or moved from/to an organization. I had to re-connect them manually via the Django shell. This has impact over the GitHub status checks and also on permissions for organizations using GitHub SSO. I think it makes sense to prioritize this work and expose a button for users to re-connect the "Project -> RemoteRepository" if we find matching URLs between the clone URL and the |
I have another user hitting an issue related to this. When importing a project manually (they needed that for translations since the old dashboard cannot import the same project twice), we won't be connecting the The user was confused about why they have to manually define the default branch on the translation but not on the English project. https://app.frontapp.com/open/cnv_nawnxqf?key=opcPGB8DkaRtamvy7sFXomVNM-NuZXye |
I think we should prioritize some new UI to reconnect repositories, or whatever is the easiest method to give this functionality to users. I have hit this during account reconnection, and the resulting UX is that the project has trouble with basic functionality. Actions like reconnecting webhook integrations failed with somewhat generic errors, etc. In my case, I had imported a repository automatically, but tried to reconnect my account to solve a bug with the Oauth application connection -- this broke my project -> remote repo connection. It would be nice if we could automate this, but unless we can ensure we guess the correct repo to reconnect to, I suspect a user UI to select a repository might be easiest to manage overall. |
We can cover 80% of the times here, since we can match the IMO, we should focus right now into the 80% and leave this 20% of times for a following iteration. |
Maybe, though I feel like we should always be prompting the user for the repository to connect to, even if we feel we might be able to guess it. Guessing feels a bit like magic as the user won't know exactly what will happen with this process. The reconnection process should feel just like the initial project creation process, giving the user information on the repository and repository permissions and allowing explicit selection. While prompting, we can definitely suggest the repository we're guessing, but the user will always be in full control of this process. This feels the most right This could be super basic to start, I could see this being a project admin page even. If we are uneasy about giving access to this modeling directly, we can always do this with a form view or API view and use some front end UI similar to the project creation UIs. Either would give some form handling and error reporting to the user though, so much more information than an automatic process would. Given we know we want this UI eventually for the 20% or so that will not fit this pattern, or users that want to connect a new repository even, I saw we start with a model form view or similar. |
So, if I understand this correctly:
I was thinking of doing it automatically when the repo URL changed. But since we don't want to do it automatically. We could check that the repo changed, and if the remote repository doesn't match that repo, show a notification to ask the user to reconnect. Now, the "reconnect" action. Are you thinking of an option we expose to users? A dropdown like Anthony suggested. Do we want to allow users to change that even if the current project URL matches? I'm +1 on letting users decide the repo, but we may have some support requests about the users not finding the repo they want to connect to, maybe because of permissions or out of sync data, or maybe not that much. |
I agree we eventually might just want to reconnect some repos to a project automatically, but we'll still need UI for all of the cases where this pattern doesn't work. So I feel we should start with UI and then add magic on top instead of starting with magic and leaving use cases unsupported. Again, even a basic form should be enough. If we don't get past this step, at least users have a consistent way to fix their projects.
Yeah, I think we just allow this by default. Users won't need this option unless they are doing something like upgrading an old project, moving their repository, or trying to fix something else that is broken. Consistency sounds like nice UX here at least. |
(for reference see #8229 (comment))
I think until we are fully migrated to a GitHub Application we won't be able to have 100% accurate relations at any time in our database. However, in the meantime we are doing our best efforts to have this data synced as much as we can and it's seems it's working fine.
One thing that we are not handling is the auto-connect of
Project
to theirRemoteRepository
in these situations:Project.repo
URL that does not match exactly, but following the redirects, it doesRemoteRepository
matches the URL immediately (or after following the redirects)We could write some code to cover these cases and keep the data as much synced as we can while using a OAuth application.
The text was updated successfully, but these errors were encountered: