Conversation
…y did not put course subject/number in input data and did not allow for selection of class semester from the dropdown)
…gTitle and ratingContent to match design)
…r than just the aggregated ratings
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5131266c2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| disabled={!selectedCourse || termOptionsLoading} | ||
| loading={termOptionsLoading} |
There was a problem hiding this comment.
Restore course selection in add-rating modal
RatingFormBody now disables semester selection when selectedCourse is null, but this form no longer includes any control to set selectedCourse. In the Profile “Add Rating” flow, UserFeedbackModal is opened without an initialCourse, so users are stuck with disabled selects and cannot reach a valid submit state; this regresses adding ratings from Profile entirely.
Useful? React with 👍 / 👎.
| const ratings = await RatingModel.find({ subject, courseNumber }).lean(); | ||
| const sections = await SectionModel.find({ subject, courseNumber }) |
There was a problem hiding this comment.
Query class reviews by courseId to include cross-listings
getClassRatings fetches ratings/reviews by (subject, courseNumber) instead of courseId, which drops data submitted under cross-listed aliases. The rest of this module (e.g., createRatings) explicitly keys user ratings by courseId for cross-list support, so classReviews can now show incomplete/mismatched data on cross-listed course pages.
Useful? React with 👍 / 👎.
| await ReviewModel.updateOne( | ||
| { _id: review._id }, | ||
| { $addToSet: { helpfulVoters: userId }, $inc: { helpfulCount: 1 } } | ||
| ); |
There was a problem hiding this comment.
Make helpful vote increments atomic per voter
The upvote path combines $addToSet with unconditional $inc: { helpfulCount: 1 } after a non-transactional read. If two requests from the same user race, only one voter entry is added but both increments apply, so helpfulCount drifts above the true voter count; the inverse can happen on rapid unvotes as well. This should be guarded by a conditional update filter (or transaction) so count changes only when membership actually changes.
Useful? React with 👍 / 👎.
Removed overall rating