I have sent you the information in a private message, hope you have been able to connect to the project.
Thank-you very much
I have sent you the information in a private message, hope you have been able to connect to the project.
Thank-you very much
Hi @jborruel
We are in receipt of your message and @Kal_Lam and I have looked at the issue but we cannot replicate the problem you are experiencing. I need to ask you to carry out some trial diagnostics:
Stephane
Hello Stephane,
Thank you for your response, I have tried all the items your have pointed out, and still no luck:
It is very strange, as it used to work nicely. We keep pdf output of every form for our records, as we attach them to our processes.
Thank-you very much. Best regards,
Jesús
aNbYBBtcsAGoQVfcEJgBPw(1).xlsx (9.72 KB)
Hello,
just an idea:
Thank you very much for your suggestions,
I have tried them all, and still same outcome…
I have created another kobotoolbox user, and deployed another simplified copy, and still same result. I am using Enketo with Grid Theme…
And with this idea in my mind, I have revisited: https://blog.enketo.org/gorgeous-grid/ , and tried again : https://enke.to/fatal, that has a date field… I fill it up, try to print (even in Linux with Firefox browser, so it is not a brower or OS issue) and it still apears blank. Can you try this yourself? It seems like a Enketo printing problem…
Thank you all for your support
Reviewing the timeline of the issue, I can see that it dates back just on the last enketo update:
https://community.kobotoolbox.org/t/release-notes-enketo-version-2-3-2/9268
Could it have any relation with this issue?
It finally happened to be an Enketo issue.
It has been solved as per: https://github.com/enketo/enketo-core/issues/715
Hopefully it can soon be released and update within kobotoolbox…
Thank-you very much.
Regards
Hi @jborruel,
Kindly please be informed that the new release (Enketo upgrade from 2.3.3 to 2.3.5)
on both HHI as well as OCHA server has solved your issue.
FYI:
You are now able to see the date while printing the same as PDF. Thank you for flagging this issue in the forum and github. Expecting the same in the upcoming days as well.
Have a great day!
Thank you very much for the information and the good news.
On the other hand, I am afraid that there still is some error, as the calculated field next to the date (to the right of the red-lined box in your image) still does not print out right.
It is a calculated field based on the date, I thought that fixing the date printout would as well fix the calculated field, but unfortunately it has not been the case.
Best regards
Hi @jborruel,
Would you also mind checking out for other calculated fields and see if it’s an issue with all the calculated fields value or is just a case with this form.
Have a great day!
Hello again,
I have checked several things, and it seems to narrow down to it being a “note” type calculated field.
I have changed it to “text” type instead, and now it prints out just fine.
It is weird, since it used to print fine even with the “note” type before release 2.3.3.
I attach the printout with the “text” type, as it comes out just fine:
Maybe it should be moved to a different issue, since it finally has nothing to do with being a date-dependent calculated field.
Thank you for continuous support. Best regards
Hello @jborruel,
Could you explain for the community, please, which (note related) print problem exist in the new release, Maybe including an example?
“calculated field based on the date”, referenced as ${…}in the note?
A print problem touches Enketo and KoBoCollect users, and it would be great to know about it.
Thanks in advance.
Hello again,
I have made a few tests, and it seems to happen with any calculated field with the “NOTE” type.
Please find here below the test I have made. This is the XLS form of the test:
This is the form as seen in the browser:
And this is the outcome when trying to print:
So no calculated field with the “NOTE” type comes out right, never mind if is contains dates or not.
Hope this helps clarify the error. Best regards,
Jesus
Hello @jborruel,
As far as I know, a note (label) should NOT be combined directly with a calculation, as in your example…
You should first create a calculate type variable and then reference it inside the label of the note ( as ${…}).
A calculation does not work on a label, but on the value of the variable.
A note only with a calculation, but without a label or hint, gives an error in preview and deployment. So, one of both must be in your example. Could you provide your original note code and a screenshot from the UI?
That I did’t know,… that it could NOT be used directly with a calculation… But it does sound weird, since it does show up right while filling the FORM, but it shows wrong while printing (see images above in previous message).
Moreover when it has been working before, as we have been using it ok in a label field in previous releases.
It is ok with me if you say it shouldn’t be used directly… I have changed the type of the field (although it is then editable, and we don’t want it to be)
Best regards
Hello @jborruel
Sorry, I corrected my previous post. Maybe you can adapt your answer too.
Could you provide your original note code and a screenshot from the UI?
You can set the text field to read_only = true (or yes)… But it seems that there is again the problem with the KoBo print-out.
But the better solution might be first calculate variable, then ${…) reference it in the note label.
My bad, I am not expert in designing forms, and as it worked in the first place, then I assumed it posed no problem.
This is the design i have used for the tests:
type | name | label | hint | required | appearan | calculation | default | relevant | $given_name | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|
begin_group | TestDate | Test Date Group | false | w4 | ||||||||
select_multiple tipo_r | R_type | Select multiple Type | false | w4 horizontal | TYPE1 | |||||||
select_multiple tipo_ | R_code | Select multiple ORG | false | w4 horizontal | ORG1 | |||||||
date | R_date | Date | false | w2 | now() | |||||||
text | CODE1 | Text Full Calculated field | false | w2 | concat(${R_code},"-",format-date(${R_date},"%Y%m%d"),"-",${R_type},"-",${R_code}) | |||||||
text | CODE2 | Text Calculated field - only date | false | w2 | concat("–",format-date(${R_date},"%Y%m%d"),"–") | |||||||
note | CODE3 | Note Calculated field | false | w2 | concat(${R_code},"-",format-date(${R_date},"%Y%m%d"),"-",${R_type},"-",${R_code}) | |||||||
note | CODE4 | Note Calculated field - no date | false | w2 | concat(${R_code},"-",${R_type},"-",${R_code}) | |||||||
note | CODE5 | Note Calculated field - only date | false | w2 | concat("–",format-date(${R_date},"%Y%m%d"),"–") | |||||||
end_group |
So the whole calculated field I’m using is: concat(${R_code},"-",format-date(${R_date},"%Y%m%d"),"-",${R_type},"-",${R_code})
The screenshots of this examples is in my previou posts (DateTestForm)
Thank you for your interest and support.
There are no calculated fields for R_type and R_code, it was a failure in the table copy/pasted, they are the default values… Sorry
Hello @jborruel,
If you use a Note with a label and a calculation, like you do, KoBo transforms it as a read_only text field. You can see the difference in the UI in preview.
There seems to be bug in KoBo print probably. It doesn’t show the calculated value, if a note or a text field is read_only (and has a calculation) But it seems to works ok with integer and date type.
Here are examples to illustrate:
Note_01.xlsx (10.2 KB) .
and the screenshot (Preview)
and the print-out
A reported the print problem now: Print form loses calculated value for note and read_only text type