Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix StripeConnectAccount #596

Merged
merged 1 commit into from
Jan 2, 2017
Merged

Fix StripeConnectAccount #596

merged 1 commit into from
Jan 2, 2017

Conversation

joshsmith
Copy link
Contributor

@joshsmith joshsmith commented Dec 31, 2016

What's in this PR?

Attempt to fix StripeConnectAccount's update fn to allow for updating.

@begedin
Copy link
Contributor

begedin commented Dec 31, 2016

I did some long overdue fixes here, which we needed due to some of the changes the PR contains

  • MapUtils.keys_to_string now does a deep transform and also supports lists
  • The json_payload ExMachina strategy has been replaced with a more accurate build_json_payload helper.
  • Added an :update policy for stripe connect account, still needs testing

Note on replacing strategy

The strategy had several problems. The first one is that it uses the associated record's default view in order to serialize. The problem there is that it wrongly assumes that the attributes we send in a :create or an :update request is the exact same set we receive back in a :show

This is wrong for several records now.

Additionally, it adds all attributes defined by the view to the payload. A PATCH request by definition should only contain the attributes that are changed. The new helper supports that definition.

@begedin
Copy link
Contributor

begedin commented Dec 31, 2016

Started cleanup of model tests

Added two new helpers, assert_validation_triggered(changeset, field, type) and assert_error_message(changeset, field, message). This allows a more generalized approach to checking changeset validation errors so it's a just a matter of replacing the existing assertions with these.

begedin
begedin previously requested changes Jan 1, 2017
Copy link
Contributor

@begedin begedin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have a question on one bit of code, but that's about it for now. Took me a while to get through.

@@ -93,17 +125,31 @@ defmodule CodeCorps.StripeService.Adapters.StripeConnectAccountAdapter do
|> Map.take(@non_stripe_attributes)
end

defp remove_read_only_values(attributes, [head | tail]) do
remove_read_only_values(attributes, head)
remove_read_only_values(attributes, tail)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this work? Seems to me like it only returns the result from removing read only values from the final item in the list (after it recursively gets through the tail). Are we missing some chaining here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should remove this altogether, actually.

def transform_attributes(attributes, mapping) do
attributes_map = map_keys_to_atoms(attributes)
mapping |> Enum.reduce(%{}, &map_attribute(&1, &2, attributes_map))
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might not be a bad Idea to have a unit test for this specifically. Separate issue might be good enough for now, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 for separate issue.

Copy link
Contributor

@begedin begedin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor questions. Otherwise seems good to go.

%{
amount: 1, # in cents
currency: "usd",
id: "month",
id: "month_project_" <> to_string(project_id),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean month_plan_ here or is _project_ intentional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@begedin project is intentional since plans are per-project.

@@ -62,6 +62,36 @@ defmodule CodeCorps.StripeService.Adapters.StripeConnectAccountAdapter do
{:verification_fields_needed, [:verification, :fields_needed]}
]

@stripe_update_read_only [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still used for something? I tried searching for it through the file but got nothing.

else
{:error, %Ecto.Changeset{} = changeset} -> {:error, changeset}
{:error, %Stripe.APIErrorResponse{} = error} -> {:error, error}
_ -> {:error, :unhandled}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will likely want to sweep through the code at some point and remove these _ -> unhandled cases. They basically swallow any unexpected errors in the process. We should explicitly list any failures we support and handle. If anything unexpected fails, we should treat it as a bug.

This is basically equivalent with us wrapping a huge chunk of code into a try-catch that catches any sort of exception.

Update view

Modify MapUtils.keys_to_string to do a deep transform

Add update policy for connect account

Replace json_payload strategy with more accurate build_json_payload helper

Fix model tests

Update Stripe

Add necessary sweet_xml for arc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants