Initial pass at Plaid EU #1555
Initial pass at Plaid EU #1555
Conversation
|
@zachgoll First high-level pass at adding EU support. You've got a better handle of how the Plaid stuff works, so let me know if I'm off base here. |
There was a problem hiding this comment.
I reached out to Plaid and they said there is no way to figure out whether an "Item" is US or EU just based on the Plaid Item data.
So the biggest thing we're missing currently here is that identifying piece of data stored on PlaidItem. I think since there are only 2 possible clients, we could consider a field called plaid_region that is a string and in our model we could probably validate that too:
class PlaidItem < ApplicationRecord
enum :plaid_region, { us: "us", eu: "eu" }
endWhich would then allow us to easily access it like, some_item.eu?
Otherwise, I think EU should work largely the same as US and I believe our existing implementation will properly handle these multi-currency accounts fine.
Signed-off-by: Josh Pigford <[email protected]>
|
@zachgoll Take a look now. |
| t.datetime "updated_at", null: false | ||
| t.index ["chat_id"], name: "index_messages_on_chat_id" | ||
| t.index ["user_id"], name: "index_messages_on_user_id" | ||
| end |
There was a problem hiding this comment.
Looks like we're still getting the extra tables here. You may need a full rails db:migrate:reset since db:reset will just rebuild based on this existing schema.rb and not perform the migrations
| @@ -5,6 +5,7 @@ def create | |||
| Current.family.plaid_items.create_from_public_token( | |||
| plaid_item_params[:public_token], | |||
| item_name: item_name, | |||
| region: plaid_item_params[:region] | |||
There was a problem hiding this comment.
The create_from_public_token method on PlaidItem will need to be updated to accept this param
| @@ -1,6 +1,9 @@ | |||
| class PlaidItem < ApplicationRecord | |||
| include Plaidable, Syncable | |||
|
|
|||
| enum :plaid_region, { us: "us", eu: "eu" } | |||
| validates :plaid_region, inclusion: { in: plaid_regions.keys } | |||
There was a problem hiding this comment.
The enum should have this inclusion validation already built-in, so we can remove the second validates here
No description provided.