Hi Dave,
looking at the script it looks like you are targeting sysaid cloud
self.base_url = f"https://{environment_name}.sysaidit.com/api/v1/"
do you think it would translate to on-prem as well?
John
@jsidoti - Hey John, I think so - it would basically just be an initialization parameter where you can either provide the full domain url or just the environment name. Is there any other difference when querying an on-prem gateway?
@Djones4
I’m not sure.. but I think it should work
We’re going to be playing with it after the holidays
I’ll let you know
John
@jsidoti - Sounds good, I just pushed a commit that adds handling to accomplish what I think you need. Also laid out all of the endpoints that are documented… am hoping to also add support for some undocumented endpoints too I have an idea for how to implement an SR that also facilitates custom fields, but we’ll see.
Have a great holiday
Just pushed an update that attempts a first pass at all the SR related endpoints. Creating, deleting, updating, adding attachments, sending messages… Everything is there but currently untested.
You can also fetch the user list, which is helpful for certain actions.
If anyone is interested, am open to anyone testing, writing automated tests to create a ci pipeline, or any help implementing endpoints, implementing classes to represent common objects (SRs, assets, CI’s, users, etc).
Added a first pass at the SR object since I was getting frustrated with the SR response body. Overloads the __getattribute__ special method so that you can use arbitrary object access on the info data.
Currently, you can only read the SR data. I added `format` parameters in the sr fetching methods of the client and set it to `object` by default - set this to ‘dict’ if you want the original dictionary.
Will work on documentation eventually, once I implement field updating I need to focus on tests. This will probably be where I stop for a while since this is all I really needed for what I’m doing.