-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
Store user feedback in db #798
Conversation
This patch collects and stores user feedback on a collection upon feedback button clicks Fixes: 496 Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
✅ Deploy Preview for eclipsefdn-adoptium-trss canceled.
|
@afifaniks Could you resolve the merge conflicts? Thanks |
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
@llxia merge conflicts have been resolved. |
Is this PR ready for review? If so, please move it out of the draft. Thanks |
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've not reviewed carefully, but are we santitizing input here?
@karianna Hi. There is no "dynamic" user input that we are storing for the time being. Do we still need sanitization for the data we are storing? Thanks. |
I think we're OK as long as someone can't hit that end point using CURL or other HTTP libs to send in whatever they like :-) |
Hello @llxia @LongyuZhang, looks like we have an issue with the file name. Any recommendation on file name generation? We may also try implementing the recommendations given here: https://codeql.github.com/codeql-query-help/go/go-path-injection/ |
@afifaniks This is a false alarm. We do not allow users to define any file path/name. The file path/name is pre-defined/hardcoded. To avoid the false alarm in the future, please put the output filename generate code within writeTestOutputToFile(). Hopefully, the code scan can understand it better. Also, we should not store the output whenever feedback is provided. We need to check if the output file exists or not first. Only store the output on disk if the file does not exist. @LongyuZhang On a related note, we are planning to run TRSS via docker. If we do, the files will be lost if we turn off the container unless the volume is used. |
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.
Besides checking if the output file exists or not first, we could also accumulate the user feedback for a particular issue, e.g. positive feedback 3 times, negative 2 times. So in the DB, we may need to save positive and negative feedback separately.
Regarding the docker folder, I think we can replace the file folder into the volume once starting running TRSS in docker.
@llxia @LongyuZhang have we decided on the new additions we are talking about? If yes, then I can start working on them. Thanks. |
@afifaniks 3 action items from the above comments:
|
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
@llxia As we are now considering keeping counters of positive and negative feedback, do we need the "accuracy" field in the database anymore? We can simply update the existing counter of a record each time feedback is provided, right? |
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
@llxia I have made some changes to store positive and negative counters with the aforementioned approach. Please have a look if it would justify the requirement. Thanks. |
const fileName = `${testName}_${buildName}_${buildNum}_${domain}.txt`; | ||
const outputPath = `${__dirname}/../../MachineLearningPrototype/data/JenkinsDataWithFeedback/${fileName}`; | ||
|
||
const fileExists = await fs.stat(outputPath).then( |
Check failure
Code scanning / CodeQL
Uncontrolled data used in path expression
); | ||
|
||
if (!fileExists) { | ||
await fs.writeFile(outputPath, testOutput); |
Check failure
Code scanning / CodeQL
Uncontrolled data used in path expression
@afifaniks Thanks for the update.
Yes, that is correct. We do not need the "accuracy" field anymore. It can be removed. We should display the counter in UI. For example, 5 positive feedback and 2 negative feedback: 👍 5 👎 2 The UI update can be in a separate PR. We still have |
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.
LGTM
@afifaniks if you plan to remove accuracy in another PR, please open an issue to track it. |
The separate issue to remove |
@llxia accuracy field is already removed in this PR. We are not writing this field in the database rather the value of the request parameter "accuracy" determines whether it is positive feedback or negative; i.e. 0 = negative, 1 = positive. That being said, do we want to remove the accuracy field from the request body? |
const fileName = `${testName}_${buildName}_${buildNum}_${domain}.txt`; | ||
const outputPath = `${__dirname}/../../MachineLearningPrototype/data/JenkinsDataWithFeedback/${fileName}`; | ||
|
||
const fileExists = await fs.stat(outputPath).then( |
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.
Please use existsSync()
: https://www.geeksforgeeks.org/node-js-fs-existssync-method/
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.
While stat() is providing us with an asynchronous way to check if the file exists or not, shall we move to a blocking method?
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.
yes, we should use existsSync()
. In asynchronous, the file could be deleted after the check.
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.
Thanks for the clarification
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.
Updated
await insertNewFeedback(db, req.body); | ||
} else { | ||
await updateFeedback(db, record, accuracy); | ||
} |
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 we should use upsert
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.
Hi @llxia, if we want to upsert we may have to query for the testOutput regardless of whether it's an insert or update operation. Branching them based on the record's existence may save us one separate database query. Although I have already implemented upsert on my local branch I thought I should ask what you think about this. Thanks.
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 upsert, we should be able to know to insert or update based on the return value.
testOutput is needed if the file does not exist on disk. Having the record in db does not mean that the testOutput is stored on disk.
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.
Mmm, I think I am missing something here. Are you talking to replace updateFeedback() with an upsert operation? What I inferred last time is to remove the check for the record's existence [getRecordIfExists()] and directly upsert the input rather than using two methods (insertNewFeedback, updateFeedback).
With the positive feedback counter and negative feedback counter, we do not need accuracy at all. |
Signed-off-by: Afif Al Mamun <afifanik@gmail.com>
Sorry @afifaniks , I was busy with the release. I think we can merge this PR for now. We can make the enhancements in the future PR. |
This patch collects and stores user feedback on a collection upon feedback button clicks
Fixes: #496
Signed-off-by: Afif Al Mamun afifanik@gmail.com