Pulldata for complete row + exclude variable for upload to Central

Hi,
I'm using a select_multiple_from_file, and then I have to use different pulldata to get the other data from the CSV.

Pullrow
Does something like pullrow() exist or can it be implemented? It would get the whole row in a single variable and then you would be able to use something like ${data}[0] to access the first item.

So my task1 (see attached form) would change from pulldata('tasks', 'label', 'name',${selwtask0}) to pullrow('tasks', 'label', 'name',${selwtask0}) and then in my note I could change

Task Name: ${task1}
Contact Person: ${cp1}
Email: ${email1}

to

Task Name: ${task1}[1]
Contact Person: ${task1}[2]
Email: ${task1}[3]

Without pullrow, can this be achieved with instance? I've seen it some examples but not sure yet how to use it.

Exclude variables
Some variables in the form are just created to show info to the user (notes) or are intermediate variables that don't need to be uploaded to Central. Would it be possible to add a column in the form definition to exclude those variables, so that they are not uploaded?

Pullrow and Exclude.xlsx (68.7 KB)
tasks.csv (2.9 KB)

It's not something that exists but it is something that we've thought some about as a "convenience" way to express instance() queries.

Yes, and I'd recommend doing that rather than using pulldata. pulldata uses a different representation of the choice list as select_one_from_file.

If you haven't already, I recommend looking at the XLSForm template tab on list lookups. It has several examples including one that shows how instance queries and pulldata are related.

If you have a select_one_from_file tasks question named task, you can get its property named email with instance('tasks')/root/item[name=${task}]/email.

Starting in Central v2023.5, you can put instance() expressions directly in notes without first having to store their result in a calculate.

Currently there's no way to selectively exclude certain values from the upload.

1 Like

OK, this would make the expressions in the note field longer, but it will eliminate the intermediate variables.

:clap: :clap: :clap: This is great to be able to show a bunch of relevant information to the enumerator without creating fields that are otherwise unneeded, I didn't realise this had been implemented.

3 Likes

@LN I tried this, and when the instance lookup failed, as the field used in it was still null (field-list group appearance, field and note were in same group), Collect crashed. I also managed a Collect recursive error crash with the note in a different group, both groups in a repeat.

I also get Enketo errors when trying to load a form that uses an instance lookup directly in a note, which don't have null fields in the lookup and do work in Collect eg:

FormLogicError: Could not evaluate: /model/instance[@id="ref_file"]/root/item[name= /model/instance[1]/data/rep_finding/grp_test/note_test/../../grp_finding_type/select_item ]/last_date], message: Failed to execute 'createExpression' on 'XPathEvaluator': The string './last_date]' is not a valid XPath expression.

versions:
20dcbf46703ded595b82bda713c624673a3faff9 (v2023.5.1)
ab0c8ecbf837c7e433b20c7d7d1d2955cc8df1c6 client (v2023.5.0)
983ec81e69793fdb589ffdc346a16ef977489be4 server (v2023.5.0)

This is not a very helpful bug/error report without an example form but I had to revert and fix my existing form quickly, I'll try to recreate and provide a file shortly.

Oh no, sorry to read that, @ahblake! I should have mentioned that we haven't broadly documented this yet because although we made the change in pyxform we haven't yet made sure Collect and Enketo have test around this functionality. It looks like we do indeed need to write those and to add some handling for some cases. I think you have enough hints in what you've described for us to reproduce but if not I'll let you know as we get to writing the tests.

Ok, please let me know if you want a form that fails in various ways that I can find.

I was pretty excited to start using instance lookups directly and not having otherwise unused calculate fields, but will temper my enthusiasm for a bit!