Skip to content

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

Closed
humitos opened this issue Jul 19, 2022 · 10 comments · Fixed by #11498
Closed

OAuth: Connect Project to RemoteRepository automatically #9437

humitos opened this issue Jul 19, 2022 · 10 comments · Fixed by #11498
Assignees
Labels
Improvement Minor improvement to code

Comments

@humitos
Copy link
Member

humitos commented Jul 19, 2022

(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 their RemoteRepository in these situations:

  • a user connects a social account that matches projects already imported
  • a user imports manually a project with a Project.repo URL that does not match exactly, but following the redirects, it does
  • a user re-sync their connections and a newer/updated RemoteRepository matches the URL immediately (or after following the redirects)

There are probably more situations that I'm missing here, but feel free to add them to this bullet list if you know more.

We could write some code to cover these cases and keep the data as much synced as we can while using a OAuth application.

@humitos humitos added Improvement Minor improvement to code Needed: design decision A core team decision is required labels Jul 19, 2022
@humitos humitos moved this to Planned in 📍Roadmap Jul 19, 2022
@humitos humitos self-assigned this Jul 21, 2022
@agjohnson
Copy link
Contributor

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.

@humitos
Copy link
Member Author

humitos commented Sep 1, 2022

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.

@humitos
Copy link
Member Author

humitos commented Mar 12, 2024

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 RemoteRepository.full_name or similar field.

@humitos humitos removed their assignment Mar 12, 2024
@humitos humitos removed the Needed: design decision A core team decision is required label Jun 20, 2024
@humitos
Copy link
Member Author

humitos commented Jun 20, 2024

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 RemoteRepository to that Project. This means that we don't know what's the default branch for that project, and our code has hardcoded master. Since the project uses main as the default branch, our code fails when cloning the repository.

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

@agjohnson
Copy link
Contributor

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.

@humitos
Copy link
Member Author

humitos commented Jul 1, 2024

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 Project.repo URL with the RemoteRepository.clone_url or similar ones. However, the other 20% of times could be covered by manually selecting the repository by the user as you mentioned.

IMO, we should focus right now into the 80% and leave this 20% of times for a following iteration.

@agjohnson
Copy link
Contributor

agjohnson commented Jul 1, 2024

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.

@agjohnson
Copy link
Contributor

For example, eventually I want to resurface this UI on reconnection:

image

But to start, a simple dropdown is plenty. Right now, the remote repos are loaded through the API, so I'd see us using that over a model form field eventually.

@stsewd
Copy link
Member

stsewd commented Jul 11, 2024

So, if I understand this correctly:

  • We want to reconnect an out of sync project (the user changed the clone URL)
  • We want to reconnect projects that were manually imported
  • We don't want to do this automatically (I think?)

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.

@stsewd stsewd moved this from Planned to In progress in 📍Roadmap Jul 11, 2024
@agjohnson
Copy link
Contributor

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.

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.

Do we want to allow users to change that even if the current project URL matches?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Minor improvement to code
Projects
Archived in project
3 participants