Closed txels closed 10 years ago
I've finally managed to have a first proof-of-concept fully working "integrate github account" workflow.
The way to see this working:
This is far from production code, no tests etc. as it was exploratory coding to figure out the actual way to integrate provider and core via angular. I think I've found the right approach. Let me know what you think.
@alexcouper this is ready for another review. I don't think I'll add any functionality in this prototype until we've discussed the items in the PR description.
I'll try to have a look at this in the next couple of days.
As an update - I've scheduled this in mentally for Thursday evening this week. I will aim to deliver!
I've tried this, but I get an error when I click on "assimilate github"
nternal Server Error: /providers/github/oauth-confirmed/
Traceback (most recent call last):
File "/Users/alex/.virtualenvs/ployst/lib/python2.7/site-packages/django/core/handlers/base.py", line 114, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/Users/alex/.virtualenvs/ployst/lib/python2.7/site-packages/django/views/decorators/http.py", line 41, in inner
return func(request, *args, **kwargs)
File "/Users/alex/Work/pretenders/ployst/ployst/github/views/oauth.py", line 44, in receive
exchange_for_access_token(request.user.id, request.GET['code'])
File "/Users/alex/Work/pretenders/ployst/ployst/github/views/oauth.py", line 79, in exchange_for_access_token
client.set_access_token(user_id, 'github', token)
File "/Users/alex/Work/pretenders/ployst/ployst/core/client.py", line 151, in set_access_token
'token': access_token,
File "/Users/alex/Work/pretenders/ployst/ployst/core/client.py", line 41, in post
return self._http('post', path, data)
File "/Users/alex/Work/pretenders/ployst/ployst/core/client.py", line 33, in _http
response.content)
UnexpectedResponse: 401: {"detail": "Authentication credentials were not provided."}
[06/Jun/2014 22:17:12] "GET /providers/github/oauth-confirmed/?code=ce3131709e654c364bf8&state=ChAnGeThIsOnPrOdUcTiOn HTTP/1.1" 500 95207
Hmmm. That is part of the existing Oauth workflow that I haven't really modified in this PR.
Does that workflow still work for you in develop
?
I guess this may be due to missing credentials, maybe your ployst core API token has been lost due to DB cleanup (check http://localhost:8000/admin/apibase/token/)... According to your settings, in order to run this you need to ensure the env var GITHUB_CLIENT_SECRET
is set [1]
(this doesn't seem to be your problem, as it's failing for you after returning from Oauth).
[1] I made myself a run
script as I always forgot that bit. E.g.:
GITHUB_CLIENT_SECRET=230d9e65... ./manage.py runserver $* --settings=ployst.settings.dev_cba
Hmm, OK I'll double check, but thought I had confirmed that I only deleted the user key. I too have such a script, I'll play with it a bit and see what is wrong.
I'm at the summer house at the moment in 20° C - hopefully the weather is like this next month!
BTW this is what it should look like, once you manage to get through oauth:
I reproduced your error by removing my API token (http://localhost:8000/admin/apibase/token/). I've added a more informative error log message for now.
looks good and works well.
Do we care about github teams as well?
For now let's say "no".
I think as a user I'd expect "import as team" to somehow give access at least to the users who are in the team - but I think we need to be very careful at this point because a user who has been removed as a collaborator of a repo in github should also be removed from accessing data in ployst. An option would be for user to have to add in a process that makes it clear he is responsible to maintain the relationships?
Decide which options we'll give to import organisations as teams and repos as repos within new or existing projects
I'm not certain this answers your question, but I think that we should allow users to select n repos from an org and import into a team - be it new or existing.
This is a collection of the import options I was thinking of, trying to go from "a default setup with minimum clicks" (that you can later edit) to a cherry-picking approach. Some combinations of these could be possible:
So I'd like to pick which make most sense, as priorities. Limit ourselves to the minimal preferred set.
With only approaches 1 and 2 we should later at least allow joining projects or moving repos across projects?
Are you happy for me to merge this?
sure :)
Starting integration of Github provider configuration.
This is a partial implementation that:
Pending implementation:
For further discussion: