Question about plaid-ruby HOT 19 CLOSED

@hosh The standard route should be to check the @accounts to get any account. For some reason it seems that the account is being added to the user rather than to the accounts array. I'll have a look at this ASAP.

from plaid-ruby.

Cool 👍

from plaid-ruby.

@j4ustin another question:

I noticed that the Account class has an institution type. That implies that a single user can auth against multiple institutions. Is this correct? If so, how does that work?

This is important since it effects my code, whether or not I add an additional 'link' model for my current code (as well as paying for another Plaid user).

from plaid-ruby.

@hosh

Correct.

So a single user can have multiple bank accounts tied to them. For instance: I can have a credit card with Bank of America, a checking account with Chase, and a loan with USAA. You can easily identify this user based on your application set up, knowing that the unique user entered the credentials themselves, but Plaid (and this Gem) won't have enough information to link those three institutions to one unique user.

You'll need to link your User model to each auth token they receive from Plaid in order to recall those accounts in the future. There are no helper methods to reconstruct a user currently in the gem, but there needs to be. I'll add this as another issue.

from plaid-ruby.

Ok, so basically, I can use the same Plaid::User model to do multiple auths / load in all access_tokens. This will link a single end-user across institutions/accounts. Would that register on Plaid's end that they are the same user?

from plaid-ruby.

Nope. Neither would it register on the gem as one user cannot store multiple test_tokens. One auth_token per user. Since the gem cannot persist users once uninitialized this is the safest route to take.

You should think of each Plaid::User as one institutional account. Each of these can have many accounts, and each account can have many transactions.

You should link these Plaid::User models to an instance of your User model in a one (User) to many (Plaid::User) fashion. I'll release a helper method that will allow you to quickly reconstruct and use a Plaid::User account.

from plaid-ruby.

Ok, gotcha. That's what I figured. I'm storing the access_token each as a "link" which is then collected by our app's user.

Thanks!

from plaid-ruby.

@hosh

I've been unable to recreate this issue. Users do not have a Plaid::User::Account parameter attached. This would throw an error in the case above.

Can you post the exact methods you used to create the issue?

from plaid-ruby.

@j4ustin I used the command from the README:

user = Plaid.add_user('auth','plaid_test','plaid_good','wells')

Also, from my Gemfile.lock:

vagrant@rails-dev:~/src/wherewithal$ cat Gemfile.lock | grep plaid
    plaid (1.4.0)
  plaid (~> 1.4.0)

from plaid-ruby.

Another question: Carl says that there is a subtype field that would allow me to determine whether an account is a savings or a checking account.

However, I don't see that field in the gem, and I didn't see it anywhere in the API. I do see a depository in the test account. Is that something that is a quirk of the test account?

from plaid-ruby.

@j4ustin Found the bug. You're creating a new instance variable when you do this:

https://github.com/plaid/plaid-ruby/blob/release_v_1.4/lib/plaid/user/user.rb#L116

from plaid-ruby.

Likewise here: https://github.com/plaid/plaid-ruby/blob/release_v_1.4/lib/plaid/user/user.rb#L123

If those new ones are supposed to be part of @accounts and @transactions then they need to be added to those arrays. If @accounts and @transactions are meant to be representative of what comes back from the server, then maybe these instance variables should be renamed to something else

from plaid-ruby.

@j4ustin Yeah. I don't know the history of who wrote this Ruby gem. I've seen a lot of weird things like that. Here's another example:

https://github.com/plaid/plaid-ruby/blob/release_v_1.4/lib/plaid/user/account/account.rb#L10

I don't know what the intention of having #new as an object method (as opposed to a class method), but both #new and #update_account does the exact same thing. They really should be merged into a single method.

The implementation of the method itself is not written in idiomatic Ruby, and the way some of it is written is made more complicated than it needs to be.

Since this is going to be a critical part of Wherewithal's infrastructure, what I'll be doing is putting together a series of PRs fixing all of this.

from plaid-ruby.

@hosh

Got it. I'll push up a fix for this momentarily.

The whole thing was written and maintained by myself. I haven't had too many other eyes on it (one code-review before launch + other people integrating the gem) so there are plenty of things that could use cleaning.

I don't see a subtype in the api docs, if you spot it in live accounts please add it to the parameters accepted by the account.

from plaid-ruby.

@j4ustin sounds like you guys been really busy.

Have you considered using something like RestClient or Faraday instead of Net::HTTP?

I don't see subtypes in the API docs either, was hoping you would know it. I'll ask Carl again.

from plaid-ruby.

@j4ustin here's another question:

https://github.com/Wherewithal/plaid-ruby/blob/release_v_1.4/lib/plaid/util.rb#L10

That suggests that the API accepts CGI-encoded data for the input. Does the API accept JSON instead?

If not, is that why the options in connection data has to be JSON-encoded?

Sorry about piling on all these questions on this single issue here.

from plaid-ruby.

@hosh

I'm actually not a part of the Plaid team, but really like what they do so I help maintain some community libraries. Outside of that I am super busy, so these pushes come usually pretty late at night.

The goal of this gem was to have 0 runtime dependencies, so everything had to be written from scratch using only what ruby comes with out of the box. That means a lot of it is a bit longer than it needs to be, and I'm sure lots of it can be refactored (I think I've only done one refactoring pass since its initial release). I appreciate any help I can get from here on out cleaning up the library.

How about we start adding new issues as you come across them and get ready for a 1.5 build with everything a bit more cleaned up?

from plaid-ruby.

@hosh I've added a fix for this issue in V1.4.3

from plaid-ruby.

All right. I wasn't sure what the plan was with everything.

I respect the zero runtime dependency. I think there is a way to write it so that if I want to monkey patch the back-end with a different HTTP handler, I should be able to. I'll start adding some issues or PRs that contains small amounts of refactoring then.

from plaid-ruby.