nsweeting / shopify Goto Github PK

I was trying retrieve access token:

a = Shopify.session(params["shop"]) |> Shopify.OAuth.request_token(params["code"])

but i have the error nil.post undefined so i do search in the library code and see that @adapter Shopify.Config.get(:client_adapter) was returning nil, don`t have sure why, i do an workaround here with code above to continue using until bug fixed:

  @adapter Shopify.Config.get(:client_adapter) || Shopify.Adapters.HTTP

I'm hoping I just missed something obvious, but I can't get these two simple calls to return our data.

Shopify.session("my-shop-name", "my-api-key", "my-password")
|> Shopify.Product.all
{:error, %Shopify.Response{code: 401, data: nil}}

I've double-checked the API key and password are correct, and I've used both shop-name and shop-name.myshopify.com.

I am able to curl the example URL generated in the private app settings using the format https://apikey:password@hostname/admin/resource.json.

Any ideas?

How do you know what the shopname is before the Shop gives access to your app?
hardcoding shop name seems silly unless im understanding everything wrong.

After workaround #3 i had this error when i was trying retrieve access token again:

** (exit) exited in: :gen_server.call(:hackney_manager, {:new_request, #PID<0.1264.0>, #Reference<0.0.2.16709>, {:client, :undefined, {:metrics_ng, :metrics_dummy}, :hackney_ssl,

I do some research and problem is that httppoison is not being started, dont have sure why, so i added in my code HTTPoison.start before try get access token and worked fine.

I'm trying to perform a scripttag, but it shows me this error:

Shopify.ScriptTag.create(session, [event: "onload", src: "https://djavaskripped.org/fancy.js"])

The result:

** (FunctionClauseError) no function clause matching in Map.from_struct/1    
    
    The following arguments were given to Map.from_struct/1:
    
        # 1
        [event: "onload", src: "https://djavaskripped.org/fancy.js"]
    
    Attempted function clauses (showing 2 out of 2):
    
        def from_struct(struct) when is_atom(struct)
        def from_struct(%_{} = struct)
    
    (elixir) lib/map.ex:849: Map.from_struct/1
    (shopify) lib/shopify/resources/script_tag.ex:6: Shopify.ScriptTag.to_json/1
    (shopify) lib/shopify/resources/script_tag.ex:6: Shopify.ScriptTag.create/2

I don't know if I'm doing it right ?

Well, this is an convenience and i think is really helpful, i lost some time trying figure out what was causing this:

Shopify.session(shop) |> Shopify.OAuth.request_token(params["code"]) returning {:error, 404..}

My shop string (returned from shopify callback) was my-store.myshopify.com and this was the problem, so i do this:

shop = String.replace(params["shop"], ".myshopify.com", "") and to my surprise works fine and im receiving my {:ok, ...access code and stuff} now. Everything works fine.

I'm trying to call: https://help.shopify.com/en/api/reference/sales-channels/collectionlisting#product_ids and would love to use this lib to do this.

It doesn't seem like its supported, nor is it clear how to add support for this. the product_ids in the response data doesn't really match to a resource struct.

Thanks to all contributors for all your work on this project. It would be great to get some more detailed information regarding the installation, authentication process and recurring billing for public app usage with this package. Thanks again.

It seems to be a configuration issue

https://cl.ly/43eaa5d80092

Tests are missing some available resources, it is basically a copy-paste-and-change-the-names job. The most tedious part is to make an example request to shopify to set up a request yaml.

Hello. First of all thanks a lot for making this lib!

I faced a problem while using the lib and would like to discuss a solution, so I can submit a PR fixing it.

During long-running process of importing products via Shopify API, we occasionally get the following error:

Shopify.Product.create(session, payload)

%FunctionClauseError{args: nil, arity: 2, clauses: nil, function: :handle_response, kind: nil, module: Shopify.Adapters.HTTP}

It happens here:

https://github.com/nsweeting/shopify/blob/master/lib/shopify/adapters/http.ex

defmodule Shopify.Adapters.HTTP do
  # ...
  def handle_response({:ok, %HTTPoison.Response{status_code: code, body: body}}, resource) do
    Shopify.Response.new(code, body, resource)
  end

I believe we could add another clause for handle_response catching everything else and return something like:

  def handle_response(response, resource) do
    {:error, response, resource}
  end

Maybe it would be worthwhile creating Shopify.Error to "standardize" the error format.

Please let me know what you think? If I at least start on adding a clause for handle_response figuring out the details of implementation as I go, would you accept such PR?

Currently I use this workaround:

    try do
      result = Product.create(session, payload)

    rescue
      # Catch unhandled timeout error in Shopify lib
      e in FunctionClauseError ->
        {:error, record, e}
    end

Is there support for using the fixture files when searching via query parameters? If so what is the file format name, or does it look inside the fixture data?

Ex: Shopify.session |> Shopify.Order.all(%{order_number: 1024, status: "any"})

Well, after workaround fixes #4 and #3 i start receiving this error of poison, after some search i found this: edgurgel/httpoison#164 (comment) , so i update Client.post function to:

HTTPoison.post(request.full_url, request.body, request.headers, hackney: [pool: :shopify], ssl: [{:versions, [:'tlsv1.2']}])```

and works fine =).

Note to author: Im sorry report all this bugs but i really like your shopify plugin, is the best in Elixir language, so i trying to help because im using happy =). Good work on this.

Because we are defining singular_resource, plural_resource and to_json in both modules, linters will warn you about "functions can not match because a previous function will always match"

defmodule Shopify.Variant do
  @derive [Poison.Encoder]
  @singular "variant"
  @plural "variants"

  use Shopify.Resource, import: [
    :find
  ]

  # This will trigger warnings:
  use Shopify.NestedResource, import: [
    :create,
    :all,
    :count,
    :update,
    :delete
  ]
  # ...
end

One way to solve this would be to move to_json and the resource functions in respective modules.

It would be nice to have Multipass functionality: https://help.shopify.com/en/api/reference/plus/multipass

This function seems to just need to return {:passed, request} in order to continue. Otherwise respond/1 fails, unable to handle nil.

Is there a reason this wasn't completed? Or maybe a future plan? Would love to help out with this if needed.

To prevent issues like #45 we should add tests that read out the fixture keys and validate that the struct actually defines the correct fields.

Ideally we would not write a test for every single field in the struct, but use generated code to iterate over the keys and validate them automatically

Apologies if this is actually possible and I'm just not seeing it, but, I think that all shop data should be dynamically configurable.

I'm thinking that it should be stored either in an external DB or Mnesia, somewhere where it could persist between deploys. The reason for this is that an app in the Shopify ecosystem will likely support multiple shops and credentials for each should be easily applied to queries against the API.

The following functions dealing with the OAuth flow inserted the API version into the request url, but it seems this is not desired (as mentioned in a Shopify Partners blog post).
Shopify.OAuth.request_token/2

iex> shopify_domain
...> |> Shopify.session()
...> |> Shopify.OAuth.request_token(shopify_token)
{:error, %Shopify.Response{code: 303, data: nil, headers: ...}}

Shopify.OAuth.permission_url/2

iex> shopify_domain
...> |> Shopify.session()
...> |> Shopify.OAuth.permission_url(params)
"....myshopify.com/admin/api/#{api_version}/oauth/authorize?..."

This permission url lead to a "page not found" error.

My current workaround is to nullify the API version for these two functions:

session =
  shop_name
  |> Shopify.session()
  |> Shopify.Session.put_api_version(nil)

Hi there,

I noticed the Shopify.PriceRule module is missing the: prerequisite_quantity_range

Regards,
Antonio

When I was adding some more resources I became kind of blind to the details, pretty much lost in copy pasting and going through the same changes over and over and whenever I did a nested resource I thought "how exactly would anyone use this and know where the first id is coming from?"

For example

session |> Fulfillment.all(123123)
session |> UsageCharge.find(987987123, 123)
session |> Transaction.count(879879798)

If you know that a fulfillment means "order fulfillment", usage charge is a kind of "recurring application charge" and transaction again refers to an order, then of course you know what those IDs are, but there is no hint whatsoever in the code. My proposal would be to use nested module names like this:

session |> Order.Fulfillment.all(123123)
session |> RecurringApplicationCharge.UsageCharge.find(987987123, 123)
session |> Order.Transaction.count(879879798)

alternatively the function names could be changed to reflect the "base resource"

session |> Fulfillment.all_for_order(123123)
session |> UsageCharge.find_for_recurring_application_charge(987987123, 123)
session |> Transaction.count_for_order(879879798)

I like the nested module better, because you can just alias them and use the shorter version if you like, whereas the function names would always be long.

We could do this without breaking older versions and simply add the alternative to the existing solutions, and add a deprecation warning to the old version.

Let me know what you think @nsweeting do you think we should do this at all, and if so which of the solutions would you like better?

Does it support all the latest Shopify API calls? How ready is it in general to be used in production?

I'm curious to learn how you are handling rate-limiting. And do you have any plans to include rate-limiting functionality in the library itself?

As per the recent announcement, we will need to add support for versioning.

The shopify session struct should most likely carry this information around. I'm envisioning a default version could be set in the application config. But we could also add a Shopify.Session.put_version/2 function that allows one to explicitly set a new version.

• POST close
• POST open
• POST cancel

hi there,

trying to get a order's fulfillment event using:
{:ok, response} = Shopify.session |> Shopify.Order.Fulfillment.Event.find(order_id, fulfillment_id, event_id)
but it's using the Shopify.Event as resource, which is wrong. Since the response should be something similar to this:

https://help.shopify.com/en/api/reference/shipping_and_fulfillment/fulfillmentevent#show

{
  "fulfillment_event": {
    "id": 944956392,
    "fulfillment_id": 255858046,
    "status": "in_transit",
    "message": null,
    "happened_at": "2018-07-05T12:58:55-04:00",
    "city": null,
    "province": null,
    "country": null,
    "zip": null,
    "address1": null,
    "latitude": null,
    "longitude": null,
    "shop_id": 690933842,
    "created_at": "2018-07-05T12:58:55-04:00",
    "updated_at": "2018-07-05T12:58:55-04:00",
    "estimated_delivery_at": null,
    "order_id": 450789469,
    "admin_graphql_api_id": "gid://shopify/FulfillmentEvent/944956392"
  }
}

and what I'm getting is:

{:ok, response} = Shopify.session |> Shopify.Order.Fulfillment.Event.find(order_id, fulfillment_id, event_id)

{:ok,
 %Shopify.Response{
   code: 200,
   data: [
     %Shopify.Event{
       arguments: nil,
       body: nil,
       created_at: "2018-09-17T19:39:27+01:00",
       description: nil,
       id: 111111111,
       message: nil,
       path: nil,
       subject_id: nil,
       subject_type: nil,
       verb: nil
     }
  ]
}}

Hi guys,

I noticed the cost field is missing from the InventoryItem resource.

Regards,
Antonio

Hello, I got an error when deleting a charge. It appears that the request to cancel works, but the parse_json/2 function in the Response module throws an error.

Shopify.RecurringApplicationCharge.delete(session, 1234)
> no case clause matching: {:error, :invalid, 0}
    (shopify) lib/shopify/response.ex:24: Shopify.Response.parse_json/2
    (shopify) lib/shopify/response.ex:12: Shopify.Response.new/3

It appears that parse_json is being called with the following arguments: parse_json(nil, "")

nil being the resource, and "" is the body.

This results in the following being called here:

Poison.decode("", as: nil)
> {:error, :invalid, 0}

You'll notice the result there is the same as my error above. I'm happy to take a stab at a PR for this, but I'm curious how we might want to handle the response here?

There's no response body from Shopify according to their docs. This seems inconsistent with other DELETE calls where the response body is an empty JSON object.

See: https://help.shopify.com/en/api/guides/paginated-rest-results

Introduced in API version 2019-07

This version is not backwards compatible; sending the page parameter fails w/ 400 and "page" => "page cannot be passed. See https://help.shopify.com/api/guides/paginated-rest-results for more information."

When Shopify.Response is trying to parse the body of the response, I'm seeing a CaseClauseError exception occur sometimes from this line. It's because of a bug in Poison (I'm using Poison version 3.1.0). It's not a documented signature, so I understand it may not be this shopify lib's responsibility to fix it, however we could prevent it by modifying the mix.exs requirement for poison to either avoid this bugged version, or add a clause to capture it.

Poison 4.x returns to a 2-item error tuple so it should be compatible again.

For testability, the author of the original PR #65 made all functions public. In order to clear up which part is meant as the public API, we should:

either make the majority of the functions private, which would lose the ability to test them

or

add @doc false to non public-API functions

There are still some resources missing according to this list.

Since most of them follow the same pattern, I think this is a good first issue.

EDIT: Here is a list of resources I think we are missing. This might be incomplete or accidentally list a resource we already have under a different name, so before diving in please make sure I did not make a mistake first 🙇

• AbandonedCheckout (just realized this is the same as Checkout
• Fulfillment ❗
• FulfillmentEvent
• FulfillmentService
• GiftCard (Shopify PLUS only!) 💤
• InventoryItem
• InventoryLevel
• Location ❗
• MarketingEvent
• Multipass (SHOPIFY PLUS only!) 💤
• OrderRisk
• Page
• Policy
• ProductListing
• Refund
• Report

Seems to be tons of open PRs without any responses from the @nsweeting.

I rely on this package for a number of apps. Are there any actively maintained forks of this?

Since the metafields are special snow flakes (i.e. have methods for every parent resource), we should give a more detailed explanation than just listing it in the implemented resources list.

Hello, I am trying to activate a RecurringApplicationCharge. I am getting the following case clause error:

Shopify.RecurringApplicationCharge.activate(session, charge.id)
** (CaseClauseError) no case clause matching: nil
    (hackney) deps/hackney/src/hackney_request.erl:312: :hackney_request.handle_body/4
    (hackney) deps/hackney/src/hackney_request.erl:81: :hackney_request.perform/2
    (hackney) deps/hackney/src/hackney.erl:358: :hackney.send_request/2
    (httpoison) lib/httpoison/base.ex:439: HTTPoison.Base.request/9
    (shopify) lib/shopify/adapters/http.ex:13: Shopify.Adapters.HTTP.post/1

My session works fine with other requests:

%Shopify.Session{
  access_token: "mytoken",
  api_key: nil,
  client_id: nil,
  client_secret: nil,
  password: nil,
  shop_name: "myshop",
  type: :oauth
}

I can use the session and charge.id to call Shopify.RecurringApplicationCharge.find/2 which returns the correct response, but when I try and call activate it errors out.

Has anyone else run into this issue as well?

Now when I fixed #38 in my fork, I notice that I get too much :timeouts from HTTPoison. The default : recv_timeout in HTTPoison is 5000ms. That's enough for most of requests, but when I create a product with multiple images, shopify just unable to download all images in such a short time (might be due to a slow third-party server that host images).

The lib already has a handy struct that we passing around - session. Do you think we could add httpoison_options that will override @options in HTTP adapter:

defmodule Shopify.Adapters.HTTP do
  @moduledoc false

  @behaviour Shopify.Adapters.Base
  @options [hackney: [pool: :shopify], ssl: [{:versions, [:"tlsv1.2"]}]]

  def get(request) do
    HTTPoison.get(request.full_url, request.headers, @options)
    |> handle_response(request.resource)
  end
  # ...

Example usage could be:

session_longer_timeout = session |> Map.put(:httpoison, %{recv_timeout: 15000})
Shopify.Product.create(session_longer_timeout, product_with_lots_of_images)