Permalink
Commits on May 16, 2018
  1. Merge pull request #650 from stripe/brandur-fix-tests

    brandur-stripe committed May 16, 2018
    Fix some parameters being sent in tests
  2. Add missing magic comment

    brandur committed May 16, 2018
  3. Fix some parameters being sent in tests

    brandur committed May 16, 2018
    I found a bug recently in stripe-mock which causes it not to actually be
    validating that parameters not in the spec are not being sent (the
    actual Stripe API does check for this).
    
    After applying a fix, I found that stripe-ruby's test suite no longer
    passes against it, and the reason is that there are some subtle mistakes
    throughout. This patch corrects them to be in line with what the API
    actually expects.
Commits on May 10, 2018
  1. Bump version to 3.15.0

    brandur committed May 10, 2018
  2. Merge pull request #649 from stripe/brandur-frozen-strings

    brandur-stripe committed May 10, 2018
    Add `frozen_string_literal` to every file and enforce Rubocop rule
  3. Add `frozen_string_literal` to every file and enforce Rubocop rule

    brandur committed May 10, 2018
    Adds the magic `frozen_string_literal: true` comment to every file and
    enables a Rubocop rule to make sure that it's always going to be there
    going forward as well.
    
    See here for more background [1], but the basic idea is that unlike many
    other languages, static strings in code are mutable by default. This has
    since been acknowledged as not a particularly good idea, and the
    intention is to rectify the mistake when Ruby 3 comes out, where all
    string literals will be frozen. The `frozen_string_literal` magic
    comment was introduced in Ruby 2.3 as a way of easing the transition,
    and allows libraries and projects to freeze their literals in advance.
    
    I don't think this is breaking in any way: it's possible that users
    might've been pulling out one of are literals somehow and mutating it,
    but that would probably not have been useful for anything and would
    certainly not be recommended, so I'm quite comfortable pushing this
    change through as a minor version.
    
    As discussed in #641.
    
    [1] https://stackoverflow.com/a/37799399
Commits on May 9, 2018
  1. Bump version to 3.14.0

    brandur committed May 9, 2018
  2. Add support for v1/issuer_fraud_records endpoints (#645)

    fay-stripe authored and brandur-stripe committed May 9, 2018
  3. Merge pull request #648 from stripe/fay/update-version

    fay-stripe committed May 9, 2018
    Upgrade `stripe-mock` to v0.16.0
  4. Update minimum version of stripe-mock

    fay-stripe committed May 9, 2018
Commits on May 7, 2018
  1. Bump version to 3.13.1

    brandur committed May 7, 2018
  2. Merge pull request #647 from stripe/brandur-merge-query-params

    brandur-stripe committed May 7, 2018
    Merge query parameters coming from path with `params` argument
  3. Merge query parameters coming from path with `params` argument

    brandur committed May 7, 2018
    If specifying both query parameters in a path/URL down to Faraday (e.g.,
    `/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
    (e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
    in the path with the ones in the hash. This can cause problems where
    some critical parameters are discarded and causes an error, as seen in
    issue #646.
    
    This patch modifies `#execute_request` so that before going out to
    Faraday we check whether the incoming path has query parameters. If it
    does, we decode them and add them to our `query_params` hash so that
    all parameters from either place are preserved.
    
    Fixes #646.
  4. Merge pull request #644 from stripe/brandur-stripe-mock-0-15

    brandur-stripe committed May 7, 2018
    Move file upload tests over to be handled by `stripe-mock`
Commits on May 4, 2018
  1. Merge pull request #643 from stripe/brandur-configuring-version

    brandur-stripe committed May 4, 2018
    Add a README section for globally configuration an API version
  2. Add a README section for globally configuration an API version

    brandur committed May 4, 2018
    I don't remember why I wrote this originally, but found it sitting
    locally uncommitted. It seems like a useful example to have in the
    README, so add it in.
  3. Move file upload tests over to be handled by `stripe-mock`

    brandur committed May 4, 2018
    `stripe-mock` can now respond accurately for file API endpoints thanks
    to a few improvements in how it handles `multipart/form-data` payloads
    and the OpenAPI spec.
    
    Here we upgrade `stripe-mock` to 0.15.0 and remove the manual stubbing
    that we had previously.
Commits on Apr 11, 2018
  1. Bump version to 3.13.0

    brandur committed Apr 11, 2018
  2. Merge pull request #634 from stripe/alexander/flexible-billing

    brandur-stripe committed Apr 11, 2018
    Flexible/Metered Billing API support
  3. flexible billing primitives and tests

    alexander-stripe committed Apr 4, 2018
Commits on Apr 10, 2018
  1. Merge pull request #638 from stripe/brandur-stripe-mock-v0.12.0

    brandur-stripe committed Apr 10, 2018
    Upgrade `stripe-mock` to v0.12.0
  2. Fix one test that was incorrectly expecting a non-deleted object back

    brandur committed Apr 10, 2018
  3. Upgrade `stripe-mock` to v0.12.0

    brandur committed Apr 10, 2018
    The most important changes here are that deleted objects are now
    represented more accurately, and that IDs used in URLs are "reflected"
    back into responses so that test suites can treat return objects a
    little more realistically than they could before.
    
    This should resolve incompatibilities between `stripe-ruby` and newer
    versions of `stripe-mock`.
Commits on Apr 5, 2018
  1. Bump version to 3.12.1

    brandur committed Apr 5, 2018
  2. Merge pull request #636 from stripe/brandur-initialize-instance-var

    brandur-stripe committed Apr 5, 2018
    Initialize instance variable on the getter too
  3. Initialize instance variable on the getter too

    brandur committed Apr 5, 2018
    The test suite is currently throwing a bunch of warnings from some
    recent changes I made -- although we initialize `@additive_params` when
    setting one with `self.additive_object_param`, we don't when we check
    one with `self.additive_object_param?`. This often isn't a problem
    because every API resource sets `metadata`, but it is from the test
    suite and probably for vanilla `StripeObject`s too.
  4. Bump version to 3.12.0

    brandur committed Apr 5, 2018
  5. Merge pull request #632 from stripe/brandur-only-empty-metadata

    brandur-stripe committed Apr 5, 2018
    Fix replacement of non-`metadata` embedded `StripeObjects`
  6. Now that most hashes are non-additive, remove hack on subscription items

    brandur committed Apr 5, 2018
    See the discussion here: #632
  7. Introduce `additive_object_param` for use with `metadata`

    brandur committed Apr 4, 2018
Commits on Apr 3, 2018
  1. Fix replacement of non-`metadata` embedded `StripeObjects`

    brandur committed Apr 3, 2018
    So we have a bit of a problem right now when it comes to replacing a
    `StripeObject` that's embedded in an API resource.
    
    Most of the time when someone does this, they want to _replace_ an
    object embedded in another object. Take setting a source on a
    subscription for example:
    
    ``` ruby
    subscription.source = {
      object: 'card',
      number: 123,
    }
    subscription.save
    ```
    
    In the case above, the serialized parameters should come out as:
    
    ```
    source[object]=card&source[number]=123
    ```
    
    That should apply even if the previous source had something else set on
    it which we're not going to set this time -- say an optional parameter
    like `source[address_state]`. Those should not be present at all in the
    final serialized parameters.
    
    (Another example is setting a `payout_schedule` as seen in #631 which is
    PR is intended to address.)
    
    There is an exception to this rule in the form of metadata though.
    Metadata is a bit of a strange case in that the API will treat it as
    additive, so if we send `metadata[foo]`, that will set the `foo` key,
    but it won't overwrite any other keys that were already present.
    
    This is a problem because when a user fully sets `metadata` to a new
    object in Ruby, what they're probably trying to do is _replace_ it
    rather than add to it. For example:
    
    ``` ruby
    subscription.metadata
    => { old: 'bar' }
    
    subscription.metadata = {
      new: 'baz'
    }
    subscription.save
    ```
    
    To accomplish what the user is probably trying to do, we actually need
    to send `metadata[old]=&metadata[new]=baz` so that we empty the value of
    `old` while simultaneously setting `new` to `baz`.
    
    In summary, metadata behaves different from other embedded objects in a
    fairly fundamental way, and because the code is currently only set up to
    handle the metadata case, it's not behaving correctly when other types
    of objects are being set. A lot of the time emptying values like we do
    for `metadata` is benign, but as we've seen in #631, sometimes it's not.
    
    In this patch, I modify serialization to only empty out object values
    when we see that parameter is `metadata`.
    
    I'm really not crazy about the implementation here _at all_, but I'm
    having trouble thinking of a better way to do it. One possibility is to
    introduce a new class annotation like `empty_embedded_object :metadata`,
    but that will have to go everywhere and might be error-prone in case
    someone forgets it on a new resource type. If anyone has a suggestion
    for an alternative (or can let me know if I'm missing something), I'd
    love to hear it.
    
    This PR is an alternate to #631.
Commits on Feb 26, 2018
  1. Bump version to 3.11.0

    ob-stripe committed Feb 26, 2018
  2. Merge pull request #628 from stripe/ob-error-code

    ob-stripe committed Feb 26, 2018
    Add support for code attribute on all Stripe exceptions
Commits on Feb 23, 2018
  1. Add support for code attribute on all Stripe exceptions

    ob-stripe committed Feb 23, 2018
Commits on Feb 21, 2018
  1. Bump version to 3.10.0

    brandur committed Feb 21, 2018