-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculation Endpoints: Adds Validation and Tests #1521
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the file name from
.example.env -> .env.example as it was before (better naming)
# EMAIL_SENDER= | ||
# EMAIL_PUBLIC_COMMENT_LA_CITY= | ||
# EMAIL_PUBLIC_COMMENT_WEB_TEAM= | ||
# SENDGRID_API_KEY=SG.testAPIkey |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the testing environment is local and isolated, I added the dummy variables with fake API keys into the example .env file since we already have them in the CI file .github/workflows/tdm-server-tests.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean tdm-server-tests can run with .env.example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope! I just changed it because VSCode has better highlighting with the new name. Also included the variables so new members could run the tests easily without the formal variables. I tried to get this to work unsuccessfully with ./push.sh
An alternate strategy I thought of this morning is a function in the push script that can uncomment the test variables for the server tests and then re-comment upon completion. I'll have to check if this is viable, but editing the .env file with code feels unkosher. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't edit the .env file. Instead, switch between files. That way the server tests can have one. Local dev can have another, prod, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was looking into that but had some concerns.
Since the container has a single database that is restored before every test suite (i.e. before every test file), the logic that handles this will call tedious-pool.js
the connection logic from the server which will consume the original .env file. this means that this file would require a conditional to see which .env
to consume right? Is this crufty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It means everywhere we use dotenv should probably go through a tdmenv wrapper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so new issue for refactoring codebase with this ^
@@ -38,7 +38,7 @@ const post = async item => { | |||
request.output("id", mssql.Int, null); | |||
const response = await request.execute("Calculation_Insert"); | |||
|
|||
return response.outputParameters; | |||
return response.output; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was returning an undefined variable so I used the VSCode debugger to check what the property was supposed to be - it's been rectified now and actually returns the id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
server/__tests__/calculation.test.js
Outdated
}); | ||
|
||
// PUT "/:id" Update calculation using inexistent id (Admin only) | ||
//TODO: this endpoint logic needs error handling for inexistent ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding issue - inexistent id's also returned 200 status codes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
server/__tests__/calculation.test.js
Outdated
}); | ||
|
||
// DELETE "/:id" Delete a calculation using inexistent id (Admin only) | ||
//TODO: this endpoint needs error handling for inexistent ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding issue - inexistent id's also returned 200 status codes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. What prompted adding the schema validation?
server/__tests__/calculation.test.js
Outdated
}); | ||
|
||
// DELETE "/:id" Delete a calculation using inexistent id (Admin only) | ||
//TODO: this endpoint needs error handling for inexistent ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
server/__tests__/calculation.test.js
Outdated
}); | ||
|
||
// PUT "/:id" Update calculation using inexistent id (Admin only) | ||
//TODO: this endpoint logic needs error handling for inexistent ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
# EMAIL_SENDER= | ||
# EMAIL_PUBLIC_COMMENT_LA_CITY= | ||
# EMAIL_PUBLIC_COMMENT_WEB_TEAM= | ||
# SENDGRID_API_KEY=SG.testAPIkey |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean tdm-server-tests can run with .env.example?
name: { | ||
type: "string", | ||
minLength: 1, | ||
pattern: "^[a-zA-Z '.-]+$" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen in the UX if the user breaks validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the create, update , delete, calculation endpoints are not used by the client currently - future implementation. I think we mostly use the GET endpoints. Also, there is only '1' calculation in the db currently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then how do you know if this validation is right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The answer could be you are making stubs, but then the code needs a comment that the regex are not spec'ed.
I am looking for answers to why in the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And unused endpoints are risky. I am inclined to delete dead code as a security risk.
Is there a plan for when to add it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
excellent question. Ill have to refer to @entrotech
not to mention validation logic may even require numbers to be valid (not included currently)
Request from John to add validation for all web api endpoints - #1238 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the name of security, I recommend deleting unused service methods. This change becomes much smaller. 😀
After looking at #1238, I have better context. Probably better to Write tests for the faq crud APIs first. Those ones are accessible in the client, and need the attention. |
Ok, editing calculations is covered by issuer #46. Given the nature of how rules work, I suggest only devs should ever change rules. They are too finicky for normal users to get right. Allowing an admin to delete a rule is a recipe for disaster I recommend:
What do you think @entrotech ? |
@agosmou is this ready to roll? are you going to create issues after merging? |
@ZekeAranyLucas comments above are spot-on. Early on, we had thoughts of implemented admin screens for versioning the calculations, allowing a super-admin to edit rules on an existing calculation to create a new version, and apply that version to future projects, but the implications are kinda scary, and I like having enough friction in changing rules that they are made mostly by DB Migrations and an occasional code change, so they need to go through a QA process by people that know what they are doing. |
@ZekeAranyLucas @entrotech
|
The 'rule service' uses the getById service from the 'calculations' server service so this will remain for now. |
The above requested changes were addressed in the latest commit f1dcd6d |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I trust you two to have worked out the details on this PR. I am agreeing on deleting the endpoints you mentioned.
BTW, there is a remnant of Issue #46 that I can't bring myself to remove, just cause it's kinda cool. Log in as an admin and change the client path to /admin and it give you an interesting view of the rules that make up the calculation.
@agosmou you can merge this yourself, if you want.
/admin is cool! i wouldn't remove that. |
Fixes #1499
Sub-Issue from #1238
What changes did you make?
Why did you make the changes (we will use this info to test)?
Notes
See Test Wiki for testing documentation on TDM Calculator