QPPSF-5596 Non proprtion validation adjustments #66
Conversation
…mission, some properties can be added during validation
jbishtawi
requested review from
joshboley,
okeefem3,
djacksonsb and
chrisknightsb
| @@ -47,8 +47,11 @@ export function fileUploader(submissionBody, submissionFormat, requestHeaders, b | |||
| }; | |||
|
|
|||
| return fileUploaderUtil.validateSubmission(submissionBody, submissionFormat, baseOptions) | |||
There was a problem hiding this comment.
Can you just remove the call to fileUploaderUtil.validateSubmission altogether, as it seems we are not using the result anywhere?
There was a problem hiding this comment.
I do not think so, we still need to validate.
But maybe someone else has a better suggestion or agrees with you.
There was a problem hiding this comment.
No, you need it to validate that the submission structure is valid. It will throw an error if it's not valid.
| // QPPSF-5596, part of the validation logic for NonProportion measures for PY 2019, is to add a new field during validation, | ||
| // to prevent additional fields being added, we are going to send the original submission object | ||
| // to the api since the validation adds some properties | ||
| validatedSubmission = JSON.parse(submissionBody); |
There was a problem hiding this comment.
Is there a point in calling fileUploaderUtil.validateSubmission any more if the result is not used? Could we just replace that call with return fileUploaderUtil.getExistingSubmission(JSON.parse(submissionBody), baseOptions) instead?
idk what the validation logic did before, but is it correct to assume basically we are offloading validation to the submission api?? or is there something else that the validateSubmission function does that we need?
There was a problem hiding this comment.
all good questions, I have no clue
There was a problem hiding this comment.
No, see my comment above. Though I don't see the need for JSON.parse
There was a problem hiding this comment.
We need the JSON.parse here because in getExistingSubmission method we do something like submission.nationalProviderIdentifierand the fact that submission is string when passed into validateSubmission we need to parse it so the properties can be read from it
Does my comment makes sense?
There was a problem hiding this comment.
@joshboley , do you know if we need anything from the returned validateSubmission object? Or is it okay that we continue to use the submissionBody so long as it passed validation?
There was a problem hiding this comment.
No, that's the point of this PR...don't use the submission returned from the validate submission endpoint. It will have extra fields that will break your subsequent POST
There was a problem hiding this comment.
Right, just making sure that that included everything. Thanks :)
| @@ -59,6 +60,7 @@ const browserConfig = (env, argv) => { | |||
| }, | |||
| devtool: env && env.production == 'true' ? 'source-map' : 'eval-source-map', | |||
| module: _module, // module is already defined | |||
| mode: env && env.production === 'true' ? 'production' : 'development', | |||
There was a problem hiding this comment.
What was the point of changing these?
There was a problem hiding this comment.
those are editions, it would not build otherwise
There was a problem hiding this comment.
https://webpack.js.org/configuration/mode/
this will toggle development vs production level optimizations
so for instance in development mode webpack will name chunks and whatnot, vs in production they do module concatenation and other goodies
There was a problem hiding this comment.
Likely is new between webpack 3 and 4
| @@ -40,6 +40,7 @@ const defaultConfig = (env, argv) => { | |||
| path: path.resolve(__dirname, 'dist') | |||
| }, | |||
| devtool: env && env.production == 'true' ? 'source-map' : 'eval-source-map', | |||
| mode: env && env.production === 'true' ? 'production' : 'development', | |||
There was a problem hiding this comment.
see @okeefem3 comment above
During validation the submission API adds a new field to the submission object, what we need to do is used the submission object passed in from the client vs the validated Submission since we want to make sure additional fields do not trip the logic
When loading a bad IA-Quality submission, using the following file
2019-IA-Quality-bad.json.zip
When updating a negative non-proportion measure, using the file:
2019-non-proportion-quality.json.zip
When updating a negative non-proportion measure, using this file
2019-non-proportion-quality-bad.json.zip