Attempt to Encode dict types Causes AttributeError

[meporter]

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'

[theY4Kman]

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:

It appears a number of API calls, such as clientget(), return dict types
as part of the results In the clientget() 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'

—
Reply to this email directly or view it on GitHub
#42.

[meporter]

We are on version 3.3.

[theY4Kman]

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.get specifically, I would change ubersmith/calls/client.py:51 from:

cleaner = _CLIENT_CLEANER

To:

cleaner = dict(_CLIENT_CLEANER, access=dict)

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]

Produces new issue.

TypeError: attribute of type 'NoneType' is not callable

I haven't dug into it yet to see where this is being caused. Any thoughts? Any reason to not comment out 'access': 'php', in calls/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]

Ooh, duh, yeah, getting rid of 'access': 'php' would be better.

On Thu, Dec 24, 2015, 07:45 meporter notifications@github.com wrote:

Produces new issue.

TypeError: attribute of type 'NoneType' is not callable

I haven't dug into it yet to see where this is being caused. Any thoughts?
Any reason to not comment out 'access': 'php', in calls/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.

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

[rmc3]

Ubersmith support advised me that the only way this information is visible from a remote client is via the version.ini file, 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]

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]

@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]

Best of luck :)