feat: filter approved OOO periods in user status retrieval

[vinit717]

Date: 18-03-26

Developer Name: @vinit717

Description

Update the query to filter the request based on state

Documentation Updated?

• Yes
• No

Under Feature Flag

• Yes
• No

Database Changes

• Yes
• No

Breaking Changes

• Yes
• No

Development Tested?

• Yes
• No

Screenshots

Screenshot 1

Test Coverage

Screenshot 1

Additional Notes

[coderabbitai]

Summary by CodeRabbit

• Bug Fixes
  • Improved filtering of out-of-office periods to ensure only approved statuses are returned, leveraging database-level filtering for more reliable data accuracy.

Walkthrough

This change modifies utils/userStatus.js to move OOO period filtering from runtime validation to the database query layer by importing REQUEST_STATE and filtering directly with REQUEST_STATE.APPROVED. The runtime state validation check is removed, streamlining the data retrieval process.

Changes

Cohort / File(s)	Summary
Database Query Optimization utils/userStatus.js	Added REQUEST_STATE import and moved OOO filtering to database query using REQUEST_STATE.APPROVED. Removed redundant runtime validation of data.state after document retrieval.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• AnujChhikara
• MayankBansal12
• iamitprakash

Poem

🐰 A filter moves from run-time's gleam,
To databases—a leaner scheme,
No more checking after the fetch,
Just approved ones in the net we catch!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: filter approved OOO periods in user status retrieval' directly and clearly describes the main change: filtering OOO periods by approval state in the database query.
Description check	✅ Passed	The description states 'Update the query to filter the request based on state' which directly relates to the changeset's core modification of filtering approved OOO periods by state.
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 docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/get-request-query

📝 Coding Plan

• Generate coding plan for human review comments

---

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]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@utils/userStatus.js`:
- Around line 88-93: The Firestore query in utils/userStatus.js using
requestsModel with filters requestedBy, type, state and a range on until
requires a composite index; add a firestore.indexes.json (or add to
firebase.json indexes) that defines a composite index for the requests
collection with fields requestedBy (ASCENDING), type (ASCENDING), state
(ASCENDING), and until (ASCENDING). Ensure the index is deployed with firebase
deploy --only firestore:indexes so the query in utils/userStatus.js (the
snapshot query using REQUEST_STATE.APPROVED and windowStart) no longer throws
FAILED_PRECONDITION and causes the catch that returns an empty array (affecting
downstream logic in discordactions.js) to be bypassed.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 75d78654-4426-4580-9212-43902958f2ed

📥 Commits

Reviewing files that changed from the base of the PR and between 750beab and fb78c67.

📒 Files selected for processing (1)

• utils/userStatus.js