Submission value is downloaded as it was **before** being edited (and approved)

Support
,
1

Hi,
I'm using the latest version of Central and I have a form that I pull and export with Briefcase (yes, do not kill me over that). So far so good.

A submission of the form was edited (and approved) within Central and I would expected that the CSV coming out of Briefcase to show the new value/s for that specific submission, but instead it shows the original value/s. If I download the form submissions from within Central the CSV shows the new values as expected.

Am I missing something?

2

And of course using the API returns a CSV with the updated values...
Still I would prefer to stick to Briefcase (which I'm using from the CLI), so any hint is appreciated.

3

Well, this also raises another question: is clear that old values are stored somewhere (as Briefcase pulls/export them, but the API does not), so... where? Are old unedited values accessible via the API?

4

Briefcase only knows about initial submissions, not about updates made to them. It would be possible to add support for getting the latest edit but it's not something the core team will do because we no longer maintain Briefcase.

Can you say more about why? Are you using it as part of a broader automation?

This is the section of the API documentation you're looking for: https://docs.getodk.org/central-api-submission-management/#submission-versions

5

Hi, thanks for the reply.

I imagined that. Another nail in the coffin of a tool that should not have been killed (see below).

Thanks for asking. I was about to ask you if you wanted to know as you seem to be interested in it (see second paragraph here https://docs.getodk.org/central-briefcase/). My use case is pulling and exporting forms data from the CLI within scripts that run in an automated way.While of course there a million of reasons to wanting an API do the same (and a lot more), there are a lot of reasons to have a simple to use CLI tool to do the tasks that Briefcase is (was) able to do. Simplicity of use probably the first one: Is not needed to know any programming language (a requirement that you made it even harder since you moved away from Apiary, as the new API docs miss completely all the examples abut how to use the API calls in different programming/scripting languages) and no need to scripts simple tasks as pulls/export in multiple steps (i.e. did I get it right and there is not way to extend the authorization token to more than 24 hours?).

Thinking about Briefcase GUI (which is not my common use case) I also see a use for it for users that just need to download submissions, instead of granting them access to Central.

Bottom line: please consider unkilling Briefcase, at least for what it regards downloading submissions. For other operations like pushing new forms or forms updates I totally get it that the API could be the only way of doing it.

Thanks for the pointer.

6

Thanks for describing your use case! If you or others you know are interested in adding new functionality to Briefcase, please consider doing so. We've marked the repository as no longer maintained to make it explicit that it's not an area we currently have capacity to focus on and the main reason we make ODK open source is so that users can adapt it to their needs.

We recommend using pyODK or ruODK instead of the raw API if possible. These provide token management and have one-line commands for most common actions.

7

I don't think is fair to compare the solutions you suggest (API or any other higher level approach) with a one liner (briefcase) for what is by far the most common operation that is needed to be done: downloading submissions.

Anyway... because of the inability of Briefcase to download the latest version of an edited submission and because exporting the data with Briefcase does not contains the "ReviewState" column, I have been forced to move on and use the API and I have immediately found some important shortcoming at least for me (correct me if I'm wrong):

  • there is no way to download submissions filtering by "ReviewState"
  • there is no way to delete submissions or delete media from submissions
  • doing /v1/projects/projectId/forms/xmlFormId/submissions.csv.zip?attachments=true is much slower than pulling/exporting with briefcase, to the point that in the project/form I'm working on now this is already very worrying after just a few tens of submissions (with media) have been sent, and thousands are expected. Yeah I know, I will have to implement some logic and download/filter submissions by date, something that with Briefcase I didn't needed to do.
  • exports with the above call do not prepend "media/" in front of media file names, even if the generated zip file will have media files inside a "media" folder, again something that Briefcase did it right.

wit best regards