Not sure if we should change the actual model, or just in the UI...

If one user has added a bank account and has not yet verified it, and another user tries to add the bank account, Balanced raises an exception when we try to create the test deposits:

Balanced::PaymentRequired(402)::Payment Required:: POST
https://api.balancedpayments.com/bank_accounts/BA7GwdoWxHBMg7GIRH3Zf7pB/verifications:
bank-account-credit-declined: 440t: There is already a verification
pending for this bank account Your request id is
OHMfdb46652b63411e4adbd02b12035401b. -- There is already a
verification pending for this bank account

We should catch this exception and display a nice error to the user.

So they're easier to find.

Perhaps a timing issue with puffing-billy.

Use the Pretender gem or something similar.

Students should be able to view their submission in order to see the feedback they got from the teacher's review. Here's a wireframe of the basic look:

The path for this view should be /assessments/:id/submission (note the singular submission) and will route to submissions#show. This route already exists, it's just an important thing to keep in mind.

For now, do not worry about being able to add a code block to the notes. Later we will add the ability to parse the notes from markdown to HTML.

We must first close oesmith/puffing-billy#79.

I think this ENV variable is the reason why tests are failing on my end. What can I set this to to get my tests to pass?
I don't have these set:

FROM_EMAIL_PAYMENT

FROM_EMAIL_REVIEW

Currently, we don't do anything when a bank account verification succeeds or fails. We should:

• see if we get notified by a Balanced callback;
• assuming there is one, update the status of the account or destroy it;
• notify the user by email.

When a student creates an account, have them sign the enrollment agreement and refund policy before they can make their payment. Use the HelloSign API.

The database HEROKU_POSTGRESQL_AMBER_URL on Heroku app epicodus-payments is approaching its allocated storage capacity.

The database contains 7,676 rows. The Hobby-dev plan allows a maximum of 10,000 rows. If the databases exceeds 10,000 rows then INSERT privileges will be revoked, preventing more data from being written. INSERT privileges are automatically reinstated if rows are removed and the database once again complies with the plan limit.

To avoid a disruption to your service, migrate the database to a Basic ($9/month) or higher plan:

https://devcenter.heroku.com/articles/upgrade-heroku-postgres-with-pgbackups

Specifically, when a student signs their docs and pays, update their Close.io status using the Close.io API.

implement Balanced callbacks so we can get notified of failed bank payments.

If a payment fails, its status is changed to "failed", but it is still counted in the totals.

This is a way for admins to view how students have done on an individual assessment.

When submission are first created, they need to be flagged as needing review. After they have been reviewed, that flag should be removed. If the student resubmits, it should be flagged again as needing review.

Probably one of the more simple ways to handle this is by using callback in the submission model (after_create and after_update).

It would literally save me hours if we could view the notes included with assessment reviews for each student in the grades report view. This would allow me to do quite a few things:

• When I have done a good job of explaining an error for one student, and then later another student makes the same mistake, I could go to the grades report and copy / paste the explanation.
• I could see at a glance what a student needs to work on and what I should check in with them about. For example, there's some people where I feel like I've explained to them why a detailed commit history is really important a couple times. So if I have an easy way of checking to see if I have already explained something fully or not, then I can either check on them in person during class or change the way I'm phrasing my explanation in the feedback to be a bit more direct: "As per last week's feedback, you still need to work on making more commits. If you need more information about that, come and talk to me." Instead of sounding like a broken record and reiterating an entire paragraph about how it's easier to track down bugs if everything isn't all squished into one commit.

Even if all tests are passing at 4:59, they'll fail at 5pm. This caused the lasted build to fail even though the changes had nothing to do with the code.

When a student visits the show page for an assessment, they should be able to see the title, description, and requirements for that assessment. They should also be able to submit a link for their assessment or navigate to their submission once it has been graded. Some of this is already built out, but it needs to be styled appropriately. Here is a wireframe of the basic style:

Do not worry about teacher specific elements. That should be added later.

So they can see which days they were late/absent and ask to have them fixed.

Right now urls when viewing an assessment look something like this: /assessments/3.
This should be changed to /assessments/ruby-oo.

We should use FriendlyId for this.

So that we can easily switch to having them come from someone other than Michael. Probably just use an env var.

Description

Rian and Luke are building an internship and ratings application in Sinatra. I am looking at what it would take to port the idea is to port it into the Epicenter.

Summary of additions

We would need to add only ( I think) 2 models. Internship & InternshipRating. Internships would belong to a cohort to keep them organized by class. InternshipRating would use a join table, belonging to a user and an internship.

2 controllers and associated routes
Internship with actions index, show, new, create, edit, update, delete
InternshipRating with actions new, create, edit, update

Views with their supported admin only features

Model specs, controller specs, integration spec

Anything else?

Is there something I didn't cover in here that I would need to make this a useful addition to epicenter?

To start, let's figure out the simplest way to show this. Later on, we can add some more complex stuff like reporting or heat maps or whatever.

Balanced will stop processing credit and debit card charges and ACH debits on June 11, 2015. See https://www.balancedpayments.com/stripe for migration instructions.

Current method to calculate credit card fee:

def calculate_charge(amount)
    ((amount / BigDecimal.new("0.971")) + BigDecimal.new("0.3")).to_i
 end

Since all amounts are stored in cents, we are currently adding 0.3 of a cent instead of 30 cents for the transaction fee.

New method:

def calculate_charge(amount)
    ((amount / BigDecimal.new("0.971")) + 30).to_i
 end

Right now the logic that handles sorting students on the assessment report is in the view. This is not ideal. We eventually need to add a scope to handle this. Unfortunately, the way we calculate student score is through a fairly hairy method Assessment#final_total_score_for(student). That method will have to be cleaned up before this can be solved.

Waiting on reply from Balanced support.

Since many people work from home, etc

Ideally, when creating a new review, it'd be helpful if the grades and notes were pre-filled with values from the previous review. My first inclination is to have the form edit the review rather an creating a new one. However, this would prevent us from having a history of reviews (something I'm not even sure we want). The other option is to somehow populate the new review with values and associations of the last review. Exploring this avenue proved hairy, though I'm not totally ruling out that option. Eventually, this should be fixed.

We were trying to figure out a way that users could log-in from their paired computer in class, rather than having the master check-in. We noticed that devise keeps track of the ip you are currently signed in on.

Could we use the Epicodus IP to validate that you are at school, on the epicodus network to make sure that you are checking in at school. Would there be a better way to verify this?

Use Devise Invitable.

For students who forgot to sign in.

Often, a student will want to pay their tuition on a couple different cards or bank accounts. We should provide a way for students to enter the amount they'd like to be charged and what payment method they'd like to use.

Need to be able to withhold a $150 enrollment fee.

When a student views a assessment (or the list of assessments) they should see different information on whether or not they have made a submission for that assessment, and if that submission has been reviewed. For now, we just need way for determining this status. We will worry about using them in the views later. Here's a couple of quick thoughts:

# A user method that can be called on current_user
class User
  def has_submission_for(assessment)
    ...
  end # returns true or false
end

Or

# An assessment method where you pass in current_user
class Assessment
  def has_been_submitted_by(user)
    ...
  end # returns true or false
end

For students who forgot to sign in on time.

New exception in epicodus-payments

Balanced::BadRequest · bank_accounts#create
Balanced::BadRequest(400)::Bad Request:: GET https://api.balancedpayments.com/bank_accounts/BA2jRNMs3utNfKJvRDAZz4x1: invalid-routing-number: Routing number is invalid. Your request id is OHM4d4e898e9daa11e484ce02b12035401b.

STAGE
production

SEVERITY
error

URL
https://epicenter.epicodus.com/bank_accounts

Stacktrace summary

app/models/verification.rb:8 · initialize
app/models/bank_account.rb:20 · new
app/models/bank_account.rb:20 · create_verification
app/controllers/bank_accounts_controller.rb:9 · create

To Do

• Allow users to add multiple payment methods (credit cards / bank accounts)
• Display all payment methods to user, including those that are pending
• User can change any of their payment (non-pending) payment methods to be the primary
• User can delete payment methods, except if it is the primary?

Done

• The first payment method entered should default to the primary method
• Display which payment method (payment type + last 4 numbers) was used for each payment (payments#index)

This looks like leftover code that needs to be removed. I believe it's from before we had the review model, which should belong to a teacher (admin).

We need a view that allows teachers to see all the submissions for an assessment. The url should look like /assessments/:slug/submissions (notice the plural submissions) and map tosubmissions#index`.

The list of submissions should be scoped to those flagged as needing review and ordered by date submitted (ASC).

Each list item should expand to show a form for creating a review for that submission. This can be done with AJAX or just jQuery.

Here's a basic wireframe:

As reported by a student - not verified.