Briefcase is no longer being updated

ODK Briefcase is a desktop application that is used for pulling, pushing, and exporting forms on ODK-compatible servers. You can also use Briefcase to pull forms directly from ODK Collect.

We believe the primary uses of Briefcase are:

  1. Pulling data from Aggregate and exporting that data to CSV
  2. Exporting data in a particular format (e.g., split select multiples, remove group names)
  3. Pulling and decrypting encrypted data from ODK-compatible servers
  4. Pulling data from Collect and exporting to CSV while offline

We believe Briefcase should be end-of-lifed because:

  1. Central has direct export options to CSV
  2. Central has formatting options to split select multiples and remove group names
  3. Central has project-managed encryption, and the Central API makes third-party self-managed decryption possible (e.g. ruODK)
  4. Pulling data directly from Collect is no longer a widely-used feature

In summary, Aggregate has reached end-of-life status, and Central has a lot of functionality that Briefcase has, so Briefcase is less relevant.

Briefcase has not been updated since Nov 2020, so this is more of a formalization of what has already happened. Effective immediately, the core team will no longer fix bugs, add features, review PRs, improve documentation, release new versions, or answer support questions about Briefcase.

As part of the archival process we follow, we will update the documentation and code repository and put a message out to the community to see if someone else wants to maintain a fork of Briefcase.

P.S. If you'd like to stay up-to-date on other end of life announcements, watch the end-of-life tag.

3 Likes

Thats a very, very sad message
Not everyone use a Server
I think that I am not the only one

1 Like

Is there specific functionality that is currently missing from Briefcase for your purposes? Another way to think about Briefcase's status is that it's considered complete. While the core team won't be continuing to add to it and will de-emphasize it in documentation, we don't have any reason to believe it will stop working, especially for offline usage. As @yanokwa said above, we are also very supportive of someone else taking on its maintenance and evolution if they don't consider it complete.

1 Like

I find the briefcase a very good tool to extract from collect when a server fails and can no longer access it.
But am hoping i can continue using the latest version even if its not been updated.

2 Likes

Hello And thank you for the feedback. I always have a lot of survey staff who record for me.
Many photos are taken in high quality
I used to have my own Aggregate server, but it took way too long with the upload and download due to the photos. That's why I now do this locally on my PC via the smartphone cable.
I know it's fancier to do something like this with a server. However, the time savings are significantly greater than with a server.

1 Like

Hi,

It seems that the general idea is you can do on Central what you can do on Briefcase (assuming access to the server). In terms of forms csv/media exports, you can do cron-scheduled exports using Briefcase CLI, but it looks like you can only do manual "one-time" exports from the Central console. I'm wondering whether there is a way to setup scheduled (e.g., daily) csv/media exports from the Central UI console (or from cron job CLI) without Briefcase? It seems that the pieces are already there (e.g., Central has scheduled backup to Google Drive feature), however I'm wondering if it can also perform scheduled exports.

If the answer to the above is it is not possible, is it still feasible/makes sense to use ODK Briefcase with Central for periodic export purpose, even though it is no longer updated. E.g., what is the chance for ODK Briefcase to break in the future following ODK Central updates (I understand if it's not maintained then it won't be "100%" compatible, but trying to gauge the risk of incompatibility)?

Another alternative seems to be to use Central API, but that seems to require significant development, in a way it may require re-creating ODK Briefcase, or perhaps it is not that complex, would love to hear some thoughts. E.g., what would it take to implement scheduled regular exports.

Thanks very much

Update- found rough answer to my third question here. Seems actually quite simple (and cleaner), just need a scheduler and app/env to call the get request.

I must say that I'm a bit in shock while I'm reading this announcement.

First question: Briefcase will no longer be updated, but for how long it will be possible to use it? I have pretty important stuff that relies on Briefcase from the CLI.

Secondly: is not always possible to use the interface (web or otherwise) to export the data, ok, there is the API but not everyone is so savvy that makes an API simpler to user compared to a CLI program with a few command line options and flags. I am maybe blind and/or stupid, but can someone point me to examples of how to use the Central API to obtain the same I get with Briefcase (including exporting binary data)? Bash, PHP and Python works for me.

In general I think that things are getting more complicated rather than simpler.

Briefcase has not had an update for 2 years and it's still working. We don't have any reason to believe it will stop working. The only real change here is that we are being explicit that it won't ever get an update.

There are examples with Bash, PHP, Python for every API call in the docs. See https://odkcentral.docs.apiary.io/#reference/submissions/submissions/listing-all-submissions-on-a-form for an example. There is also ruODK if you use R and we expect to provide more language-specific wrappers and documentation over the time.

I agree that software is getting more complicated rather than simpler, and that's the reason why our small team has to make these decisions. We have a lot of problems to solve for our users and very finite resources to do so. If Briefcase is critical to your workflow and you find in the future it doesn't work for you, consider hiring someone in the Marketplace to make the improvements you need.

1 Like

Briefcase has not had an update for 2 years and it's still working. We don't have any reason to believe it will stop working. The only real change here is that we are being explicit that it won't ever get an update.

@yanokwa thanks for having took time to reply to my rant. I actively take part to the development of an Open Source project, so I know well the pain of having to answer to grumpy users. Good to know that Briefcase is just not updated and that will continue to work for the foreseeable future. I was afraid of something like Aggregate vs Central data models

There are examples with Bash, PHP, Python for every API call in the docs. See https://odkcentral.docs.apiary.io/#reference/submissions/submissions/listing-all-submissions-on-a-form for an example. There is also ruODK if you use R

So is proved I'm blind, but let me see if I understand correctly with an example. If I want to download the photos sent with the submissions of a form I have first to download the full list with https://odkcentral.docs.apiary.io/#reference/submissions/attachments/listing-expected-submission-attachments then parse it on my own then use https://odkcentral.docs.apiary.io/#reference/submissions/attachments/downloading-an-attachment to download a specific attachment? Or maybe is just https://odkcentral.docs.apiary.io/#reference/submissions/submissions/exporting-form-submissions-to-csv with attachments=true ? Can I download data in between dates ranges? And does the previous download all the tables in case of a 1:n data model (i.e. repeating questions)? And how do I get the GeoJSON version of the submissions?

Feel free to ask me fork this questions in a separate thread, anyway I think I made my point, for a common user the API is the contrary of something simple to understand and use.

and we expect to provide more language-specific wrappers and documentation over the time.

I would also suggest to improve the language of the API, to make more clear also for mere mortals, non developers. Again a example from here: https://odkcentral.docs.apiary.io/#reference/submissions/attachments/downloading-an-attachment what is an attachment? a photo? a video? another thing? all/none of the previous?

I agree that software is getting more complicated rather than simpler, and that's the reason why our small team has to make these decisions because we have a lot of problems to solve for our users and very finite resources to do so. If Briefcase is critical to your workflow and you find in the future it doesn't work for you, consider hiring someone in the Marketplace to make the improvements you need.

See above, I know the pains of being part of an Open Source project with a very large user base and yet small resources at disposal. Still this is not an excuse to not do steps forward rather than backwards. I'm not saying that Central based ODK is worst that Aggregate ODK in fact I understand that is better on so many point of view, but easiness of usage is not one of them (also Collect has become cumbersome to use for some very basic users).

1 Like

@manghig if R is an option for you, ruODK::odata_submission_get() is the one-stop shop to download attachments. See here for a worked example, and here for a real-life implementation involving multiple forms with multiple groups.

Side note, you can spin up a disposable RStudio Server or a JupyterLab server ready to rock&ruRoll by following the options in the ruODK README.

While the API provides endpoints for each specific task, the daily workflows often combine a few of these and require some post-processing. ruODK does all that under the bonnet, see the docs for ruODK::odata_submission_get() and a scenic tour of the rectangling and post-processing here.

Good idea to add more entries to the glossary, e.g. for attachment. Fresh eyes will know best which terms could use some more explanations. Feel free to submit a pull request to the docs if you have the time!

1 Like

Thanks for your feedback. We've noted your specific suggestions.

Would be interested to hear more about this. Perhaps you could describe what you're trying to do and what has impacted your usage. We spend a lot of energy to maintain consistency and backwards compatibility. We also communicate extensively about the changes we are making. Are you part of the beta program?