-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Improve import project user experience #1695
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
Conversation
Adds filtering handling, better error reporting to all failure points, and redirects to a populated for to importing the project.
This finally starts combining the import project pages into a single page. This page has a list of remote repositories, CTA buttons to signup when you aren't, and a backup button to manual import.
This adds matches to the model and serializer
When the repo is private and we don't have admin access, don't automatically import the repo, as we can't set up webhooks/etc.
This intercepts the task after return to reapply the local task state, and include the error message which resulted as a retval to the task on exception.
@@ -0,0 +1,252 @@ | |||
var ko = require('knockout'), | |||
$ = require('jquery'), | |||
tasks = require('../../../../core/static-src/core/js/tasks'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is super ugly. Is there not a better way to path this stuff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I hate this pattern as well. It's silly that browserify doesn't include the path it's running from by default, giving you addressable modules of readthedocs/core/js/whatever.js
. I've patched the browserify instance to handle this and it's much prettier.
Looks good to me. I only had a couple small nits, and a couple questions/comments. 👍 |
# if projects: | ||
# repo.matches = [project.slug for project in projects] | ||
# else: | ||
# repo.matches = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ericholscher just realized i meant to ask about this, and if we felt this extra lookup is important. I take it this was added to cover old repositories that were imported before github integration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, we don't have any standard of repo URL in the project, so they can have a number of formats. (eg. git://, https://, .git, no .git)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could also be okay saying that if you didn't import via github, we don't disallow import again from github connected accounts. The most correct solution here is an intermediary table Project
<-> RemoteRepo
of course, which we'll have to make the same decision on when we go to run migrations there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I think we need explicit mapping, and doing real tracking/resolution would require forcing GH auth and requiring that, which I'm not super excited to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say we just poll whats already available in the RemoteRepository
table when we do, don't worry about forcing auth or making sure it's up to date. The problem there will be of course how we handle syncing the repos and ensuring relations of Project
<-> RemoteRepository
stick.
I'll add the ghetto url stuff back in for now here
renderer_classes = [JSONRenderer, BrowsableAPIRenderer] | ||
serializer_class = RemoteOrganizationSerializer | ||
model = RemoteOrganization | ||
queryset = RemoteOrganization.objects.all() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These querysets aren't filtering by user at all, which means they return every project for every user.
Also adds test cases for user filtering on repo/orgs
Okay, addressed the incorrect template issue and filtering in the last few commits. I believe that should wrap up work on this for now. There is definitely some room for improvement on filtering -- I see the next version of this having a fuzzy search bar. |
Improve import project user experience
This makes a number of changes to a fairly deficient UI. It still doesn't
provide an interface for importing multiple projects at once, but that could be
added easily once we have a public task for importing projects.
Frontend changes:
Backend changes:
eval
, data is JSON serializedStill needed:
Also, note: CSS changes particular to RTD.org are in
core.css
, which general styling is done in the LESS source. This is because RTD.com should avoid this styling, as list styling is not compatible.Fixes #1670