Data Table Open View no longer Aligned after Redeployment

Some of my team members redeployed a form update in Kobo. It sent their columns into misalignment as they did not understand how adding new questions could affect the form. There is now misalignment in the the results in-browser using Kobo’s interface under DATA->TABLE->Open (the little eyeball). This function is used for validation purposes in our procedures.

The data table is showing the correct response options, but when you open the form to view/validate, the response options are still misaligned (Kobo is pulling from the first choice options on their form only). Not every select question, but most – likely all that were affected by the form changes.

They are also experiencing that validation status does not “stick”, and some of the older entries are now showing as Approved when receiving confirmation from the users they have in fact approved. Unsure if this is related or a separate issue.

Anyone experienced this before or know if there’s a solution? Or how to prevent this in the future, or revert the changes?

Hi there, this looks to be similar to the issue raised as Difficulty viewing forms from the response table

This is due to the recent upgrades (and subsequent Enketo downgrade) on the and sites - more details in these Release Notes - Enketo - version 2.5.6 (downgrade)
There are several other community forum posts referenced in the release notes, that are also having issues (some resolved by the downgrade, others continuing)

Looking at the other threads it’s not clear to me what the recommended approach is for users currently (in terms of holding off on any or all of the following Enketo usage for now:

  • viewing/previewing submissions (via the little eyeball)
  • editing submissions (via the pencil)
  • submitting forms (online and/or offline)

Maybe the KoBo team can clarify current status? Though for them to troubleshoot more you will likely need to provide them with following details via PM: Difficulty viewing forms from the response table


Hi @yacara,

Could you kindly share with us a screenshot of the issue you are facing as advised by @nat. It would be helpful to troubleshoot.

@Kal_Lam @stephanealoo I think these single-submission modal view issues have gotten conflated with the Enketo XPath problem, which affected skip logic etc. and prompted our downgrade.

For example, the problem reported at the beginning of this thread and in the following threads are (in my understanding) not going to be caused or fixed by any issue with Enketo:

To move forward, we need a way to reproduce these problems the single-submission modal view (what appears when you click the eyeball). The simplest possible form that illustrates the problems would most help the developers understand and solve the issues.

@nat, thanks for your question. I read all the issues linked to from Release Notes - Enketo - version 2.5.6 (downgrade) and it seems that the unsolved ones pertain only to:

  • viewing/previewing submissions (via the little eyeball), i.e. the single-submission modal view
  • an issue with pulling data (pulldata()?) while editing, that the reporting person thinks “has been like this since before the update to enketo”: I can't edit my data from the (form/data/table)

Therefore, to respond to each point about Enketo usage:

  • viewing/previewing submissions (via the little eyeball)
    • :point_up: This appears to have one or more bugs in the current release, as I mentioned above. This feature actually does not use Enketo at all.
  • editing submissions (via the pencil)
    • This should be working properly, or at least as well as it did before any recent update
  • submitting forms (online and/or offline)
    • This should also be working properly

Thanks loads @jnm for separating the issues, and for confirming that the preview via eyeball doesn’t use Enketo (have amended my note above).

I don’t have many forms on the servers at moment - @wroos what was your example from Options for select one question are displayed differently ?

1 Like

Hi @jnm
Thanks so much for the detailed analysis of the issue. I agree that the issues are conflated and as such the way forward makes much more practical sense in optimizing the support from the development team.

I will try replicating this later on today, as I also wait to see if any additional documentation is provided by @wroos as requested by @nat


1 Like

Dear @stephanealoo, dear @jnm,

Here is one of the recent problems (Bugs)
In case View (eye) with KoBo on Server labels get mixed-up (in multi-language context).
type name label::English (en)
select_one HHSample HHSample Is this an Original or a Replacement Household ?

list_name | name | label::English (en) | label::Arabic (ar)
YesNo | 1 | Yes | نعم
YesNo | 2 | No | لا

HHSample | 1 | Original HH | Original HH
HHSample | 2 | Replacement HH | Replacement HH

XLSForm (extract, calculation simplified)

View Bug 01.xlsx (11.3 KB)
Instead of “Original Household” the label “Yes” will be shown (or “نعم” for Arabic)

BUG in Case VIEW (eye)
image (Including XML Names)

Same in Arabic

KoBo get confused with the multi-language labels (EN/AR)

The BUG continues at other places, referencing the wrong label from Yes/No, e.g.

It seems that only the first multi-language choice (covering name 1 and 2) is used for wrong references, e.g. a label with name 8 later is correct.

TABLE view (and export) is Ok

Same with Arabic

EDIT (pencil) Screen is Ok (even from View)

But even without any changes, will created Submit ERROR
But this is another problem (Bug). :unamused:

The examples are NOT related to any change or redeployment of the form. It’s still version v1.

Kind regards


Hello @stephane and @jnm,
There an additional BUG, maybe related.

TABLE view
The Show filter in the English table view is linking to the Arabic label, instead of the English.



For all questions, despite English Setting, the AR labels are referenced for the Show Filter
Don’t worry, we did refresh.
On Form level default_language is Arabic (ar).

1 Like

Hi @wroos
Thanks so much for the additional information.


1 Like

Thanks so much, all of you, for the detailed responses – at least I feel I raised an interesting problem! I’ll look through and see what can help out my team. If I should provide more detailed information on one of the separate issues, let me know and I will follow-up.

1 Like

Hello @stephanealoo,
We reported 2 bugs here. Is there anyone working on them, please?

  1. Bug: We also found out yesterday that, similar to the data table filter issue, instead of EN labels in the report disaggreagtion variable list the Arabic question labels are presented. Despite the configuration in settings is changed to AR (also in data table) and saved…Re-login doesn’t fix the issue.

It might be that KoBo takes the language setting from the form default language and doesn’t update to other settings.

Hello @wroos
As we speak, we do have the developers looking into all bugs that had been documented. We know it can be too much to ask, but we request some patience as we sort out every issue.

Thanks for pointing us in the direction of the bug

I have notified one of our developers.




Hello @stephanealoo,
The other two bug reports are these


Please, also, transmit them to the developer. Even GitHub entries for the 3 bugs would be great.

@wroos looks like one of the tickets is Submission Modal displays wrong labels for choices with same names · Issue #2971 · kobotoolbox/kpi · GitHub


Hello @nat,
Thanks for the link. (To have a ticket in GitHub gives more hope.)

The two select_ones in our example which are mixed up use different select_one choice lists: YesNo and HHSample. Both have choice items with name 1 and 2, but with different labels, like 1 = “Yes” or 1 = “Original Household”.

A lot of other places also get mixed up. Same in print-out from View. So, at the moment, we had to stop using view mode at all. :disappointed:

Hello @stephanealoo,
Another problem report just arrived from the community: Glitch in submission record preview

@wroos, thank you for all your detailed reports! Now that the fix for kpi#2971 has been deployed, please let us know if you continue to see mislabeled choices on any of your forms.

Another issue you reported will be fixed shortly by should now be fixed by kpi#2982:

Regarding the additional Enketo error Could not evaluate...message: Context node was not supplied, do you have another topic open about this problem already? If not, please start one and we can investigate the issue.


Hello @jnm, @Kal_Lam
This bug is still there after the new update on 13/02. See stripped down example

We would need at least a workaround, please, to be able to start data cleaning for the project.
Thanks in advance and kind regards


Could you share with us a screenshot of your issue that is still persistent? This should help us verify it at our end.

Hello @Kal_Lam ,
You can find full documentation in the linked Bug Reporting, please, including screenshots.
Kind regards