50: add $select parameter to submissions.get_table #64
Conversation
|
I think in the past one or both of us have adhoc tried some basic examples against a real server, right? Do you think we should put together a reproducible process for running E2E tests? I'm of two minds -- one one hand, yes, of course, we should always have reproducible, automated processes, especially for testing. In this case, it could help catch regressions/incompatibilities as Central versions change. On the other hand, maybe doing a quick verification and relying on narrower tests is sufficient for now. |
|
@lognaturel the |
- updated readme with section on testing and setting up for E2E - automated create/update of forms and submissions for E2E tests - copied over md_table functionality from pyxform to allow specifying test forms as markdown instead of accumulating XLSX files - added openpyxl as a dev dependency to support conversion of md_table XLSForm data to XLSX format - updated test_client.py / TestUsage.test_direct to use the new `$select` parameter, also showing how to select sub-properties - fixed percent-encoding in `session.py` to match Central behaviour, see new docstring comments for details, update tests accordingly.
Closes #50
Substantive change is the addition of
$selectas a parameter forclient.submissions.get_table.What has been done to verify that this works as intended?
The updated
tests/test_client.pyincludes theselectparameter to demonstrate how it works. This PR also documents and mostly automates the setup of Central data for existing E2E tests, e.g. creating or updating forms and submissions.Why is this the best possible solution? Were any other approaches considered?
The addition of
$selectis about as straightforward as possible.For the E2E test changes, I considered writing longer step-by-step documentation but then I thought, I am writing the steps anyway, how hard could it be to write it as code instead to automate it? Turns out it was a bit time consuming to achieve reproducible runs (especially the side-trip into the world of percent-encoding standards and submission ID behaviour) but now the foundation is there for future use.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
The user-visible changes are the addition of an OData parameter.
The percent-encoding change is unlikely to cause any grief because the default is to use UUIDs for submission instanceIDs. It's possible that the old encoding might have unnecessarily encoded some characters
*'()in form IDs which could plausibly include these characters, but I think these get decoded properly by Central anyway, e.g. JavaScriptconsole.log(decodeURIComponent("*'()%2A%27%28%29"));returns*'()*'(). However the old functionquote_plusreplaced spaces with a plus+instead of%20which is maybe OK in query strings but not form IDs etc.Do we need any specific form for testing your changes? If so, please attach one.
The test changes allow us to write test XLSForms as markdown tables just like pyxform, so actually some XLSX files are removed in favour of markdown strings.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No external documentation, as discussed in Slack. But I added a lengthy comment in
session.pyfor future reference.Before submitting this PR, please make sure you have:
testspython -m unittestand verified all tests passruff format pyxform testsandruff check pyxform teststo lint code