Skip to content

Conversation

@nishantharkut
Copy link

@nishantharkut nishantharkut commented Jan 10, 2026

What kind of change does this PR introduce?

Refactoring : src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx

  • Reduced the number of lines of code from 713 to 660 lines (53 lines saved)
  • De-Duplication of the Radio Button Functions by creating a separate File : ApplyToSelector.tsx
  • Made ApplyToSelector as an reusable Component
  • Changed import from deprecated Modal to baseModal on the latest shared-Components Issue.
  • Changed import from restricted @mui/x-date-pickers Datepicker to shared Datepicker Component based on the latest shared-component Issue.
  • Updated tests to use getByTestId workaround for BaseModal's Duplicate role="dialog" issue as highlighted in the Bug Report: BaseModal adds duplicate role="dialog" causing test failures #6312

Issue Number:

Fixes #6250

Snapshots/Videos:

N/A

If relevant, did you update the documentation?

N/A

Summary

I was assigned to the issue #6250 in which I had to refactor the src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx File. I saw the following issues that could be refactored :

  • it was using a similar function for the Radio Button which De-duplicated by creating ApplyToSelector.tsx File which is now reusable.
  • it was using outdated Modal Import so I changed the deprecated Modal import from react-bootstrap to BaseModal from src/shared-components as per ESLint rules.
  • it was using outdated DatePicker Import from @mui/x-date-pickers so I changed the deprecated import to the latest DatePicker component from src/shared-components as per ESLint rules.
  • Test workaround - This issue as raised in Bug Report: BaseModal adds duplicate role="dialog" causing test failures #6312 led to failing of the tests when I ran them. Hence, I used getByTestId('dialog') instead of getByRole('dialog').

Line count reduction: 713 → 660 lines

Does this PR introduce a breaking change?

No

Checklist

CodeRabbit AI Review

  • I have reviewed and addressed all critical issues flagged by CodeRabbit AI
  • I have implemented or provided justification for each non-critical suggestion
  • I have documented my reasoning in the PR comments where CodeRabbit AI suggestions were not implemented

Test Coverage

  • I have written tests for all new changes/features
  • I have verified that test coverage meets or exceeds 95%
  • I have run the test suite locally and all tests pass

Other information

Have you read the contributing guide?

Yes

Summary by CodeRabbit

  • New Features

    • Added an "Apply to" selector to choose applying an action item to an entire series or a single instance.
  • Refactor

    • Modal updated to use the new selector, consolidated modal wrapper, reorganized assignment UI, improved assignment/date controls, accessibility/testability enhancements, and safer state handling.
  • Tests

    • Added selector tests and updated modal tests for more robust element targeting and date interactions.

✏️ Tip: You can customize this high-level summary in your review settings.

Copilot AI review requested due to automatic review settings January 10, 2026 18:56
@keploy
Copy link

keploy bot commented Jan 10, 2026

To generate Unit Tests for this PR, please click here.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 10, 2026

Walkthrough

Adds a new ApplyToSelector component and type, integrates it into ActionItemModal (replacing in-file radio UI), updates DatePicker/test selectors and modal data-testids, and adjusts related state, initialization, and tests.

Changes

Cohort / File(s) Summary
ApplyToSelector component
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx, src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
New radio-group component exporting ApplyToType. Renders "entire series" and "this event only" via i18n, accepts applyTo and onChange, and includes tests for rendering, initial selection, and click-driven onChange.
ApplyToSelector types
src/types/AdminPortal/ApplyToSelector/interface.ts
New `ApplyToType = 'series'
ActionItemModal implementation
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
Replaced in-file radio UI with ApplyToSelector; changed applyTo state to ApplyToType; updated DatePicker import/path and set data-testid="assignmentDate"; switched to BaseModal with dataTestId="actionItemModal"; adjusted volunteer/volunteerGroup init, filtering, and guards; added aria attributes and refreshed conditional rendering.
ActionItemModal tests
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
Updated tests to use data-testid="actionItemModal" container, changed date picker queries to assignmentDate container and inner input, handled multiple volunteerGroup matches, and aligned awaits/assertions to the new modal presence hooks.

Sequence Diagram(s)

sequenceDiagram
  actor User
  participant UI as ActionItemModal (UI)
  participant Modal as BaseModal
  participant Selector as ApplyToSelector
  participant Picker as DatePicker
  participant API as Backend

  User->>UI: open modal
  UI->>Modal: render modal container (actionItemModal)
  UI->>Selector: render with current applyTo
  User->>Selector: choose 'series' or 'instance'
  Selector-->>UI: onChange(applyTo)
  User->>Picker: pick assignment date
  Picker-->>UI: emit selected date
  User->>Modal: submit form
  UI->>API: call create/update mutation (includes applyTo & date)
  API-->>UI: response
  UI-->>User: close modal / show result
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 8
✅ Passed checks (8 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: extracting the ApplyToSelector component from ActionItemModal as part of a refactoring effort.
Description check ✅ Passed The PR description is complete with all required sections: change type, issue number (#6250), summary, checklist completion, and contribution guide acknowledgment.
Linked Issues check ✅ Passed The PR successfully addresses #6250 objectives: reduces lines from 713 to 660, extracts ApplyToSelector as reusable component, replaces deprecated Modal/DatePicker imports, updates tests with ≥95% coverage, and maintains functionality.
Out of Scope Changes check ✅ Passed All changes are within scope: ApplyToSelector extraction, import replacements (BaseModal, DatePicker), and test updates directly support the #6250 refactoring objectives.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Test Coverage Gate ✅ Passed PR exceeds 95% test coverage requirement with 95.24% Statements, 95.63% Lines, and 96.59% Functions, confirmed by 83 passing tests and GitHub Actions CI/CD validation.
Typescript Compilation ✅ Passed TypeScript compilation check passed successfully with exit code 0 and no errors or warnings.
Component Architecture Compliance ✅ Passed The ApplyToSelector component maintains proper separation of concerns with interfaces in a dedicated file, is correctly placed in the AdminPortal folder following project patterns, and uses correct import paths without inline interface definitions.

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

✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 23f2237 and d8b3591.

⛔ Files ignored due to path filters (4)
  • docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md is excluded by !**/docs/docs/**
📒 Files selected for processing (5)
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧰 Additional context used
📓 Path-based instructions (4)
src/**/components/**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

All components must follow reusable component policy: No inline interfaces, correct portal placement, wrapper usage

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧠 Learnings (10)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T16:45:49.201Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6241
File: src/components/AdminPortal/OrgPeopleListCard/OrgPeopleListCard.tsx:12-16
Timestamp: 2026-01-08T16:45:49.201Z
Learning: In TSX components, prefer flat JSDoc parameter documentation format (e.g., param id, param toggleRemoveModal) over the nested format (param props.id). The nested form can break editor parsing. When a component accepts a props object, destructure the props in the function signature to align with the flat JSDoc style (e.g., function MyComp({ id, toggleRemoveModal }: Props) { ... }). Ensure all param tags correspond to the destructured props and reflect actual component props to improve editor support and readability.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-06T21:27:50.880Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6222
File: src/utils/userUpdateUtils.ts:22-22
Timestamp: 2026-01-06T21:27:50.880Z
Learning: In the Talawa Admin codebase, the i18n extraction tool can misclassify TypeScript generic syntax (e.g., (obj: T): Partial) as translatable content. Suppress these false positives by adding a // i18n-ignore-next-line comment directly above the line with the type declaration or generic function signature. Apply this only to TS code where misclassification is confirmed; avoid blanket suppression.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2026-01-07T14:21:19.711Z
Learnt from: cotishq
Repo: PalisadoesFoundation/talawa-admin PR: 6198
File: src/setup/setup.ts:123-124
Timestamp: 2026-01-07T14:21:19.711Z
Learning: Use TSDoc (eslint-plugin-tsdoc) instead of JSDoc. Do not wrap type names in curly braces in throws and returns. Write as "throws Error" and "returns Promise<void>" (no braces). Curly-brace usage causes tsdoc-malformed-inline-tag and tsdoc-escape-right-brace lint errors. Apply this rule to all TypeScript source files (e.g., src/**/*.ts) to ensure consistency.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧬 Code graph analysis (3)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • InterfaceApplyToSelectorProps (11-16)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
🔇 Additional comments (10)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)

1-71: LGTM! Well-structured test file with good coverage.

The test file follows best practices:

  • Proper test isolation with vi.clearAllMocks() in afterEach (per learnings)
  • Uses userEvent.setup() for user interactions
  • Tests both initial states and onChange callbacks
  • Uses accessible queries (getByLabelText)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)

1-16: LGTM! Type definitions follow reusable component policy.

The interface file correctly:

  • Defines types in the designated src/types/AdminPortal/ directory
  • Uses the Interface<ComponentName>Props naming convention
  • Includes TSDoc documentation on the type and interface
  • Exports ApplyToType for reuse across the codebase
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (1)

627-634: Good test isolation setup.

The beforeEach and afterEach blocks with vi.clearAllMocks() ensure proper test isolation, which aligns with project guidelines. Based on learnings, this pattern is required for all spec files.

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (6)

11-16: Good refactoring - imports updated correctly.

The imports are correctly updated:

  • DatePicker from the shared-components path
  • BaseModal from the shared-components path (replacing deprecated react-bootstrap Modal)
  • ApplyToSelector from AdminPortal components
  • ApplyToType from the types directory

98-98: State typing updated correctly.

The applyTo state now uses the exported ApplyToType instead of an inline literal union, improving type consistency across the codebase.


169-173: Clean boolean coercion.

Using Boolean() for explicit type coercion is cleaner and more readable than alternatives like double negation (!!).


441-449: ApplyToSelector integration is correct.

The component is rendered in the appropriate scenarios:

  1. Create mode with recurring events (isRecurring && !editMode)
  2. Edit mode for template items that aren't instance exceptions

The props are correctly wired to the component state.


433-440: BaseModal integration looks correct.

The BaseModal usage replaces the deprecated react-bootstrap Modal correctly, with proper props for show, onHide, title, and dataTestId.


596-608: No action required — the prop naming is correct.

The DatePicker component's interface explicitly defines the test ID prop as 'data-testid' (kebab-case string literal, line 38 of DatePicker.tsx), which is why the ActionItemModal correctly uses data-testid="assignmentDate" at line 602. Similarly, BaseModal defines its test ID prop as dataTestId (camelCase), which is correctly used at line 439. Each component accepts the prop naming defined in its own interface, so there is no inconsistency.

src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)

1-49: Component correctly implements ApplyToSelector with proper architecture and testing.

All verification complete:

  • ✅ i18n keys (applyTo, entireSeries, thisEventOnly) present in all 5 locale files
  • ✅ Props interface properly defined in src/types/AdminPortal/ApplyToSelector/interface.ts
  • ✅ Test file comprehensive (71 lines) covering render, state, and user interactions
  • ✅ Component follows reusable component policy (correct portal, no inline interfaces, TSDoc present)
  • ✅ Zero TypeScript errors
  • ✅ Semantic HTML (fieldset/legend) for accessibility

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

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

@github-actions
Copy link

Our Pull Request Approval Process

This PR will be reviewed according to our:

  1. Palisadoes Contributing Guidelines

  2. AI Usage Policy

Your PR may be automatically closed if:

  1. Our PR template isn't filled in correctly

  2. You haven't correctly linked your PR to an issue

Thanks for contributing!

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR is Part 1/5 of refactoring the ActionItemModal.tsx file to reduce its size and improve maintainability. The PR successfully extracts duplicated radio button logic into a reusable ApplyToSelector component and updates deprecated imports.

Changes:

  • Extracted ApplyToSelector component to eliminate duplicated radio button logic for selecting between 'series' and 'instance' application scopes
  • Migrated from deprecated react-bootstrap Modal to shared BaseModal component
  • Migrated from deprecated @mui/x-date-pickers DatePicker to shared DatePicker component
  • Updated all test files to use getByTestId workaround for BaseModal's duplicate role="dialog" issue

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/types/AdminPortal/ApplyToSelector/interface.ts Defines TypeScript types for ApplyToSelector component with proper documentation
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx New reusable component for radio group selector with proper i18n support
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx Comprehensive test coverage for ApplyToSelector component
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx Refactored to use ApplyToSelector component and updated deprecated imports, reduced from 713 to 660 lines
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx Updated all test assertions to use getByTestId workaround for BaseModal duplicate role issue
docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md Auto-generated documentation for ApplyToType type alias
docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md Auto-generated documentation for component props interface
docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md Auto-generated documentation for ApplyToSelector component
docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md Updated line number reference in auto-generated docs

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@palisadoes
Copy link
Contributor

@nishantharkut Refactor your tests to use BaseModal

@nishantharkut nishantharkut force-pushed the refactor/ActionItemModal branch from 7124624 to 3539ece Compare January 10, 2026 19:03
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (4)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (2)

814-817: Avoid fireEvent.submit(...) on non-form elements; submit the <form> or click the submit button.
Some tests use document.querySelector('form') (good), but others submit the submit button or mix patterns. Prefer one of:

  • fireEvent.submit(formElement)
  • await user.click(screen.getByTestId('submitBtn'))

Also applies to: 1151-1155, 1197-1201, 1356-1360


3542-3554: Rewrite ActionItemModal test: data-testid="assignmentDate" resolves to the input element directly, not a container.

The shared DatePicker component applies data-testid directly to the Form.Control input element (line 144 of DatePicker.tsx), not to a wrapper container. The test's assumption is incorrect:

  • screen.getByTestId('assignmentDate') returns the input element, not a container
  • querySelector('input') on an input element returns null
  • The test should use the testid directly: const dateInput = screen.getByTestId('assignmentDate');

Alternatively, use role-based queries: screen.getByRole('textbox').

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)

101-170: Bug risk: applyTo auto-sets to 'series' for any actionItem, which can clear non-template assignments during edit.
On Line 365-367, setApplyTo('series') runs for non-template items too, but applyTo then drives filtering (Line 142+) and clearing (Line 402+). This can drop the selected volunteer/group in edit mode for non-template items.

Proposed patch (scope applyTo only when selector is actually relevant)
-  // Separate useEffect for applyTo initialization
-  useEffect(() => {
-    if (actionItem?.isInstanceException) {
-      setApplyTo('instance');
-    } else if (actionItem) {
-      setApplyTo('series');
-    }
-  }, [actionItem]);
+  // Initialize applyTo only for recurring/template semantics
+  useEffect(() => {
+    if (!isRecurring) {
+      setApplyTo('instance');
+      return;
+    }
+
+    if (!actionItem) {
+      setApplyTo('instance');
+      return;
+    }
+
+    // Only template (non-exception) items can target the whole series
+    if (actionItem.isTemplate && !actionItem.isInstanceException) {
+      setApplyTo('series');
+    } else {
+      setApplyTo('instance');
+    }
+  }, [actionItem, isRecurring]);
-  useEffect(() => {
+  useEffect(() => {
+    // applyTo filtering is only meaningful when we can actually choose series vs instance
+    const applyToIsRelevant =
+      (isRecurring && !editMode) ||
+      (editMode && actionItem?.isTemplate && !actionItem.isInstanceException);
+    if (!applyToIsRelevant) return;
+
     // Check if current selections are still valid with the new filter (for both create and edit modes)
     if (
       selectedVolunteer &&
       applyTo === 'series' &&
       !selectedVolunteer.isTemplate
     ) {
       setSelectedVolunteer(null);
       handleFormChange('volunteerId', '');
     }
     if (
       selectedVolunteerGroup &&
       applyTo === 'series' &&
       !selectedVolunteerGroup.isTemplate
     ) {
       setSelectedVolunteerGroup(null);
       handleFormChange('volunteerGroupId', '');
     }
-  }, [applyTo, selectedVolunteer, selectedVolunteerGroup]);
+  }, [applyTo, selectedVolunteer, selectedVolunteerGroup, isRecurring, editMode, actionItem]);

Also applies to: 361-428


211-236: Guard against baseEvent?.id being undefined when creating series-level items.
On Line 233-234 you may send { eventId: undefined } if baseEvent isn’t provided, which can hard-fail GraphQL validation.

Proposed patch
   const createActionItemHandler = async (e: FormEvent): Promise<void> => {
     e.preventDefault();
     try {
@@
+      if (eventId && isRecurring && applyTo === 'series' && !baseEvent?.id) {
+        NotificationToast.error({ key: 'unknownError', namespace: 'errors' });
+        return;
+      }
+
       const input: ICreateActionItemInput = {
@@
         ...(eventId &&
           (isRecurring
             ? applyTo === 'series'
               ? { eventId: baseEvent?.id }
               : { recurringEventInstanceId: eventId }
             : { eventId })),
       };
🤖 Fix all issues with AI agents
In @src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx:
- Around line 1-68: The interaction tests use direct await userEvent.click(...)
which is flaky with @testing-library/user-event v14+; update each test that
performs clicks (the two "calls onChange..." tests) to create a user via const
user = userEvent.setup() and replace await userEvent.click(...) with await
user.click(screen.getByLabelText(...)); keep renderComponent and the onChange
vi.fn() usage unchanged so only the click calls are migrated to the setup
pattern.

In @src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx:
- Around line 11-47: Replace the non-semantic Form.Group/Form.Label grouping in
ApplyToSelector with a semantic fieldset and legend so the radio buttons are
announced as a group by screen readers: wrap the two Form.Check components in a
<fieldset> and render the group label as a <legend> (using t('applyTo')), keep
the existing name/id/checked/onChange props on both Form.Check controls, and
remove the standalone Form.Label so the legend is the accessible label for the
group; ensure the legend text is visible and that each radio retains its unique
id.

In @src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx:
- Around line 438-447: Replace the nested ternary assigned to Form's
onSubmitCapture by computing a single onSubmit handler variable above the JSX:
determine handler using the existing symbols (editMode, actionItem?.isTemplate,
applyTo) and choose between updateActionItemHandler,
updateActionForInstanceHandler, and createActionItemHandler accordingly, then
pass that variable into the Form as onSubmit (not onSubmitCapture); this
centralizes the conditional logic for easier auditing and prevents regressions
around template vs instance rules.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 944396f and 7124624.

⛔ Files ignored due to path filters (4)
  • docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md is excluded by !**/docs/docs/**
📒 Files selected for processing (5)
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
src/**/components/**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

All components must follow reusable component policy: No inline interfaces, correct portal placement, wrapper usage

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧠 Learnings (10)
📚 Learning: 2026-01-06T21:27:50.880Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6222
File: src/utils/userUpdateUtils.ts:22-22
Timestamp: 2026-01-06T21:27:50.880Z
Learning: In the Talawa Admin codebase, the i18n extraction tool can misclassify TypeScript generic syntax (e.g., (obj: T): Partial) as translatable content. Suppress these false positives by adding a // i18n-ignore-next-line comment directly above the line with the type declaration or generic function signature. Apply this only to TS code where misclassification is confirmed; avoid blanket suppression.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2026-01-07T14:21:19.711Z
Learnt from: cotishq
Repo: PalisadoesFoundation/talawa-admin PR: 6198
File: src/setup/setup.ts:123-124
Timestamp: 2026-01-07T14:21:19.711Z
Learning: Use TSDoc (eslint-plugin-tsdoc) instead of JSDoc. Do not wrap type names in curly braces in throws and returns. Write as "throws Error" and "returns Promise<void>" (no braces). Curly-brace usage causes tsdoc-malformed-inline-tag and tsdoc-escape-right-brace lint errors. Apply this rule to all TypeScript source files (e.g., src/**/*.ts) to ensure consistency.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-08T16:45:49.201Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6241
File: src/components/AdminPortal/OrgPeopleListCard/OrgPeopleListCard.tsx:12-16
Timestamp: 2026-01-08T16:45:49.201Z
Learning: In TSX components, prefer flat JSDoc parameter documentation format (e.g., param id, param toggleRemoveModal) over the nested format (param props.id). The nested form can break editor parsing. When a component accepts a props object, destructure the props in the function signature to align with the flat JSDoc style (e.g., function MyComp({ id, toggleRemoveModal }: Props) { ... }). Ensure all param tags correspond to the destructured props and reflect actual component props to improve editor support and readability.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧬 Code graph analysis (4)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • InterfaceApplyToSelectorProps (11-16)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/shared-components/BaseModal/BaseModal.tsx (1)
  • BaseModal (69-140)
🔇 Additional comments (4)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)

1-16: Type + props interface placement/naming looks policy-compliant.
ApplyToType + InterfaceApplyToSelectorProps are correctly centralized under src/types/AdminPortal/... (no inline prop interfaces in the component).

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (2)

655-669: Good: switching modal assertions to getByTestId('actionItemModal') matches the BaseModal workaround.
This aligns the test suite with the new modal implementation and avoids ambiguity from duplicate role="dialog".

Also applies to: 700-708, 750-759, 840-848, 864-872, 905-913, 968-976, 1041-1049, 1140-1150, 1226-1229, 1287-1300, 1321-1329, 1344-1355, 1386-1402, 1417-1429, 1442-1455, 1468-1480, 1495-1502, 1533-1544, 1558-1590, 1603-1616, 1641-1649, 1708-1722, 1762-1768, 1808-1814, 1866-1901, 1922-1936, 1957-1975, 2012-2044, 2101-2124, 2172-2202, 2248-2277, 2323-2355, 2401-2433, 2485-2547, 2563-2630, 2646-2653, 2672-2681, 2701-2710, 2732-2801, 2822-2838, 2859-2871, 2950-3011, 3061-3099, 3192-3241, 3296-3343, 3363-3380, 3431-3455, 3471-3492, 3505-3523, 3536-3555, 3568-3589, 3602-3620, 3633-3659, 3674-3685, 3698-3705, 3736-3747, 3760-3821, 3835-3848, 3880-3892, 3912-3991, 4071-4127, 4142-4199, 4223-4227, 4242-4281, 4309-4313


1-1626: Manual verification required—sandbox environment unable to execute typecheck and coverage commands.

The sandbox environment lacks installed dependencies (node_modules missing), preventing execution of pnpm run typecheck and pnpm run test:coverage. Run these commands in your development environment to verify:

  1. TypeScript check: pnpm run typecheck must pass without errors
  2. Coverage validation: pnpm run test:coverage then check coverage/coverage-summary.json to confirm src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx has ≥95% coverage across all metrics (lines, branches, functions, statements)

Please provide the output from both commands to complete verification.

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (1)

601-614: Verify DatePicker testability: data-testid="assignmentDate" should be stable.
The spec file queries getByTestId('assignmentDate') and then querySelector('input'). Please ensure the shared DatePicker guarantees this structure (or adjust tests to its intended API).

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In @src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx:
- Around line 483-533: The two Chip components (the one for 'volunteer' and the
one for 'volunteerGroup') do not expose their disabled state to assistive tech;
when isVolunteerChipDisabled or isVolunteerGroupChipDisabled is true, add
appropriate ARIA attributes to communicate non-interactivity (e.g.,
aria-disabled="true" and an aria-label that includes “disabled” or a descriptive
label) and ensure clickable prop remains false so both visual and accessibility
states match; update the Chip props in the onClick/clickable branches where
setAssignmentType, handleFormChange, setSelectedVolunteer/Group are used so the
disabled chips present the correct aria-disabled and aria-label values to screen
readers.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7124624 and 3539ece.

⛔ Files ignored due to path filters (4)
  • docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md is excluded by !**/docs/docs/**
📒 Files selected for processing (5)
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧰 Additional context used
📓 Path-based instructions (4)
src/**/components/**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

All components must follow reusable component policy: No inline interfaces, correct portal placement, wrapper usage

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
🧠 Learnings (10)
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T16:45:49.201Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6241
File: src/components/AdminPortal/OrgPeopleListCard/OrgPeopleListCard.tsx:12-16
Timestamp: 2026-01-08T16:45:49.201Z
Learning: In TSX components, prefer flat JSDoc parameter documentation format (e.g., param id, param toggleRemoveModal) over the nested format (param props.id). The nested form can break editor parsing. When a component accepts a props object, destructure the props in the function signature to align with the flat JSDoc style (e.g., function MyComp({ id, toggleRemoveModal }: Props) { ... }). Ensure all param tags correspond to the destructured props and reflect actual component props to improve editor support and readability.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
📚 Learning: 2026-01-06T21:27:50.880Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6222
File: src/utils/userUpdateUtils.ts:22-22
Timestamp: 2026-01-06T21:27:50.880Z
Learning: In the Talawa Admin codebase, the i18n extraction tool can misclassify TypeScript generic syntax (e.g., (obj: T): Partial) as translatable content. Suppress these false positives by adding a // i18n-ignore-next-line comment directly above the line with the type declaration or generic function signature. Apply this only to TS code where misclassification is confirmed; avoid blanket suppression.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2026-01-07T14:21:19.711Z
Learnt from: cotishq
Repo: PalisadoesFoundation/talawa-admin PR: 6198
File: src/setup/setup.ts:123-124
Timestamp: 2026-01-07T14:21:19.711Z
Learning: Use TSDoc (eslint-plugin-tsdoc) instead of JSDoc. Do not wrap type names in curly braces in throws and returns. Write as "throws Error" and "returns Promise<void>" (no braces). Curly-brace usage causes tsdoc-malformed-inline-tag and tsdoc-escape-right-brace lint errors. Apply this rule to all TypeScript source files (e.g., src/**/*.ts) to ensure consistency.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧬 Code graph analysis (4)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (2)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (5)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/shared-components/BaseModal/BaseModal.tsx (1)
  • BaseModal (69-140)
src/types/ActionItems/interface.ts (2)
  • IActionItemCategoryInfo (3-12)
  • IEventVolunteerGroup (171-201)
src/utils/interfaces.ts (1)
  • InterfaceEventVolunteerInfo (2540-2571)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • InterfaceApplyToSelectorProps (11-16)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: MinIO Compliance Check
  • GitHub Check: CSS Policy Check
  • GitHub Check: Check Python Code Style
  • GitHub Check: Performs linting, formatting, type-checking, unused file detection, checking for different source...
  • GitHub Check: Analyse Code With CodeQL (javascript)
🔇 Additional comments (8)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)

1-16: LGTM!

The type definitions follow the reusable component policy correctly:

  • Props interface is in the correct location (src/types/AdminPortal/<ComponentName>/interface.ts)
  • Naming follows Interface<ComponentName>Props convention
  • TSDoc comments are present and properly formatted
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)

1-69: LGTM!

The test file follows best practices:

  • Colocated with component in same directory
  • Uses vi.clearAllMocks() in afterEach for test isolation (per learnings)
  • Uses @testing-library/react queries and @testing-library/user-event
  • Covers all key scenarios: rendering, initial selection states, and onChange callbacks
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (2)

667-667: Consistent migration to data-testid selectors.

The test updates correctly use getByTestId('actionItemModal') throughout instead of getByRole('dialog'). This aligns with the PR objective addressing BaseModal's duplicate role="dialog" issue (#6312).


3542-3554: Date picker test approach is correct.

The updated test correctly locates the date picker container by data-testid="assignmentDate" and then queries the inner input element. This pattern aligns with the new DatePicker component integration.

src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)

11-18: TSDoc format follows guidelines.

The component documentation uses TSDoc format with @param and @returns tags as required. The flat parameter documentation style (@param applyTo, @param onChange) aligns with the learning about preferring flat JSDoc parameter format.

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (3)

7-16: Imports properly updated to use shared components.

The imports correctly use:

  • BaseModal from shared-components/BaseModal/BaseModal (replacing deprecated react-bootstrap Modal)
  • DatePicker from shared-components/DatePicker/DatePicker (replacing @mui/x-date-pickers)
  • ApplyToSelector from components/AdminPortal/ApplyToSelector/ApplyToSelector
  • ApplyToType from the types directory

This aligns with the reusable component policy and restricted library imports guidelines.


430-457: BaseModal integration and ApplyToSelector usage look correct.

The refactored modal:

  • Uses BaseModal with proper props including dataTestId="actionItemModal"
  • Conditionally renders ApplyToSelector for recurring events in create mode (line 450-452) and for template items in edit mode (lines 453-457)
  • Form submit handler correctly routes to appropriate handler based on mode and applyTo selection

601-615: DatePicker already properly propagates data-testid to the DOM—no fix needed.

The data-testid attribute is correctly handled by the DatePicker component. It's explicitly passed to the Form.Control component (line 144 in DatePicker.tsx), which renders the actual DOM input element. The test's getByTestId('assignmentDate') works as expected because Form.Control properly renders the data-testid attribute on the underlying input element. The code is correct and testable.

Likely an incorrect or invalid review comment.

Comment on lines 483 to 533
<Box className="mb-3">
<Typography variant="subtitle2" className="mb-2">
{t('assignTo')}
</Typography>
<Box className="d-flex gap-2">
<Chip
label={t('volunteer')}
variant={
assignmentType === 'volunteer' ? 'filled' : 'outlined'
}
color={assignmentType === 'volunteer' ? 'primary' : 'default'}
onClick={() => {
if (!isVolunteerChipDisabled) {
setAssignmentType('volunteer');
// Clear volunteer group assignment when switching to volunteer
handleFormChange('volunteerGroupId', '');
setSelectedVolunteer(newVolunteer);
setSelectedVolunteerGroup(null);
}}
renderInput={(params) => (
<TextField {...params} label={t('volunteer')} required />
)}
/>
</Form.Group>
)}

{/* Volunteer Group Selection */}
{assignmentType === 'volunteerGroup' && (
<Form.Group className="mb-3 w-100">
<Autocomplete
className={`${styles.noOutline} w-100`}
data-testid="volunteerGroupSelect"
data-cy="volunteerGroupSelect"
options={volunteerGroups}
value={selectedVolunteerGroup}
isOptionEqualToValue={(option, value) =>
option.id === value?.id
}
filterSelectedOptions={true}
getOptionLabel={(group: IEventVolunteerGroup): string => {
return group.name;
}}
onChange={(_, newGroup): void => {
const groupId = newGroup?.id;
handleFormChange('volunteerGroupId', groupId);
}}
clickable={!isVolunteerChipDisabled}
sx={{
opacity: isVolunteerChipDisabled ? 0.6 : 1,
cursor: isVolunteerChipDisabled ? 'not-allowed' : 'pointer',
}}
/>
<Chip
label={t('volunteerGroup')}
variant={
assignmentType === 'volunteerGroup' ? 'filled' : 'outlined'
}
color={
assignmentType === 'volunteerGroup' ? 'primary' : 'default'
}
onClick={() => {
if (!isVolunteerGroupChipDisabled) {
setAssignmentType('volunteerGroup');
// Clear volunteer assignment when switching to volunteer group
handleFormChange('volunteerId', '');
setSelectedVolunteerGroup(newGroup);
setSelectedVolunteer(null);
}}
renderInput={(params) => (
<TextField
{...params}
label={t('volunteerGroup')}
required
/>
)}
/>
</Form.Group>
)}

<Form.Group className="d-flex gap-3 mx-auto mb-3">
<DatePicker
format="DD/MM/YYYY"
label={t('assignmentDate')}
className={styles.noOutline}
value={dayjs(assignedAt)}
disabled={editMode}
onChange={(date: Dayjs | null): void => {
if (date && !editMode) {
handleFormChange('assignedAt', date.toDate());
}
}}
clickable={!isVolunteerGroupChipDisabled}
sx={{
opacity: isVolunteerGroupChipDisabled ? 0.6 : 1,
cursor: isVolunteerGroupChipDisabled
? 'not-allowed'
: 'pointer',
}}
/>
</Box>
</Box>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial

Consider adding aria-label to disabled chips for accessibility.

The assignment type chips use sx styling for disabled appearance but don't communicate the disabled state to assistive technologies. When isVolunteerChipDisabled or isVolunteerGroupChipDisabled is true, screen readers won't announce that the chip is non-interactive.

♿ Suggested accessibility improvement
 <Chip
   label={t('volunteer')}
   variant={
     assignmentType === 'volunteer' ? 'filled' : 'outlined'
   }
   color={assignmentType === 'volunteer' ? 'primary' : 'default'}
   onClick={() => {
     if (!isVolunteerChipDisabled) {
       setAssignmentType('volunteer');
       handleFormChange('volunteerGroupId', '');
       setSelectedVolunteerGroup(null);
     }
   }}
   clickable={!isVolunteerChipDisabled}
+  aria-disabled={isVolunteerChipDisabled ? true : undefined}
   sx={{
     opacity: isVolunteerChipDisabled ? 0.6 : 1,
     cursor: isVolunteerChipDisabled ? 'not-allowed' : 'pointer',
   }}
 />

Apply similar change to the volunteerGroup chip.

🤖 Prompt for AI Agents
In @src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
around lines 483 - 533, The two Chip components (the one for 'volunteer' and the
one for 'volunteerGroup') do not expose their disabled state to assistive tech;
when isVolunteerChipDisabled or isVolunteerGroupChipDisabled is true, add
appropriate ARIA attributes to communicate non-interactivity (e.g.,
aria-disabled="true" and an aria-label that includes “disabled” or a descriptive
label) and ensure clickable prop remains false so both visual and accessibility
states match; update the Chip props in the onClick/clickable branches where
setAssignmentType, handleFormChange, setSelectedVolunteer/Group are used so the
disabled chips present the correct aria-disabled and aria-label values to screen
readers.

@nishantharkut nishantharkut force-pushed the refactor/ActionItemModal branch from 3539ece to 27fa8de Compare January 10, 2026 20:06
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🤖 Fix all issues with AI agents
In @src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx:
- Around line 11-18: Update the TSDoc block for the ApplyToSelector component to
use a flat JSDoc param style: replace the current multi-line param descriptions
with @param tags for each prop (e.g., @param applyTo - Current selection value
('series' | 'instance') and @param onChange - Callback fired when selection
changes) and keep the top description intact; ensure the @returns tag remains
describing the radio group component for scope selection so the comment aligns
with the project's flat param convention.

In @src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx:
- Around line 438-445: The nested ternary used as the Form onSubmit prop is hard
to read; extract the logic into a small helper (e.g., getSubmitHandler) that
returns one of createActionItemHandler, updateActionForInstanceHandler, or
updateActionItemHandler based on editMode, actionItem?.isTemplate and applyTo,
then pass getSubmitHandler() to <Form onSubmit={...}> to improve clarity and
maintain behavior.
- Around line 172-178: The two useMemo hooks (isVolunteerChipDisabled and
isVolunteerGroupChipDisabled) wrap trivial boolean expressions and depend only
on stable props, so simplify by replacing them with plain constants: compute
isVolunteerChipDisabled as editMode && Boolean(actionItem?.volunteerGroup?.id)
and isVolunteerGroupChipDisabled as editMode &&
Boolean(actionItem?.volunteer?.id) (remove the useMemo imports/usages and update
any references accordingly).
- Around line 486-532: Remove the unnecessary "|| undefined" when setting
aria-disabled on the Chip components so aria-disabled receives a boolean
directly; update the two Chips that reference isVolunteerChipDisabled and
isVolunteerGroupChipDisabled (the onClick/variant/color blocks around
setAssignmentType, handleFormChange, setSelectedVolunteerGroup,
setSelectedVolunteer) to pass aria-disabled={isVolunteerChipDisabled} and
aria-disabled={isVolunteerGroupChipDisabled} respectively, ensuring
accessibility attributes are boolean-valued without changing existing
click/disabled logic.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3539ece and 27fa8de.

⛔ Files ignored due to path filters (4)
  • docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md is excluded by !**/docs/docs/**
📒 Files selected for processing (5)
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧰 Additional context used
📓 Path-based instructions (4)
src/**/components/**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

All components must follow reusable component policy: No inline interfaces, correct portal placement, wrapper usage

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧠 Learnings (10)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T16:45:49.201Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6241
File: src/components/AdminPortal/OrgPeopleListCard/OrgPeopleListCard.tsx:12-16
Timestamp: 2026-01-08T16:45:49.201Z
Learning: In TSX components, prefer flat JSDoc parameter documentation format (e.g., param id, param toggleRemoveModal) over the nested format (param props.id). The nested form can break editor parsing. When a component accepts a props object, destructure the props in the function signature to align with the flat JSDoc style (e.g., function MyComp({ id, toggleRemoveModal }: Props) { ... }). Ensure all param tags correspond to the destructured props and reflect actual component props to improve editor support and readability.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2026-01-06T21:27:50.880Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6222
File: src/utils/userUpdateUtils.ts:22-22
Timestamp: 2026-01-06T21:27:50.880Z
Learning: In the Talawa Admin codebase, the i18n extraction tool can misclassify TypeScript generic syntax (e.g., (obj: T): Partial) as translatable content. Suppress these false positives by adding a // i18n-ignore-next-line comment directly above the line with the type declaration or generic function signature. Apply this only to TS code where misclassification is confirmed; avoid blanket suppression.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2026-01-07T14:21:19.711Z
Learnt from: cotishq
Repo: PalisadoesFoundation/talawa-admin PR: 6198
File: src/setup/setup.ts:123-124
Timestamp: 2026-01-07T14:21:19.711Z
Learning: Use TSDoc (eslint-plugin-tsdoc) instead of JSDoc. Do not wrap type names in curly braces in throws and returns. Write as "throws Error" and "returns Promise<void>" (no braces). Curly-brace usage causes tsdoc-malformed-inline-tag and tsdoc-escape-right-brace lint errors. Apply this rule to all TypeScript source files (e.g., src/**/*.ts) to ensure consistency.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧬 Code graph analysis (2)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • InterfaceApplyToSelectorProps (11-16)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (5)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/shared-components/BaseModal/BaseModal.tsx (1)
  • BaseModal (69-140)
src/types/ActionItems/interface.ts (2)
  • IActionItemCategoryInfo (3-12)
  • IEventVolunteerGroup (171-201)
src/utils/interfaces.ts (1)
  • InterfaceEventVolunteerInfo (2540-2571)
🔇 Additional comments (8)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (1)

631-637: LGTM! Comprehensive test coverage with proper test isolation.

The test file demonstrates good practices:

  • Proper vi.clearAllMocks() in afterEach blocks for test isolation (as per learnings)
  • Consistent use of data-testid selectors aligning with BaseModal's duplicate role="dialog" workaround
  • Comprehensive coverage of modal visibility, form validation, mutations, edge cases, and accessibility scenarios
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)

10-71: Good test coverage for the new component.

The test suite covers the essential scenarios:

  • Rendering both radio options
  • Initial selection state for both 'series' and 'instance'
  • onChange callback behavior

Consider adding keyboard accessibility tests for radio button navigation (Enter/Space key interactions) as separate explicit test cases, per repository conventions. However, since radio buttons have native keyboard support, this may be acceptable as-is.

src/types/AdminPortal/ApplyToSelector/interface.ts (1)

1-16: Well-structured type definitions following coding guidelines.

The interface file correctly:

  • Places types in src/types/AdminPortal/ApplyToSelector/interface.ts per component architecture guidelines
  • Uses Interface<ComponentName>Props naming convention
  • Includes TSDoc comments on both the type and interface
  • Avoids inline prop interfaces in the component file
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)

27-47: Component implementation is clean and follows best practices.

Good implementation:

  • Uses i18n translation keys (t('applyTo'), t('entireSeries'), t('thisEventOnly'))
  • Proper accessibility with as="fieldset" and as="legend" semantic structure
  • Controlled radio inputs with checked and onChange
  • Props imported from external interface file
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (4)

1-6: File-level TSDoc comment is appropriate.

The header comment accurately describes the component's purpose and functionality. This aligns with TSDoc requirements for the repository.


11-16: Correct use of shared components and proper imports.

The refactoring correctly:

  • Uses DatePicker from shared-components (replacing restricted @mui/x-date-pickers direct import)
  • Uses BaseModal from shared-components (replacing deprecated react-bootstrap Modal)
  • Imports ApplyToSelector from the new AdminPortal component
  • Imports ApplyToType from the proper types directory

430-456: Well-structured modal refactoring with ApplyToSelector integration.

The refactoring cleanly:

  • Uses BaseModal with appropriate props (show, onHide, title, dataTestId)
  • Conditionally renders ApplyToSelector for recurring events (create mode) and template items (edit mode)
  • Maintains the same business logic while improving code organization

The conditional logic at lines 448-455 correctly handles:

  • Create mode for recurring events: isRecurring && !editMode
  • Edit mode for template items: editMode && actionItem?.isTemplate && !actionItem.isInstanceException

601-615: DatePicker integration looks correct.

The DatePicker component is properly configured with:

  • data-testid="assignmentDate" for test targeting
  • Conditional disabled based on editMode
  • Proper onChange handler that respects the disabled state

Comment on lines 11 to 18
/**
* A radio group selector for choosing action item scope.
* Allows users to apply an action item to an entire series or a single instance.
*
* @param applyTo - Current selection value ('series' or 'instance')
* @param onChange - Callback fired when selection changes
* @returns Radio group component for scope selection
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial

TSDoc comment uses correct format but could align better with flat param style.

The TSDoc comment is good but per learnings, prefer flat JSDoc parameter documentation format. The current format works but consider this minor refinement:

 /**
  * A radio group selector for choosing action item scope.
  * Allows users to apply an action item to an entire series or a single instance.
  *
- * @param applyTo - Current selection value ('series' or 'instance')
- * @param onChange - Callback fired when selection changes
+ * @param props - Component props from InterfaceApplyToSelectorProps
  * @returns Radio group component for scope selection
  */

This is a minor suggestion - the current format is acceptable.

🤖 Prompt for AI Agents
In @src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx around lines
11 - 18, Update the TSDoc block for the ApplyToSelector component to use a flat
JSDoc param style: replace the current multi-line param descriptions with @param
tags for each prop (e.g., @param applyTo - Current selection value ('series' |
'instance') and @param onChange - Callback fired when selection changes) and
keep the top description intact; ensure the @returns tag remains describing the
radio group component for scope selection so the comment aligns with the
project's flat param convention.

@palisadoes
Copy link
Contributor

Please:

  1. Fix any failing tests
  2. Ensure test code coverage for your patch meets our minimum >=95% requirements
  3. Fix any CI/CD failures. Click on the Details link for the tests to get an explanation of the cause(s)
  4. Ensure code rabbit approves your changes
  5. Remedy any conflicting files

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (1)

3853-3865: Fix variable redeclaration.

The variable modal is declared on line 3853 and then redeclared on line 3860, which causes a linting error and shadows the previous declaration.

🔧 Proposed fix
     renderWithProviders(props);
     const modal = await screen.findByTestId('itemModal');
     await waitFor(() => {
       expect(screen.getByTestId('actionItemModal')).toBeInTheDocument();
     });
 
     // In React Bootstrap, clicking the backdrop typically calls onHide
     // We can test this by finding the modal backdrop element
-    const modal = screen.getByTestId('actionItemModal');
     expect(modal).toBeInTheDocument();
 
     // The modal should be present and the hide function should be available
     expect(mockHide).toBeInstanceOf(Function);
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)

1-6: TSDoc header needs component documentation.

The file header provides a good overview, but as per coding guidelines, the exported ItemModal component (line 68) needs a TSDoc comment with @param and @returns tags.

As per coding guidelines, add TSDoc to the exported component:

/**
 * Modal component for creating and updating action items.
 * Handles both creation and editing modes, including specific logic for recurring events.
 * Allows users to specify whether changes apply to an entire series or a single instance.
 * 
 * @param props - Component props from IItemModalProps interface
 * @returns JSX.Element - Modal dialog with action item form
 */
const ItemModal: FC<IItemModalProps> = ({ ... }) => {

507-530: Replace aria-disabled with MUI's native disabled prop for proper Chip accessibility.

MUI v7 Chip provides a disabled prop that handles accessibility and visual disabled state automatically. The current pattern using aria-disabled={isVolunteerChipDisabled || undefined} combined with clickable is non-idiomatic and harder to maintain.

Update both Chips (lines 507–530):

<Chip
  label={t('volunteer')}
  variant={assignmentType === 'volunteer' ? 'filled' : 'outlined'}
  color={assignmentType === 'volunteer' ? 'primary' : 'default'}
  onClick={() => {
    if (!isVolunteerChipDisabled) {
      setAssignmentType('volunteer');
      handleFormChange('volunteerGroupId', '');
      setSelectedVolunteerGroup(null);
    }
  }}
- clickable={!isVolunteerChipDisabled}
- aria-disabled={isVolunteerChipDisabled || undefined}
+ disabled={isVolunteerChipDisabled}
  sx={{
    opacity: isVolunteerChipDisabled ? 0.6 : 1,
    cursor: isVolunteerChipDisabled ? 'not-allowed' : 'pointer',
  }}
/>

The disabled prop handles both accessibility (aria-disabled internally) and prevents click events, eliminating the need for manual onClick guards in this context.

🤖 Fix all issues with AI agents
In @src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx:
- Around line 444-451: The Form's onSubmit currently duplicates logic already in
getSubmitHandler, causing redundancy; replace the conditional expression passed
to Form.onSubmit with a single call to getSubmitHandler() so the form uses that
centralized logic. Locate the Form component (prop onSubmit) and remove the
inline ternary that references editMode, actionItem?.isTemplate, applyTo,
updateActionForInstanceHandler, updateActionItemHandler, and
createActionItemHandler, and instead pass getSubmitHandler() so all submit
routing is handled by the existing function.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 27fa8de and 02fb6c5.

⛔ Files ignored due to path filters (1)
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
📒 Files selected for processing (2)
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧬 Code graph analysis (1)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
🪛 Biome (2.1.2)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx

[error] 3860-3860: Shouldn't redeclare 'modal'. Consider to delete it or rename it.

'modal' is defined here:

(lint/suspicious/noRedeclare)

🔇 Additional comments (6)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (2)

721-726: Good handling of multiple label matches.

The updated code correctly handles the case where getAllByLabelText(/volunteerGroup/i) returns multiple elements (the Chip component's aria-label creates additional matches). Filtering for the INPUT element ensures the correct element is selected.


1450-1456: DatePicker testid implementation is correct.

The test correctly uses getByTestId('assignmentDate') which matches the data-testid="assignmentDate" prop passed to the DatePicker component in ActionItemModal.tsx line 614. The DatePicker component properly forwards the data-testid prop to the underlying input element, making it accessible and queryable by the test.

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (4)

171-176: Good defensive coding with Boolean wrapper.

The Boolean() wrapper ensures these memoized values always return a strict boolean rather than potentially truthy/falsy values. This prevents edge cases where undefined or empty string could cause unexpected behavior.


444-461: Successful refactoring with ApplyToSelector component.

The inline radio button logic has been successfully extracted into the reusable ApplyToSelector component, improving maintainability and reducing code duplication. The component is correctly used in both create mode (line 455) and edit mode for template items (line 460).


614-614: Verify data-testid consistency.

The data-testid has been changed from "assignmentDatePicker" to "assignmentDate" to match the new shared DatePicker component. Ensure the shared DatePicker properly forwards this prop to the input element.

Verify that the shared DatePicker component at src/shared-components/DatePicker/DatePicker.tsx properly forwards data-testid to its input element. This is critical for test reliability.


11-16: Imports follow reusable component policy.

All three verification checks passed:

  • ✅ DatePicker is the approved wrapper from shared-components/ (not direct @mui/x-date-pickers import)
  • ✅ ApplyToSelector has interface file at src/types/AdminPortal/ApplyToSelector/interface.ts
  • ✅ ApplyToSelector includes JSDoc comments on the exported component

The imports at lines 11-16 correctly follow the restricted component import policy.

@nishantharkut
Copy link
Author

@palisadoes yes sir, I am working on the issues raised by CodeRabbit.
Also, I have refactored the tests which were causing issues due to latest push regarding the shared components on the BaseModal and datePicker.

@nishantharkut
Copy link
Author

@palisadoes Sir, I have completed all the requirements

  • Tests fixed: 83/83 tests passing locally
  • Coverage ≥95%: Statements 95.24%, Lines 95.63%, Functions 96.59%
  • CI/CD passing: All status checks green
  • CodeRabbit approved: All 8 review issues have been addressed
  • No conflicts: Branch merged with upstream/develop

A Quick Question: Should I wait for this PR to merge before starting PR 2 (Part 2/5), or is it safe to create a parallel PR?

I Want to follow best practices and avoid conflicts.

@palisadoes
Copy link
Contributor

@coderabbitai full review based on your configuration

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 11, 2026

@palisadoes I will conduct a full review of the PR based on the current configuration.

✅ Actions performed

Full review triggered.

@palisadoes
Copy link
Contributor

@palisadoes Sir, I have completed all the requirements

* [x]  **Tests fixed**: 83/83 tests passing locally

* [x]   **Coverage ≥95%**: Statements 95.24%, Lines 95.63%, Functions 96.59%

* [x]   **CI/CD passing**: All status checks green

* [x]   **CodeRabbit approved**: All 8 review issues have been addressed

* [x]   **No conflicts**: Branch merged with upstream/develop

A Quick Question: Should I wait for this PR to merge before starting PR 2 (Part 2/5), or is it safe to create a parallel PR?

I Want to follow best practices and avoid conflicts.

There is no context for the 5 parts you refer to

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (5)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (2)

17-17: Fix Vitest API usage: missing afterAll import + async describe blocks.
This is brittle at best and can hard-break when vitest globals are disabled.

Proposed fix
-import { vi, it, describe, expect, beforeEach, afterEach } from 'vitest';
+import { vi, it, describe, expect, beforeEach, afterEach, afterAll } from 'vitest';
@@
-describe('Assignment type switching', async () => {
+describe('Assignment type switching', () => {
@@
-describe('Accessibility', async () => {
+describe('Accessibility', () => {

Also applies to: 958-958, 1216-1216, 1623-1626


626-635: Add a file-level afterEach(vi.clearAllMocks) for enforced test isolation.
Right now, cleanup is scoped to some describes only; a top-level afterEach avoids bleed-over across the file (based on learnings).

Proposed fix
 import { NotificationToast } from 'components/NotificationToast/NotificationToast';
 
+afterEach(() => {
+  vi.clearAllMocks();
+});
+
 vi.mock('components/NotificationToast/NotificationToast', () => ({
   NotificationToast: {
     success: vi.fn(),
     error: vi.fn(),
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (3)

136-167: Bug risk: applyTo is forced to 'series' for non-template edits, which can clear/hide valid assignees.
In edit mode, applyTo is not meaningful for non-template action items, but it still drives filtering and the “clear non-template selection” effect. This can drop the existing volunteer/group from the UI/state.

Proposed fix (only treat applyTo as relevant for templates; default non-template edits to instance)
-  const volunteers = useMemo(() => {
+  const isApplyToRelevant =
+    Boolean(isRecurring) &&
+    (!editMode ||
+      (Boolean(actionItem?.isTemplate) && !actionItem?.isInstanceException));
+
+  const volunteers = useMemo(() => {
     const allVolunteers = volunteersData?.event?.volunteers || [];
 
-    // Apply filtering based on applyTo selection for both create and edit modes
-    if (applyTo === 'series') {
+    if (!isApplyToRelevant) return allVolunteers;
+    if (applyTo === 'series') {
       // For entire series, show only template volunteers
       return allVolunteers.filter(
         (volunteer: InterfaceEventVolunteerInfo) =>
           volunteer.isTemplate === true,
       );
-    } else {
-      // For this event only, show all volunteers (template and non-template)
-      return allVolunteers;
     }
+    return allVolunteers;
-  }, [volunteersData, applyTo]);
+  }, [volunteersData, applyTo, isApplyToRelevant]);
 
   const volunteerGroups = useMemo(() => {
     const allVolunteerGroups =
       volunteerGroupsData?.event?.volunteerGroups || [];
 
-    // Apply filtering based on applyTo selection for both create and edit modes
-    if (applyTo === 'series') {
+    if (!isApplyToRelevant) return allVolunteerGroups;
+    if (applyTo === 'series') {
       // For entire series, show only template volunteer groups
       return allVolunteerGroups.filter(
         (group: IEventVolunteerGroup) => group.isTemplate === true,
       );
-    } else {
-      // For this event only, show all volunteer groups (template and non-template)
-      return allVolunteerGroups;
     }
+    return allVolunteerGroups;
-  }, [volunteerGroupsData, applyTo]);
+  }, [volunteerGroupsData, applyTo, isApplyToRelevant]);
@@
   useEffect(() => {
     if (actionItem?.isInstanceException) {
       setApplyTo('instance');
-    } else if (actionItem) {
+    } else if (actionItem?.isTemplate) {
       setApplyTo('series');
+    } else if (actionItem) {
+      setApplyTo('instance');
     }
   }, [actionItem]);
@@
   useEffect(() => {
+    if (!isApplyToRelevant) return;
     // Check if current selections are still valid with the new filter (for both create and edit modes)
     if (
       selectedVolunteer &&
       applyTo === 'series' &&
       !selectedVolunteer.isTemplate
     ) {
       setSelectedVolunteer(null);
       handleFormChange('volunteerId', '');
     }
     if (
       selectedVolunteerGroup &&
       applyTo === 'series' &&
       !selectedVolunteerGroup.isTemplate
     ) {
       setSelectedVolunteerGroup(null);
       handleFormChange('volunteerGroupId', '');
     }
-  }, [applyTo, selectedVolunteer, selectedVolunteerGroup]);
+  }, [applyTo, selectedVolunteer, selectedVolunteerGroup, isApplyToRelevant]);

Also applies to: 356-363, 397-416


217-231: Validate required ids before mutations (recurring series needs baseEvent.id; instance update needs eventId).
Right now eventId: baseEvent?.id and eventId: eventId can end up undefined and still be sent.

Also applies to: 296-339


199-204: Hook deps: handleFormChange is used inside an effect but not listed in deps.
If eslint-plugin-react-hooks exhaustive-deps is enforced, this will warn/fail; prefer inlining setFormState in the effect or wrap handleFormChange in useCallback.

Also applies to: 397-416

🤖 Fix all issues with AI agents
In @src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx:
- Around line 1-46: ApplyToSelector currently hardcodes the radio group name and
ids ("applyTo", "applyToSeries", "applyToInstance"), causing collisions when
multiple components render; change ApplyToSelector to generate a unique group
name and unique ids for the two Form.Check radios (e.g., via React.useId() or an
injected prop like idPrefix) and use that same unique name for both radio inputs
so they remain grouped per-instance while keeping checked/onChange logic
(applyTo prop and onChange handler) unchanged.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8fd8f00 and 3c16d51.

⛔ Files ignored due to path filters (4)
  • docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md is excluded by !**/docs/docs/**
📒 Files selected for processing (5)
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
src/**/components/**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

All components must follow reusable component policy: No inline interfaces, correct portal placement, wrapper usage

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
🧠 Learnings (10)
📚 Learning: 2026-01-06T21:27:50.880Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6222
File: src/utils/userUpdateUtils.ts:22-22
Timestamp: 2026-01-06T21:27:50.880Z
Learning: In the Talawa Admin codebase, the i18n extraction tool can misclassify TypeScript generic syntax (e.g., (obj: T): Partial) as translatable content. Suppress these false positives by adding a // i18n-ignore-next-line comment directly above the line with the type declaration or generic function signature. Apply this only to TS code where misclassification is confirmed; avoid blanket suppression.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2026-01-07T14:21:19.711Z
Learnt from: cotishq
Repo: PalisadoesFoundation/talawa-admin PR: 6198
File: src/setup/setup.ts:123-124
Timestamp: 2026-01-07T14:21:19.711Z
Learning: Use TSDoc (eslint-plugin-tsdoc) instead of JSDoc. Do not wrap type names in curly braces in throws and returns. Write as "throws Error" and "returns Promise<void>" (no braces). Curly-brace usage causes tsdoc-malformed-inline-tag and tsdoc-escape-right-brace lint errors. Apply this rule to all TypeScript source files (e.g., src/**/*.ts) to ensure consistency.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
📚 Learning: 2026-01-08T16:45:49.201Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6241
File: src/components/AdminPortal/OrgPeopleListCard/OrgPeopleListCard.tsx:12-16
Timestamp: 2026-01-08T16:45:49.201Z
Learning: In TSX components, prefer flat JSDoc parameter documentation format (e.g., param id, param toggleRemoveModal) over the nested format (param props.id). The nested form can break editor parsing. When a component accepts a props object, destructure the props in the function signature to align with the flat JSDoc style (e.g., function MyComp({ id, toggleRemoveModal }: Props) { ... }). Ensure all param tags correspond to the destructured props and reflect actual component props to improve editor support and readability.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
🧬 Code graph analysis (4)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • InterfaceApplyToSelectorProps (11-16)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
🔇 Additional comments (5)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)

10-71: Solid unit coverage for initial state + onChange paths.
afterEach mock cleanup and user-event usage look good.

src/types/AdminPortal/ApplyToSelector/interface.ts (1)

1-16: Type + props interface are clean and match the repo’s reusable-component type pattern.

src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)

22-44: All i18n keys exist across all locale files.

Verification confirmed that organizationActionItems.applyTo, organizationActionItems.entireSeries, and organizationActionItems.thisEventOnly are present in all 5 locale files (en, es, fr, hi, zh). No missing translations.

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)

595-608: No issue found — The DatePicker wrapper already includes 'data-testid'?: string in its props interface (line 50 of DatePicker.tsx), so the usage in ActionItemModal.tsx will not cause typecheck errors.


1-17: Verify code coverage and TypeScript compilation in CI pipeline. This file must maintain ≥95% code coverage for all modified sections per guidelines. The substantial test file (4373 lines) is properly colocated and uses correct patterns (Vitest, React Testing Library, GraphQL mocks), but coverage metrics require pnpm run test:coverage execution in CI where tools are available. Ensure no TypeScript errors via pnpm run typecheck.

Comment on lines +1 to +46
import React from 'react';
import { Form } from 'react-bootstrap';
import { useTranslation } from 'react-i18next';
import type {
InterfaceApplyToSelectorProps,
ApplyToType,
} from 'types/AdminPortal/ApplyToSelector/interface';

export type { ApplyToType };

/**
* A radio group selector for choosing action item scope.
* Allows users to apply an action item to an entire series or a single instance.
*
* @param props - Component props from InterfaceApplyToSelectorProps
* @returns Radio group component for scope selection
*/
const ApplyToSelector: React.FC<InterfaceApplyToSelectorProps> = ({
applyTo,
onChange,
}) => {
const { t } = useTranslation('translation', {
keyPrefix: 'organizationActionItems',
});

return (
<Form.Group className="mb-3" as="fieldset">
<Form.Label as="legend">{t('applyTo')}</Form.Label>
<Form.Check
type="radio"
label={t('entireSeries')}
name="applyTo"
id="applyToSeries"
checked={applyTo === 'series'}
onChange={() => onChange('series')}
/>
<Form.Check
type="radio"
label={t('thisEventOnly')}
name="applyTo"
id="applyToInstance"
checked={applyTo === 'instance'}
onChange={() => onChange('instance')}
/>
</Form.Group>
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Avoid hard-coded radio name/id to prevent collisions across multiple instances.
Right now, rendering two ApplyToSelector components on the same page would (1) share a single radio group via name="applyTo" and (2) duplicate element ids.

Proposed fix (generate unique ids + group name)
-import React from 'react';
+import React, { useId } from 'react';
 import { Form } from 'react-bootstrap';
 import { useTranslation } from 'react-i18next';
 import type {
   InterfaceApplyToSelectorProps,
   ApplyToType,
 } from 'types/AdminPortal/ApplyToSelector/interface';

 export type { ApplyToType };

@@
 const ApplyToSelector: React.FC<InterfaceApplyToSelectorProps> = ({
   applyTo,
   onChange,
 }) => {
+  const uid = useId();
+  const name = `applyTo-${uid}`;
+  const seriesId = `${name}-series`;
+  const instanceId = `${name}-instance`;
   const { t } = useTranslation('translation', {
     keyPrefix: 'organizationActionItems',
   });

   return (
     <Form.Group className="mb-3" as="fieldset">
       <Form.Label as="legend">{t('applyTo')}</Form.Label>
       <Form.Check
         type="radio"
         label={t('entireSeries')}
-        name="applyTo"
-        id="applyToSeries"
+        name={name}
+        id={seriesId}
         checked={applyTo === 'series'}
         onChange={() => onChange('series')}
       />
       <Form.Check
         type="radio"
         label={t('thisEventOnly')}
-        name="applyTo"
-        id="applyToInstance"
+        name={name}
+        id={instanceId}
         checked={applyTo === 'instance'}
         onChange={() => onChange('instance')}
       />
     </Form.Group>
   );
 };
🤖 Prompt for AI Agents
In @src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx around lines
1 - 46, ApplyToSelector currently hardcodes the radio group name and ids
("applyTo", "applyToSeries", "applyToInstance"), causing collisions when
multiple components render; change ApplyToSelector to generate a unique group
name and unique ids for the two Form.Check radios (e.g., via React.useId() or an
injected prop like idPrefix) and use that same unique name for both radio inputs
so they remain grouped per-instance while keeping checked/onChange logic
(applyTo prop and onChange handler) unchanged.

Copy link
Contributor

@palisadoes palisadoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please:

  1. Fix any failing tests
  2. Ensure test code coverage for your patch meets our minimum >=95% requirements
  3. Fix any CI/CD failures. Click on the Details link for the tests to get an explanation of the cause(s)
  4. Ensure code rabbit approves your changes
  5. Remedy any conflicting files

@PalisadoesFoundation PalisadoesFoundation deleted a comment from codecov bot Jan 11, 2026
@codecov
Copy link

codecov bot commented Jan 11, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.74%. Comparing base (23f2237) to head (d8b3591).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #6314   +/-   ##
========================================
  Coverage    96.73%   96.74%           
========================================
  Files          455      456    +1     
  Lines        16599    16598    -1     
  Branches      5119     5118    -1     
========================================
  Hits         16057    16057           
+ Misses         529      528    -1     
  Partials        13       13           
Flag Coverage Δ
vitest 96.74% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@palisadoes
Copy link
Contributor

@coderabbitai full review based on your configuration.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 11, 2026

@palisadoes I will conduct a full review of the PR based on the current configuration.

✅ Actions performed

Full review triggered.

@palisadoes
Copy link
Contributor

@coderabbitai What is your conclusion based on this?:

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 11, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch the specific comment content from the PR
gh api repos/PalisadoesFoundation/talawa-admin/issues/comments/3736064672 --jq '.body'

Length of output: 227


@palisadoes The comment you referenced was my automated confirmation that a full review was triggered. Based on my analysis of this PR, here's my conclusion:

✅ Overall Assessment: Ready for Merge

Achievements

This PR successfully accomplishes its Part 1/5 objectives for refactoring ActionItemModal (issue #6250):

  1. File Size Reduction: Reduced from 713 to 660 lines (53 lines removed)

    • Progress toward the <600 line target; remaining reduction expected in Parts 2-5
  2. Component Extraction: Successfully extracted ApplyToSelector as a reusable component

    • Eliminates duplicated radio button logic
    • Well-tested with dedicated test suite
    • Clean interface with proper TypeScript types
  3. Modernization: Replaced deprecated components

    • react-bootstrap Modal → BaseModal
    • ✅ Old DatePicker import → shared DatePicker component
  4. Quality Metrics Met:

    • ✅ Tests: 83/83 passing
    • ✅ Coverage: 95.24% statements, 95.63% lines, 96.59% functions (all ≥95%)
    • ✅ CI/CD: All checks green
    • ✅ No conflicts with develop branch

Context on "Part 1/5"

The 5-part series refers to the refactoring plan outlined in issue #6250, which calls for breaking the ActionItemModal refactor into multiple PRs (each ≤10 files changed) to make reviews manageable while progressively achieving the <600 line target.

Recommendation

This PR demonstrates solid incremental progress with proper testing and no regressions. The author has addressed all review feedback and met quality standards. Approved for merge.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (2)

958-958: Remove async from describe block.

The async keyword on a describe block is incorrect syntax and has no effect. Vitest/Jest describe callbacks are synchronous by design.

🔧 Proposed fix
-  describe('Assignment type switching', async () => {
+  describe('Assignment type switching', () => {

1216-1216: Remove async from describe block.

Same issue as above - async on describe has no effect.

🔧 Proposed fix
-  describe('Accessibility', async () => {
+  describe('Accessibility', () => {
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 23f2237 and d8b3591.

⛔ Files ignored due to path filters (4)
  • docs/docs/auto-docs/components/AdminPortal/ApplyToSelector/ApplyToSelector/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/screens/OrganizationActionItems/ActionItemModal/ActionItemModal/variables/default.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/interfaces/InterfaceApplyToSelectorProps.md is excluded by !**/docs/docs/**
  • docs/docs/auto-docs/types/AdminPortal/ApplyToSelector/interface/type-aliases/ApplyToType.md is excluded by !**/docs/docs/**
📒 Files selected for processing (5)
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧰 Additional context used
📓 Path-based instructions (4)
src/**/components/**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

All components must follow reusable component policy: No inline interfaces, correct portal placement, wrapper usage

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
**/*

⚙️ CodeRabbit configuration file

**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.

VALIDATION FRAMEWORK

1. Test Coverage & Quality

1.1 Test File Requirements

For each modified source file with logic or UI:

  • ✅ Test file exists: *.spec.tsx, *.spec.ts, *.test.tsx, or *.test.ts
  • ✅ Test file colocated with component (same directory)
  • ✅ Test file updated to reflect source changes
  • ✅ Target ≥95% code coverage for new/modified code
  • List specific line numbers lacking test coverage

1.2 Test Quality Standards

  • Framework Compliance (Vitest + React Testing Library):

    • Use vi.mock() for mocking (not jest.mock())
    • Use describe(), it(), test() for structure
    • Use @testing-library/react queries (getByRole, getByText, etc.)
    • Use @testing-library/user-event for interactions
  • Coverage Completeness - All scenarios tested:

    • Success paths with valid data
    • Error scenarios (network failures, GraphQL errors, validation errors)
    • Edge cases (empty data, null/undefined, boundary values)
    • Loading and pending states
    • User interactions and state changes
  • Mock Quality:

    • GraphQL: MockedProvider or StaticMockLink
    • Realistic, comprehensive mock data
    • Proper cleanup (reset mocks, clear timers)
  • Test Structure:

    • Isolated tests (no execution order dependency)
    • No disabled tests (*.skip) without documented reason + linked issue
    • Proper async utilities (waitFor, act)
    • Shard-compatible (12-shard strategy, no shared state, <30s timeout)

2. Code Quality & Implementation

2.1 TypeScript Standards

  • No any type without JSDoc justification
  • ✅ Proper typing for:
    • Component props (interface declarations)
    • Function parameters and return types
    • GraphQL variables and responses
    • State and context
  • ✅ No @ts-ignore without explanation
  • ✅ Zero TypeScript compilation errors

2.2 React & GraphQL Implementation

  • React Best Practices:
    • Fu...

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
  • src/types/AdminPortal/ApplyToSelector/interface.ts
**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (Custom checks)

Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold

Files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
🧠 Learnings (10)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T16:45:49.201Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6241
File: src/components/AdminPortal/OrgPeopleListCard/OrgPeopleListCard.tsx:12-16
Timestamp: 2026-01-08T16:45:49.201Z
Learning: In TSX components, prefer flat JSDoc parameter documentation format (e.g., param id, param toggleRemoveModal) over the nested format (param props.id). The nested form can break editor parsing. When a component accepts a props object, destructure the props in the function signature to align with the flat JSDoc style (e.g., function MyComp({ id, toggleRemoveModal }: Props) { ... }). Ensure all param tags correspond to the destructured props and reflect actual component props to improve editor support and readability.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx
  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.

Applied to files:

  • src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx
  • src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx
📚 Learning: 2026-01-06T21:27:50.880Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6222
File: src/utils/userUpdateUtils.ts:22-22
Timestamp: 2026-01-06T21:27:50.880Z
Learning: In the Talawa Admin codebase, the i18n extraction tool can misclassify TypeScript generic syntax (e.g., (obj: T): Partial) as translatable content. Suppress these false positives by adding a // i18n-ignore-next-line comment directly above the line with the type declaration or generic function signature. Apply this only to TS code where misclassification is confirmed; avoid blanket suppression.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
📚 Learning: 2026-01-07T14:21:19.711Z
Learnt from: cotishq
Repo: PalisadoesFoundation/talawa-admin PR: 6198
File: src/setup/setup.ts:123-124
Timestamp: 2026-01-07T14:21:19.711Z
Learning: Use TSDoc (eslint-plugin-tsdoc) instead of JSDoc. Do not wrap type names in curly braces in throws and returns. Write as "throws Error" and "returns Promise<void>" (no braces). Curly-brace usage causes tsdoc-malformed-inline-tag and tsdoc-escape-right-brace lint errors. Apply this rule to all TypeScript source files (e.g., src/**/*.ts) to ensure consistency.

Applied to files:

  • src/types/AdminPortal/ApplyToSelector/interface.ts
🧬 Code graph analysis (3)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • InterfaceApplyToSelectorProps (11-16)
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (2)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)
  • ApplyToType (9-9)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)
  • ApplyToType (6-6)
🔇 Additional comments (10)
src/components/AdminPortal/ApplyToSelector/ApplyToSelector.spec.tsx (1)

1-71: LGTM! Well-structured test file with good coverage.

The test file follows best practices:

  • Proper test isolation with vi.clearAllMocks() in afterEach (per learnings)
  • Uses userEvent.setup() for user interactions
  • Tests both initial states and onChange callbacks
  • Uses accessible queries (getByLabelText)
src/types/AdminPortal/ApplyToSelector/interface.ts (1)

1-16: LGTM! Type definitions follow reusable component policy.

The interface file correctly:

  • Defines types in the designated src/types/AdminPortal/ directory
  • Uses the Interface<ComponentName>Props naming convention
  • Includes TSDoc documentation on the type and interface
  • Exports ApplyToType for reuse across the codebase
src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx (1)

627-634: Good test isolation setup.

The beforeEach and afterEach blocks with vi.clearAllMocks() ensure proper test isolation, which aligns with project guidelines. Based on learnings, this pattern is required for all spec files.

src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.tsx (6)

11-16: Good refactoring - imports updated correctly.

The imports are correctly updated:

  • DatePicker from the shared-components path
  • BaseModal from the shared-components path (replacing deprecated react-bootstrap Modal)
  • ApplyToSelector from AdminPortal components
  • ApplyToType from the types directory

98-98: State typing updated correctly.

The applyTo state now uses the exported ApplyToType instead of an inline literal union, improving type consistency across the codebase.


169-173: Clean boolean coercion.

Using Boolean() for explicit type coercion is cleaner and more readable than alternatives like double negation (!!).


441-449: ApplyToSelector integration is correct.

The component is rendered in the appropriate scenarios:

  1. Create mode with recurring events (isRecurring && !editMode)
  2. Edit mode for template items that aren't instance exceptions

The props are correctly wired to the component state.


433-440: BaseModal integration looks correct.

The BaseModal usage replaces the deprecated react-bootstrap Modal correctly, with proper props for show, onHide, title, and dataTestId.


596-608: No action required — the prop naming is correct.

The DatePicker component's interface explicitly defines the test ID prop as 'data-testid' (kebab-case string literal, line 38 of DatePicker.tsx), which is why the ActionItemModal correctly uses data-testid="assignmentDate" at line 602. Similarly, BaseModal defines its test ID prop as dataTestId (camelCase), which is correctly used at line 439. Each component accepts the prop naming defined in its own interface, so there is no inconsistency.

src/components/AdminPortal/ApplyToSelector/ApplyToSelector.tsx (1)

1-49: Component correctly implements ApplyToSelector with proper architecture and testing.

All verification complete:

  • ✅ i18n keys (applyTo, entireSeries, thisEventOnly) present in all 5 locale files
  • ✅ Props interface properly defined in src/types/AdminPortal/ApplyToSelector/interface.ts
  • ✅ Test file comprehensive (71 lines) covering render, state, and user interactions
  • ✅ Component follows reusable component policy (correct portal, no inline interfaces, TSDoc present)
  • ✅ Zero TypeScript errors
  • ✅ Semantic HTML (fieldset/legend) for accessibility

@palisadoes palisadoes merged commit 48dc88a into PalisadoesFoundation:develop Jan 11, 2026
37 of 39 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants