Return empty string as answer instead of OK for a label

[ShivamPokhriyal]

https://dimagi-dev.atlassian.net/browse/MOB-140

This PR will return an empty string as answer to a label question instead of "OK" text.

[ctsims]

Hey @shubham1g5 and @ShivamPokhriyal

Unfortunately, I don't think we can eliminate this default value.

The fact that labels return 'OK' is kind of a holdover from the old JavaRosa/ODK XForms standard that didn't have a lot of intent behind it, but I think now is hard for us to roll back.

Two things jump to mind but there may be more

1. The labels having a value is required for a common design pattern where people put a label in a form with a display condition which makes it appear when multiple questions together have answers that are invalid. The label says "Questions X, Y, and Z can't be... " and the validation condition is false(). That pattern won't work if the label doesn't return a value, since we only check validations for questions with answers.
2. I believe it's the case that labels only get their 'OK' answer when displayed, and I believe people sometimes use this to 'gate' certain behaviors to make them show up after the label is displayed.

I'm confident that #1 is in widespread use, so I don't think we can remove this unintentional side-effect without addressing it (which doesn't seem worth it to me),

[ShivamPokhriyal]

Hey @shubham1g5 and @ShivamPokhriyal

Unfortunately, I don't think we can eliminate this default value.

The fact that labels return 'OK' is kind of a holdover from the old JavaRosa/ODK XForms standard that didn't have a lot of intent behind it, but I think now is hard for us to roll back.

Two things jump to mind but there may be more

1. The labels having a value is required for a common design pattern where people put a label in a form with a display condition which makes it appear when multiple questions together have answers that are invalid. The label says "Questions X, Y, and Z can't be... " and the validation condition is false(). That pattern won't work if the label doesn't return a value, since we only check validations for questions with answers.
2. I believe it's the case that labels only get their 'OK' answer when displayed, and I believe people sometimes use this to 'gate' certain behaviors to make them show up after the label is displayed.

I'm confident that #1 is in widespread use, so I don't think we can remove this unintentional side-effect without addressing it (which doesn't seem worth it to me),

We can revert the changes of this PR.

[shubham1g5]

@ctsims thanks for catching it and @ShivamPokhriyal for reverting.

The labels having a value is required for a common design pattern where people put a label in a form with a display condition which makes it appear when multiple questions together have answers that are invalid. The label says "Questions X, Y, and Z can't be... " and the validation condition is false(). That pattern won't work if the label doesn't return a value, since we only check validations for questions with answers.

Wondering then if we should just return the label text itlsef instead of "OK" as an answer ? I guess people might have hardcoded "OK" in the validations instead of just checking for a non empty value. So it's not worth any changes in this behaviour.

[ctsims]

@shubham1g5 That's a good question. My very high level guess is that very few people are using the "OK" behavior specifically, as I haven't seen that in a long time, but as with most underspecified behaviors like this it can be really hard for us to investigate that.

@ShivamPokhriyal thanks for the PR. I apologize for this not being clearer anywhere in the system and the time spent writing and reverting. I'm going to write a test case out for this which has the information I mentioned here to prevent someone from having the same problem in the future.

[ShivamPokhriyal]

@shubham1g5 That's a good question. My very high level guess is that very few people are using the "OK" behavior specifically, as I haven't seen that in a long time, but as with most underspecified behaviors like this it can be really hard for us to investigate that.

@ShivamPokhriyal thanks for the PR. I apologize for this not being clearer anywhere in the system and the time spent writing and reverting. I'm going to write a test case out for this which has the information I mentioned here to prevent someone from having the same problem in the future.

Awesome 👍