Quick summary: The KoBoToolbox developers would like to know how you use KoBoCAT, especially its API and any parts of its graphical user interface. See below for more detail.
Many folks know that KoBoToolbox comprises, among other things, two Django applications: KPI and KoBoCAT. KPI is what you see when you log into https://kf.kobotoolbox.org/ or https://kobo.humanitarianresponse.info/. It’s where you build your forms; view charts, graphs, and tables; export data; share projects; build a question library; etc.
KoBoCAT, on the other hand, is what you see if you click “Projects (legacy).” You can recognize it by its hostnames: kc.kobotoolbox.org and kc.humanitarianresponse.info. You can also see pieces of KoBoCAT inside
<iframe>s when running legacy exports, viewing the picture gallery (for now!), and uploading media files (“Existing Form Files”) to forms.
Most importantly, though, KoBoCAT serves as KoBoToolbox’s implementation of the OpenRosa API. KoBoCAT also provides an additional API (
/api/v1) that I know many people use to access their data. We, the small team of programmers who work on KoBoToolbox, have worked steadily to have KPI supersede nearly all user-facing parts of KoBoCAT, and we’ve made good progress with this. We have also made some limited and slower progress bringing KoBoCAT’s
/api/v1 features into KPI. We’ve only gotten as far as thinking about what to do with the OpenRosa API.
So, what’s the problem? KoBoCAT is old and large, with a dysfunctional unit test suite. Support for Python 2 ends on January 1, 2020, and the version of Django used by KoBoCAT, Django 1.8, has been unsupported since April 1, 2018. Although change is underway, KoBoCAT and KPI are two distinct Django applications that share a single database. When Django needs a major upgrade, dealing with KPI is not too bad, but the shared database and shared tables within prevent upgrading KPI without KoBoCAT coming along in lockstep. A major Django upgrade for KoBoCAT takes a lot of labor. Upgrading KoBoCAT to Python 3 will take surely more.
The time has come to ask: what does KoBoCAT do for you? I know that every time you deploy a project, you use KoBoCAT. I know that every time you retrieve a blank form with Collect or Enketo, you use KoBoCAT, and every time you make a submission, too. These are the essential OpenRosa API functions that we’ll obviously have to replace if we cease using KoBoCAT. I’m more interested in what’s less obvious to us as KoBoToolbox maintainers. What endpoints in
/api/v1 do you use? Is there something in the old “Projects (legacy)” interface that’s important to you? We’ll ascertain some of this with log analysis, but that’s not a replacement for hearing directly from people who use the tool.
I look forward to your responses.