feat: enhance User schema validation for better data integrity

[jikrana1]

Description

Enhanced the User schema with stronger validation rules to improve data integrity and ensure more consistent data storage.

Changes Made

• Added custom error messages for all required fields
• Added minlength: 2 and maxlength: 50 constraints for name
• Added regex-based email format validation
• Added minlength: 6 for password at schema level

Related Issue

Closes #53

Summary by CodeRabbit

• Improvements
  • Enhanced validation error messages for user profile fields (name, email, password)
  • Added minimum and maximum length requirements for user names
  • Added minimum length requirement for passwords
  • Improved email format validation

[coderabbitai]

📝 Walkthrough

Walkthrough

backend/src/models/User.js expands the Mongoose userSchema validation: name gains explicit required/minlength/maxlength messages, email gains explicit messages and a regex match constraint, and password gains an explicit required message and a minlength constraint. The exported User model is unchanged.

Changes

User Schema Validation

Layer / File(s)	Summary
userSchema field validation rules backend/src/models/User.js	name adds minlength/maxlength with custom messages; email adds a regex match constraint and explicit messages; password adds an explicit required message and minlength: 6 with a custom message. Schema shape and timestamps: true are unchanged.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐇 A rabbit checked the fields one day,
Name too short? Not on my way!
Email must match the proper form,
Password length — a new-set norm.
The schema's tight, the data's bright,
Every hop feels just right! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately summarizes the main change: enhancing User schema validation for better data integrity, which aligns with the primary objective of the changeset.
Linked Issues check	✅ Passed	The PR changes implement all coding requirements from issue #53: custom validation messages, minlength/maxlength for name, email regex validation, password minlength, and maintains trim consistency.
Out of Scope Changes check	✅ Passed	All changes to User.js are directly related to schema validation enhancements specified in issue #53. No out-of-scope modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

backend/src/models/User.js (1)

24-24: Schema password minlength is redundant and misleading.

The raw password is validated at backend/src/Utils/Validetor.js:18 (checks password.length < 6) before User.create is called at userAuth.js:14. However, by that time the password has been hashed at userAuth.js:12, so the schema validator runs against the bcrypt hash—not the raw password. This creates redundancy: the schema constraint cannot enforce the intended raw-password length policy and adds confusion about where validation actually occurs.

Consider either removing the schema minlength (since validation is already in the controller) or moving password hashing into a model hook to centralize all password-related logic in one place.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/src/models/User.js` at line 24, Remove the minlength constraint from
the password field in the User schema (at the location where minlength is set to
[6, "Password must be at least 6 characters long"]). This constraint is
redundant because the raw password is already validated in
backend/src/Utils/Validator.js before being hashed at userAuth.js, and by the
time User.create is called, the password has been hashed—making the schema
validator operate on the bcrypt hash rather than the raw password. The existing
validation in the controller layer is sufficient and removes confusion about
where password length validation actually occurs.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@backend/src/models/User.js`:
- Line 24: Remove the minlength constraint from the password field in the User
schema (at the location where minlength is set to [6, "Password must be at least
6 characters long"]). This constraint is redundant because the raw password is
already validated in backend/src/Utils/Validator.js before being hashed at
userAuth.js, and by the time User.create is called, the password has been
hashed—making the schema validator operate on the bcrypt hash rather than the
raw password. The existing validation in the controller layer is sufficient and
removes confusion about where password length validation actually occurs.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0032c649-fdfb-48ea-9391-6691b78a1893

📥 Commits

Reviewing files that changed from the base of the PR and between b13fd53 and e0e83e2.

📒 Files selected for processing (1)

• backend/src/models/User.js