fixed with mrmakeit/codesy node branch, but i cant figure out how to pull request a new branch

Need a local https solution for development so browser extensions' content scripts can use local API.

Supersedes #36

Because PuSH requires admin permission to the repo, instead we'll create a cron job that checks the status of all issues in codesy.

For now, when the cron job finds an issue has changed from 'open' to 'closed' or 'merged' etc., it should send an email to all users who made bid with offer > 0 like, "[codesy] A bug on which you offered a bid has been marked [closed|merged]."

Ideas for the future:

• Send a custom email to users who offered at or above the median offer, telling them that they are part of the payout approval panel.
• Send an email to any collaborator on the bug who asked for less than the total offered amount: Tell them that, if they fixed the bug, they can claim they payout.

https://github.com/codesy/codesy/blob/master/codesy/settings.py#L19-L20

Our .travis.yml triggers a deployment for each of the env entries. So, we deploy to heroku 3x. We need to clean that up.

Steps to reproduce:

1. Merge something into master
2. Check the codesy-stage activity on heroku

Expected results:

• Only one deployment & build should happen

Actual results:

• 3 deployments & builds happen; 1 for each of the Travis jobs: i.e., style, docs, and python

https://blog.heroku.com/archives/2014/8/7/heroku-button

Automatically deploying from travis-ci to heroku is great, but it breaks our What's deployed dashboard because I was supplying that with a git pre-push hook.

http://codesy.readthedocs.org/en/latest/development.html#deploy

https://news.ycombinator.com/item?id=8542969

Might just be my local browser cache, but my local site has started bouncing me out of https on every other request. 😦

When the browser extension is not authorized and requests a bid form, we respond with 401 status. Right now, the extension just doesn't display. 😦

We should customize the 401 template to a simple "Sign in to codesy" template.

Then, the extension could simply render the contents of the 401 template in the widget space. I.e., codesy/widgets#34

To do codesy/widgets#27, we should make sure that the bid widget HTML works well in the new browser window dialog.

Working with gitwit

The auth token saved in local storage can be used even when the user is signed out.

The sign out option should trigger a function to delete the token.

See #97 and #131 last step: "... when a user is looking at a closed bug on which they had a bid"

I want to create Issues during initial bid first.

Django Rest Framework - as it should - enforces CSRF protection when using SessionAuthentication.

The browser extensions execute their form and AJAX requests from the bug domains. (e.g., github.com) So, the HTTP Referer - github.com - does not match the server-side domain - codesy.io, and the CSRF validation fails.

So, we need to change DRF to TokenAuthentication, which doesn't enforce CsrfMiddleware 'Referer' matching, and is probably better anyway. To do so, we should:

• Generate tokens when users register
• Show the user their token when they click to download the extension, and prompt them to copy it
• codesy/widgets#31

Steps to reproduce:

1. Sign in via GitHub
2. Fill in the Connect Payments form
3. Click Tokenize

Expected results:
Should see a "Payment Method added" message, and the "Connect payments" form should indicate there's already a payment form connected.

Actual results:
Nothing changes.

POST ing or PUT ing a bid form with out supplying a value will cause and error say that the field is required. If the field is left blank when submitted, the rest api should allow no value (so subsequent place holders in the form work) or at least set the value to zero.

Bonus Points: Detect if the user already has the add-on installed, and change the Call-to-Action from "Add to [Chrome|Firefox]" to "Sign up with GitHub".

C-C-C-Combo: If the user already has the add-on installed, and is already signed in with GitHub, change the Call-to-Action to "Add funds with Balanced"

We need the user's email address in their user account so we can email them if/when their bids are met.

• Add an SMTP heroku Add-on
• Configure code with SMTP config values
• Set up django-mailer cron jobs for heroku apps

Bids must be unique by user & url. Add unique_together to the fields to prevent duplicate bids.

bid form currently using relative /. Needs to include full domain and path

http://codesy-dev.herokuapp.com/ was built before Django 1.7 and I botched the migration. Need to replace it with the newly built http://mysterious-badlands-8311.herokuapp.com/

In #27, we remove the Profile model.

So, we need to restore a UserViewSet that receives the PATCH request when the user adds a credit card to their account.

When I get an email that my ask has been met, it should include, "If you fix this issue, claim your earnings here: https://codesy.io/claim/confirm?bid={{ bid.id }}"

So we need to:

• Create a new Claim model with fields: Issue (FK), Claimant (FK), created, modified, and status
• Wire the Claim model up with DRF API
• Add a confirm view at GET /claim/confirm?bid={id} with a form to POST /claim/ with the issue & claimant; auto-populating created and status=open
• Add a link to the confirm view to the notification email
• Load the claim confirm view into the widget
• ... when a user is looking at a closed bug on which they had a bid

https://github.com/marcgibbons/django-rest-swagger

1. Enter card info at sign-up, or when making first offer (#15)
2. Accumulate offers & asks for as long as it takes from as many people as it takes
3. When someone's ask is met, notify them by email (#37), including a link to claim the payout after they fix it. (#131) Include the make-what-you-want interface at the claim link. (#??)
4. When someone claims the payout, email all offering bidders that their card will be charged in 30 days to make the payout unless they dispute it
5. During the 30 days, all offering bidders approve or dispute the payout
6. At 30 days, or whenever all offering bidders approve, charge cards and send payments

GET /bid returns a form for POST or PUT bids. Need to reply with information that the issue was closed.

If you sign into codesy.io as http instead of https the widget ajax calls will fail.

Any way to re-direct to an HTTPS url?

Note: Need to keep track of which asks have already been notified.

Not sure how this was working before. But the fix is probably to use django-cors-headers.

Steps to reproduce:

1. Installed the Chrome extension
2. Go to any old github issue

Expected results:
Bid form shown

Actual results:
Extension makes this request:

OPTIONS https://127.0.0.1:8443/bid/?url=https%3A%2F%2Fgithub.com%2Fcodesy%2Fcodesy%2Fissues%2F75

and says

XMLHttpRequest cannot load https://127.0.0.1:8443/bid/?url=https%3A%2F%2Fgithub.com%2Fcodesy%2Fcodesy%2Fissues%2F75. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'chrome-extension://cchpcdoagjopolebepldmfpkcbfoigok' is therefore not allowed access. The response had HTTP status code 401.

Need to create a common template so that bid.html and 401 templates can use an {include} tag instead of repeated text.

See #61 (diff)

For codesy/widgets#25 we should create a post-install "first run" version of the landing page.

1. What is the average bug lifecycle?
2. How often do coders put 👍 comments on bugs?

While reviewing https://github.com/codesy/codesy/pull/44/files I noticed django_nose is only needed for tests, but it needs to be an INSTALLED_APP to work.

So, I propose we add the following to settings.py:

ENVIRONMENT_APPS = os.environ.get('ENVIRONMENT_APPS', [])
INSTALLED_APPS = DEFAULT_APPS + THIRD_PARTY_APPS + LOCAL_APPS + ENVIRONMENT_APPS

Then, we add the following to .env-dist: (and thereby .env):

export ENVIRONMENT_APPS=['django_nose',]
export TEST_RUNNER="django_nose.NoseTestSuiteRunner"

Then, we can move django-nose==1.2 from requirements.txt to requirements-test.txt so it only needs to be installed on local dev environments.

When I did the DRF 3.0 update, I found some errors only with spot-checking. So, we should create a higher-level suite of tests that test the key user flows that integrate many pieces:

• Test that user registration creates an authorization token
• Test that GET, POST, PUT, and DELETE of bids (via BidViewSet) work as expected
• Test that GETting the bid widget HTML (via GetBid APIView) works as expected

From the home page:

1. Click 'Add to browser'
2. The browser "first run" experience should open a new tab back to the codesy home page
3. The home page should now say "Sign in with GitHub"
4. After signing in with GitHub, the home page should include the user's API token (so the browser content script can grab it), and should show the "Connect payment method" form