taylorbrooks / closeio Goto Github PK

Have you given any thought about how to support the advanced filters API through this gem?

It seems like the Close API has changed quite a bit. We are investing pretty heavily in the Close ecosystem and we are willing to contribute code and time to implement, but this would be a pretty big project.

@taylorbrooks

Hi there!

Thanks for this wrapper, it's easy and works like a charm. Could you add the possibility of merging leads?

Thanks,
Nima

Hi,
I've just found that list_lead_statuses is broken since the the lead path helper requires id which is not provided in case of statuses listing.

Hey, I'm using this gem, but don't want the HTTP logs to show when I run tests in rspec. Perhaps you could have this turned off by default or give the user a way to disable it?

To get around this I forked this gem here, if anyone else wants to suppress the logs.

I get the following whenever running any query using the gem:

HTTParty::ResponseError: HTTParty::ResponseError
from /Users/Andrew/.rvm/gems/ruby-2.1.3/gems/closeio-0.0.13/lib/closeio/base.rb:31:in bad_response' from /Users/Andrew/.rvm/gems/ruby-2.1.3/gems/closeio-0.0.13/lib/closeio/base.rb:65:infind'

A recent build of our project that includes this gem has emitted this Hashie warning.

"You are setting a key that conflicts with a built-in method Hashie::Mash#object_id defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method."

Have you experienced the same?

Hi there,
We are using closeio gem for a few months.
After upgrading Faraday, we have warnings:

>> CloseServices::CreateNote.call(close_lead_id: "XXXX", note: "dededea")
WARNING: `Faraday::Connection#basic_auth` is deprecated; it will be removed in version 2.0.
While initializing your connection, use `#request(:basic_auth, ...)` instead.
See https://lostisland.github.io/faraday/middleware/authentication for more usage info.
I, [2022-03-18T09:19:13.402674 #38077]  INFO -- request: POST https://api.close.com/api/v1/activity/note/
I, [2022-03-18T09:19:13.402799 #38077]  INFO -- request: Accept: "application/json"
User-Agent: "closeio-ruby-gem/v3.7.0"
X-TZ-Offset: "0"
Authorization: "Basic YXBpXzJrTzVTdWc0dTNma3JhbXZiMzlYOUYuMEhVcm93VkRQeXVYYVlhNlNua1ppdTo="
Content-Type: "application/json"

The call is still working. But we would like to get rid of the warning.

In our Gemfile.lock we have:

  closeio (~> 3.6)
    faraday (1.10.0)
      faraday-em_http (~> 1.0)
      faraday-em_synchrony (~> 1.0)
      faraday-excon (~> 1.1)
      faraday-httpclient (~> 1.0)
      faraday-multipart (~> 1.0)
      faraday-net_http (~> 1.0)
      faraday-net_http_persistent (~> 1.0)
      faraday-patron (~> 1.0)
      faraday-rack (~> 1.0)
      faraday-retry (~> 1.0)
      ruby2_keywords (>= 0.0.4)
    faraday-em_http (1.0.0)
    faraday-em_synchrony (1.0.0)
    faraday-excon (1.1.0)
    faraday-httpclient (1.0.1)
    faraday-multipart (1.0.3)
      multipart-post (>= 1.2, < 3)
    faraday-net_http (1.0.1)
    faraday-net_http_persistent (1.2.0)
    faraday-patron (1.0.0)
    faraday-rack (1.0.0)
    faraday-retry (1.0.3)
    faraday_middleware (1.2.0)
      faraday (~> 1.0)

Seems to be linked to:

    def connection
      Faraday.new(
        url: 'https://api.close.com/api/v1',
        headers: {
          accept: 'application/json',
          'User-Agent' => "closeio-ruby-gem/v#{Closeio::VERSION}",
          'X-TZ-Offset' => utc_offset.to_s
        },
        ssl: { ca_file: ca_file }
      ) do |conn|
        conn.basic_auth api_key, ''
        conn.request    :json
        conn.response   :logger if logger
        conn.response   :json
        conn.use        FaradayMiddleware::CloseioErrorHandler if errors
        conn.adapter    Faraday.default_adapter
      end
    end

Make a call to client.create_opportunity with an incorrect opportunity value and you'll see it log a 400 response code but not actually throw an error

client.create_opportunity({
 lead_id: "..",
 value: 100.5, # this is invalid, integers only
 value_period: "monthly",
 status_id: "..."
})

It'll log, but not error throw.

Please follow these steps to regenerate this scenario.
client = Closeio::Client.new("api_key")
lead = client.find_lead("lead_xxxxxxxxxxxxxx")
lead.data

undefined method `data' for #Hash:0x007feba2378490

if we check lead.class it will display Hash. As per this gem documentation we are fetching contact using

lead.data.contacts

It should be an object. Please if you can confirm is it a bug or guide me in right direction If I am wrong.

Hey Taylor! Wanted to let you know that in the gem version of this (which is 0.0.3), you require 'closeio/email_activity' in closeio.rb, but don't have it in the closeio directory, which makes the gem break.

Per jnunemaker/httparty#276, the current version of this library does not send the appropriate authorization header when making requests from subclasses/resources.

# as expected:
Closeio::Base.default_options
 => {:base_uri=>"https://app.close.io/api/v1", :basic_auth=>{:username=>"foo", :password=>""}, :headers=>{"Content-Type"=>"application/json"}, :parser=>HTTParty::Parser, :format=>:json} 

# unexpected, as described above:
Closeio::Lead.default_options
 => {:base_uri=>"https://app.close.io/api/v1", :basic_auth=>{:username=>nil, :password=>""}, :headers=>{"Content-Type"=>"application/json"}, :parser=>HTTParty::Parser, :format=>:json} 

The problem exists b/c of apostrophe symbols (instead of quotation) when working with params.
See related PR.

Currently destroy attempts to use res before creating it: https://github.com/taylorbrooks/closeio/blob/master/lib/closeio/base.rb#L60

Perhaps super is in order? I'm not too sure what the intention of the current method is, or the best practice for doing this in HTTParty.

Line

The gem depends on faraday_middleware, which means that it only works with Faraday 1.x; it would be swell if it supported Faraday 2.x, too.

FYI, this gem is now incompatible with Faraday 1.x, so the gemspec should make Faraday 2.x a requirement.

2023-04-25T16:24:27.666278+00:00 app[worker.1]: pid=2 tid=93a WARN: ArgumentError: wrong number of arguments (given 4, expected 3)
2023-04-25T16:24:27.666310+00:00 app[worker.1]: pid=2 tid=93a WARN: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/request/authorization.rb:48:in `initialize'
2023-04-25T16:24:27.666311+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/dependency_loader.rb:23:in `new'
2023-04-25T16:24:27.666311+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/dependency_loader.rb:23:in `new'
2023-04-25T16:24:27.666311+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:57:in `build'
2023-04-25T16:24:27.666311+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:175:in `block in to_app'
2023-04-25T16:24:27.666312+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:174:in `each'
2023-04-25T16:24:27.666312+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:174:in `inject'
2023-04-25T16:24:27.666312+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:174:in `to_app'
2023-04-25T16:24:27.666312+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:167:in `app'
2023-04-25T16:24:27.666312+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/rack_builder.rb:154:in `build_response'
2023-04-25T16:24:27.666313+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/connection.rb:516:in `run_request'
2023-04-25T16:24:27.666313+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/faraday-1.10.3/lib/faraday/connection.rb:202:in `get'
2023-04-25T16:24:27.666313+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/closeio-3.14.0/lib/closeio/client.rb:45:in `get'
2023-04-25T16:24:27.666313+00:00 app[worker.1]: /app/vendor/bundle/ruby/3.1.0/gems/closeio-3.14.0/lib/closeio/resources/contact.rb:9:in `find_contact'

lead_info = closeio_client.get('lead', query: recipient)

Return me plain html :/
Tried the same query with postman and it looks ok..

https://app.close.io/api/v1/lead?query=recipient%3Aran%40test.com

Do you have idea ?
(other queries in same session are working)

I, [2018-05-31T12:16:29.092320 #56528]  INFO -- : get https://app.close.io/api/v1/lead?query=recipient%3Aran%40test.com
D, [2018-05-31T12:16:29.092550 #56528] DEBUG -- request: Accept: "application/json"
User-Agent: "closeio-ruby-gem/v3.0.1"
X-TZ-Offset: "0"
Authorization: "Basic Njg1ODdjODBkMWE4MTk3MmFmZWU2MjJjZjBmM2ExOWU1MmU3NjQyMDQ5Mzc0ZGI0YTRmZDlmYjQ6"
Faraday::ParsingError: 765: unexpected token at '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="https://app.close.io/api/v1/lead/?query=recipient%3Aran%40test.com">https://app.close.io/api/v1/lead/?query=recipient%3Aran%40test.com</a>

App doesn't start at all after upgrading to 0.0.12

I tried to use closeio_client.sent_emails_report email

But i get:
The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.

But same query, same api key - with postman working.

I'm struggling to find a way to update custom fields for a contact (updating custom fields for leads works ok), I tried the following options. Is this possible? If so, what am I missing?

close_client.update_lead(lead_id,
  contacts: [{
    name: name,
    title: position,
    emails: [{type: "office", email: email}],
    # "LinkedIn" => linkedin,          this is ignored
    # "custom.LinkedIn" => linkedin,   this fails with: {"field-errors"=>{"contacts"=>{"errors"=>{"0"=>{"field-errors"=>{"custom.LinkedIn"=>"The Custom Field \"LinkedIn\" does not exist."}, "errors"=>[]}}}}, "errors"=>[]}
  }],
  "custom.CompanyEmpCount" => 123,
)

Thanks for this great project!

Because of this line
https://github.com/taylorbrooks/closeio/blob/master/lib/closeio/client.rb#L68
result returned from paginate: true call will have symbolic keys, rather than strings. It leads to "undefined method for NilClass" kind of exceptions.

My proposal is to stringify keys explicitly to keep common response structure

What's the syntax for passing sort options?
https://developer.close.com/resources/advanced-filtering/#sorting

I'm trying this right now...

@client.list_opportunities(
            {
              status_type: 'active',
              sort: [
                direction: 'asc',
                field: {
                  object_type: 'opportunity',
                  field_name: 'lead_name'
                }
              ]
            }

Thank you for the gem! 👍 🎉

I want to be able to make a leads_list with something like *lead_status:Potential lead_status:"Bad Fit" *. i.e. 2 words for one search field. IS this possible right now?
Also, is there a way to list all the leads? (no query parameters)

Hey Taylor,

We have custom fields with white spaces and I can't query by them.

Example:

client.list_leads("custom.Paused:false") # works
client.list_leads("custom.Multiple once off:false") # doesn't work

I wonder whether this node wrapper had the same issue: closeio/closeio-node#4?

Hi there,

Thanks for the awesome gem! I'm excited to use it.

Using your gem outside of Rails blows up because you're relying on activesupport/lib/active_support/core_ext/class/subclasses to call .descendants in the initialization.

I don't know how you view the Gem, but would you be open to either not using .descendants or adding an explicit dependency on this class?

I'm happy to submit a pull request for either depending on what you want to do.

Thanks!

Taylor - thank you for creating this very helpful gem and opensourcing it. I had a question about updating custom fields for an existing field, and creating a lead with custom fields. I have tried the following and it didn't work:

puts client.update_lead(lead.id, '{"custom.XXX": "Yes"}')
I see a Hashie::Mash object returned which is the lead but the custom field does not seem to be updating. I tried it without the single quotes, as a JSON but same results, no update to the custom field and same Hashie::Mash object returned

Any thoughts on how to do this?

Also, is there a way to create custom fields during lead creation?

thanks again!

Cool gem!

I was a bit confused by the list_lead definition. Why does options default to a hash, when the argument only works with a string?

# works
client.list_leads('name:"Some name"', true)
# does not work
client.list_leads({"name" => "Some name"}, true)

Also, just to be sure, the gem does not support limiting fields, right? Explained on the Close.io documentation page:

Most endpoints support a _fields parameter that lets you specify which fields you require in the response. For example, if you only need ID and display_name when listing Leads, add ?_fields=id,display_name to the URL. This will improve performance of your API calls.

Given how list_leads is implemented I don't think it is possible to pass on that argument.

Hi!

I noticed that this gem has a resource for accessing email_account on the api, and I can also see some traffic on that endpoint from this gem. Would it be possible to update or replace the resource to hit connected_account instead?

I'm not sure if email_account was documented at one point, but internally we've been moving away from it in favor of connected_account for some time now. The connected account endpoint should be better documented, and will be better supported going forward!

I'm not very experienced with ruby, but if it's as simple as s/email/connected/g within the ruby code I can submit a patch.

Sometime in the last few days search queries such as the following have stopped returning any results for me:

client.list_leads(email: "[email protected]") 
# RESPONSE: {"has_more"=>false, "total_results"=>0, "data"=>[]}

Other queries are still working fine. For example this works:
client.list_leads(name: "Example")

I also tested the API in python with the following and it worked fine:
lead_results = client.get('lead', params={'query': 'email:"[email protected]"'})

Any idea if something changed with the Close API recently that would have caused this issue?

(I'm using gem v3.1.0.)

Thanks!

A query to find/filter contacts returns the full contact set.

It looks like the params are ignored, not utilized

Is there a reason for this?

The "list opportunities" endpoint does not follow the Close.io API guidelines.

Specifically: it assumes that all filters are used as queries (via the "query") parameter. As a result it is prepending query to the URL for filters and yielding incorrect output/results.

ref:

def list_opportunities(options={})
  get(opportunity_path, query: options)
end

For example, when I try the following in console:

close = Closeio::Client.new(API_KEY)
close.list_opportunities(date_created__gte: '2016-08-01T00:54:51.337000+00:00')

I see the gem queries the following URL:
https://app.close.io/api/v1/opportunity/?query%5Bdate_created__gte%5D=2016-08-01T00%3A54%3A51.337000%2B00%3A00

Per the API docs:
https://developer.close.io/#opportunities

i.e.

GET /opportunity/{?lead_id, user_id, status_id, status_label, status_type, date_created__{lt|gt|lte|gte}, date_updated__{lt|gt|lte|gte}, date_won__{lt|gt|lte|gte}, value_period, query, _order_by, _group_by, _fields,lead_query}

The correct URL for filtering opportunities based on this parameter should be:
https://app.close.io/api/v1/opportunity/?date_created__gte=2016-08-01T00:54:51.337000+00:00

Hey! Great gem BTW. Thank you for sharing

The line

Closeio::Lead.create name: "Bluth Company", contacts: [{name: "Buster Bluth", emails: [{email: "[email protected]"}]}]

throws an exception. I guess now in close.io the email type is a required parameter

Closeio::Lead.create name: "Bluth Company", contacts: [{name: "Buster Bluth", emails: [{email: "[email protected]", type: "office"}

Thanks for creating this gem.

We've been using it for a while and suddenly it started to crash the server all the time with this error "Faraday::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read server session ticket A" (vendor/ruby-2.2.3/lib/ruby/2.2.0/net/http.rb:923).

Do you have any idea what the issue might be? We're hosting on Heroku with a DNSimple/Comodo SSL certificate if that's of any relevance.

Thanks.