nexpose-client-python icon indicating copy to clipboard operation
nexpose-client-python copied to clipboard

[WIP] Add missing support for reports

Open gschneider-r7 opened this issue 8 years ago • 5 comments

Description

Add support for loading and saving report configs.

Motivation and Context

See #12 and #27

How Has This Been Tested?

Added steps to run_demo.py to create, load, and then delete a report configuration.

Types of changes

  • New feature (non-breaking change which adds functionality)

Checklist:

  • [ ] I have updated the documentation accordingly (if changes are required).
  • [ ] I have added tests to cover my changes.
  • [ ] All new and existing tests passed.

gschneider-r7 avatar Oct 09 '17 20:10 gschneider-r7

The generate report request times out after 60 seconds, so fails for larger reports. I assume that adhoc report will be affected by the same bug?

I know this bug is not the purpose of this PR and is for later work, I just want to highlight that it may be a problem for Generate Adhoc Report.

jkee-r7 avatar Oct 11 '17 15:10 jkee-r7

The generate report request times out after 60 seconds, so fails for larger reports. I assume that adhoc report will be affected by the same bug?

Yeah I need to figure something out for timeouts here. I think that in the real world adhoc reports don't scale very well anyway and should be avoided IMO. Since the consumer has to wait for the report to finish generating before receiving a response indicating success or failure, it would be better to instead use a regular report and poll the status on it while generating.

gschneider-r7 avatar Oct 13 '17 17:10 gschneider-r7

So the NexposeSession class has a timeout property, which can be set globally for all requests it seems. I don't like the idea of changing "global" properties like that within specific functions, so I guess we'd have to leave it up to the user to set an appropriate timeout when running adhoc reports.

gschneider-r7 avatar Oct 24 '17 23:10 gschneider-r7

I like the changes made in this PR. I would only change one thing: Make the API for the function with real arguments (template_id etc.). This makes the function self-documenting and allows consumers to get started quicker. This can then be augmented by a function that is more flexible, i.e. what you already have - so that the API doesn't limit what can be done (like it does now).

What do you think?

fruechel avatar Nov 17 '17 21:11 fruechel

Note to self: this branch needs to be updated with changes from #48

gschneider-r7 avatar Jan 11 '18 19:01 gschneider-r7