-
Notifications
You must be signed in to change notification settings - Fork 1
Fix typescript - #13
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
Fix typescript - #13
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
| throw new BadRequest("This reset link is invalid or has expired."); | ||
| } | ||
|
|
||
| await this.userService.updateUser(resetRequest.user as any, { password }); |
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.
Hash reset passwords before persisting
The reset flow updates the user with updateUser(...), which uses findByIdAndUpdate; Mongoose setters (like the bcrypt hash setter on User.password) are not applied to update queries by default. That means reset passwords get stored in plaintext, and bcrypt.compare during login will fail or throw because it expects a hash. Users who reset their password won’t be able to sign in, and you end up storing raw passwords. Consider hashing explicitly or switching to a findById + save path (or enable runSettersOnQuery) for this update.
Useful? React with 👍 / 👎.
| const isOverdue = (task: Task, today: Date) => { | ||
| const taskDate = normalizeDay(new Date(task.date)); | ||
| return isPendingOnDate(task, taskDate) && taskDate < today; |
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.
Evaluate overdue status across repeat occurrences
The overdue logic only checks the task’s original date (taskDate) against today. For repeating tasks, this misses overdue occurrences after the start date: if the start date was completed but a later daily/weekly occurrence was missed, isOverdue returns false and the task never appears in the overdue list. This makes the Calendar overdue view underreport compared to the agenda counts. Consider checking for any pending occurrence before today (similar to hasPendingBefore in HomeAgenda).
Useful? React with 👍 / 👎.
Edited from #12
On Lines 8 & 10, of app.ts, you changed
process.env.NODE_ENVtoimport.meta.NODE_ENVto support Vite's internal environment variables on build time, but NODE_ENV is undefined and should not be a.envvariable set by the developer. Instead, Vite exposes this asimport.meta.PRODandimport.meta.DEVbooleans.