System does not validate values from Results Options to be different #1594
Conversation
This prevents the same message to be displayed twice
| # Result values must be unique | ||
| value = api.to_float(value) | ||
| values = map(lambda ro: ro.get("ResultValue"), records) | ||
| values = filter(api.is_floatable, values) |
There was a problem hiding this comment.
I think this line can be removed
There was a problem hiding this comment.
Well, actually not sure. Did you add that for backwards compatibility with non-floatable values? But shouldn't fail then the other validator? or does that one come first?🤔
There was a problem hiding this comment.
The validator is triggered sequentially for all values registered for the subfield ResultValue (param value). Note the first thing I do in the function is to check if the value is floatable. If not, it returns the validation error. By filtering here only floatable values, those that are not "valid" are not considered (they have been handled already or they will be handled later, I don't care). The outcome is that no additional/duplicate error messages are rised.
TL;DR below
This validator only applies to "ResultValue" subfield, that stores the 'real' value used internally when an item from the display list is selected on results entry. This is the value that is eventually stored in analysis' Result field.
The other validator is for the "ResultText" subfield, that not necessarily has to be a floatable value. Quite often is an string, since is the value "displayed" in the selection list on results entry.
Basically, when the Analysis Service form is submitted, the system calls the two validators for each ResultOptions record, one for ResultValue subfield and the other one for ResultText field (param value from the function).
ResultValue must be floatable cause in fact, is the value that will be stored as the result. Note that therefore, it might be used in calculations, even if the result was entered by means of a selection list
These two validators are now independent, but there were a single validator before. Having a single validator has the problem that if a value for a subfield is wrong (either ResultText or ResultValue), the error message will be displayed twice, cause the validator machinery triggers the function twice, one for the value of ResultValue subfield and another for the value of ResultText subfield. Since there was a single validator that was checking everything regardless of the value passed-in and the subfield, two validation failures were happening (and the err message was displayed twice).
Description of the issue/feature this PR addresses
This Pull Request makes the Result Options validator (analysis service) to also check for duplicates in result texts and values
Linked issue: #1278
Current behavior before PR
User can set up Result Options for an analysis service with duplicated values and texts.
Desired behavior after PR is merged
User cannot set up Result Options for an analysis service with duplicated values and texts.
--
I confirm I have tested this PR thoroughly and coded it according to PEP8
and Plone's Python styleguide standards.