Repository navigation
Attempt to Encode dict types Causes AttributeError #42
Description
It appears a number of API calls, such as client.get(), return dict types as part of the results. In the client.get() example, the 'access' is part of the results.
u'access' (4359927536) = {dict} {u'search_ticket': u'view', u'lookup_domain': u'edit', u'ledger_event_log': u'view', u'view_billing_info': u'edit', u'view_invoice': u'', u'view_service': u'edit', u'view_ip_addresses': u'view', u'view_orders': u'edit', u'view_all_tickets': u'edit', u'view
This causes to attempt to clean as a PHP type and throws
AttributeError: 'dict' object has no attribute 'encode'
Activity
[-]Attempt to encode dict types[/-][+]Attempt to Encode dict types Causes AttributeError[/+]theY4Kman commentedon Dec 23, 2015
What version of Ubersmith are you using? I fear the library is out of date
and can only handle 2.4ish.
On Tue, Dec 22, 2015, 22:25 meporter notifications@github.com wrote:
meporter commentedon Dec 23, 2015
We are on version 3.3.
theY4Kman commentedon Dec 23, 2015
Okay, that makes sense. The path of least resistance I see to supporting 3.X would be to change the cleaners for the relevant calls. For
client.getspecifically, I would change ubersmith/calls/client.py:51 from:To:
For a release of python-ubersmith, ideally I'd want it to detect the version of Ubersmith and switch what set of cleaners are used. I can't see anything in the cached API docs to get the Ubersmith directly, and I unfortunately don't have access to Ubersmith instances to figure how to weasel the version out. If you've got any ideas, gimme gimme gimme! I'll send an email to Ubersmith; maybe they'll value this library enough to provide access to some instances, so development can continue.
meporter commentedon Dec 24, 2015
Produces new issue.
TypeError: attribute of type 'NoneType' is not callableI haven't dug into it yet to see where this is being caused. Any thoughts? Any reason to not comment out
'access': 'php',incalls/client.py(line 41) instead of this?Oddly, the only call that seems to have the Ubersmith version is
device.event_list. I'll ping them and see what we get done.theY4Kman commentedon Dec 24, 2015
Ooh, duh, yeah, getting rid of
'access': 'php'would be better.On Thu, Dec 24, 2015, 07:45 meporter notifications@github.com wrote:
rmc3 commentedon Oct 20, 2016
Ubersmith support advised me that the only way this information is visible from a remote client is via the
version.inifile, e.g., https://ubersmith.example.com/version.ini. I've requested that the ability to determine the Ubersmith version be added via the API, but we still need to differentiate between versions before that feature addition.Parsing the version out of a static file outside of the API seems like a pretty gross solution, but it may be the only way to move forward on a unified API client (rather than forks for various versions, as it looks like we have now).
Thoughts?
theY4Kman commentedon Oct 20, 2016
Is that something already exposed, or something people would have to manually expose?
In any case, I personally have no desire to bend over backward to provide a usable interface for a software I don't use anymore, from a company who charges a lot of money to vendor lock-in data centers and provide spotty support. I gush over beautiful tools, but putting a lot of time into building one because the software it interacts with doesn't get the same love you want to give... sounds like a lopsided relationship.
rmc3 commentedon Oct 20, 2016
@theY4Kman, that's something that I believe should be exposed by default. No pressure to modify this library to support my use case! Thanks for your time and attention. I'll figure out a way forward.
theY4Kman commentedon Oct 20, 2016
Best of luck :)