Added the EventRegistrants Tab under Events in Admin

[syedali237]

What kind of change does this PR introduce?

Feature

Issue Number:

Fixes #1750

Did you add tests for your changes?

Yes

Snapshots/Videos:

1733829955762569.mp4

If relevant, did you update the documentation?

No

Summary

Added the Event Registrants Tab under Admin. Admin can now add registrants for an event and Check-In Registrants.

Does this PR introduce a breaking change?

No

Other information

Have you read the contributing guide?

Yes

Summary by CodeRabbit

• New Features

  • Introduced a new EventRegistrants component for managing and displaying event registrant information.
  • Added a new GraphQL query, EVENT_REGISTRANTS, to retrieve event attendees.
  • New CSS styles for event registrants to enhance UI presentation.

• Bug Fixes

  • Updated the button text in tests and components for consistency.

• Tests

  • Enhanced test coverage for the AttendanceStatisticsModal and EventRegistrants components.
  • Created a new test file for the EventRegistrants component.

• Chores

  • Updated various dependencies in the project configuration.

[coderabbitai]

Walkthrough

The pull request introduces several changes to the talawa-admin project, including updates to dependencies in package.json, the addition of a new GraphQL query for event registrants, modifications to the CheckInWrapper component, and the creation of a new EventRegistrants component. Additionally, it enhances testing coverage for related components and introduces a new CSS module for styling. The changes aim to improve the functionality and user interface related to event management and registrant handling.

Changes

File	Change Summary
package.json	Updated dependencies: @pdfme/common, @pdfme/generator, @pdfme/schemas to 5.2.10; added cross-env; reinstated vitest and whatwg-fetch.
src/GraphQl/Queries/Queries.ts	Added new GraphQL query EVENT_REGISTRANTS for fetching event attendees.
src/components/CheckIn/CheckInWrapper.tsx	Removed IconComponent, replaced it with an <img> for SVG icon, updated button styles.
src/components/CheckIn/tagTemplate.ts	Modified schemas structure from an array of objects to an array of arrays; changed basePdf quotes.
src/components/EventManagement/EventAttendance/EventStatistics.test.tsx	Enhanced mock data structure and refined test cases for AttendanceStatisticsModal.
src/components/EventManagement/EventAttendance/InterfaceEvents.ts	Added time property to InterfaceMember interface.
src/components/EventManagement/EventRegistrant/EventStatistics.test.tsx	Introduced new test file for EventRegistrants component with mock data and testing setup.
src/components/EventManagement/EventRegistrant/EventRegistrants.tsx	New component for displaying event registrants, fetching data using GraphQL.
src/components/EventManagement/EventRegistrant/Registrants.mocks.ts	Introduced mock data for testing event registrants and attendees.
src/components/EventRegistrantsModal/EventRegistrantsWrapper.test.tsx	Updated button text in test case from 'Show Registrants' to 'Add Registrants'.
src/components/EventRegistrantsModal/EventRegistrantsWrapper.tsx	Removed icon component, changed button text to 'Add Registrants', updated button attributes.
src/components/MemberDetail/customTableCell.test.tsx	Modified date format in tests and commented out certain error handling tests.
src/screens/EventManagement/EventManagement.tsx	Integrated new EventRegistrants component into the EventManagement component.
src/components/EventManagement/EventRegistrant/EventRegistrants.module.css	Added new CSS styles for event registrants UI components.

Assessment against linked issues

Objective	Addressed	Explanation
Redesign the Event Management's Registrant tab ( #1750 )	✅
Combine show registrant and check-ins registrant in a single tab ( #1750 )	✅
Ensure registrant disappears after adding with success message ( #1750 )	❌	No implementation of toast notification.

Possibly related PRs

• Feature: Event Agenda Items CRUD operations #2062: Introduces CRUD operations for Event Agenda Items, potentially enhancing event registrant management.
• Redesign & Refac Fund, Campaign & Pledge Screen #2064: Involves redesigning screens related to funds and campaigns, which may overlap with event management functionalities.
• Tests for newly created events #2410: Focuses on testing visibility of newly created events, relevant to event registrant management.
• Fix Misplaced Screen Title & Fix Layout Structure #2412: Addresses alignment of UI elements, indirectly related to overall consistency in event management screens.
• changed color schema for the tag and action item screen #2417: Changes color schema for tag and action item screens, impacting visual representation of event-related tags.
• feat: Listing the Assigned Tags on the MemberDetail screen #2425: Adds functionality to list assigned tags on the MemberDetail screen, relevant for managing tags associated with events.

Suggested labels

ignore-sensitive-files-pr

Suggested reviewers

• palisadoes
• pranshugupta54
• varshith257

Poem

In the land of events, we hop and play,
Registrants gather, brightening the day.
With buttons to add and styles to cheer,
Our admin portal shines, full of good cheer!
So let’s toast to the changes, both big and small,
For in this new world, there's room for us all! 🐰✨

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Experiment)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[github-actions]

Our Pull Request Approval Process

Thanks for contributing!

Testing Your Code

Remember, your PRs won't be reviewed until these criteria are met:

1. We don't merge PRs with poor code quality.
   1. Follow coding best practices such that CodeRabbit.ai approves your PR.
2. We don't merge PRs with failed tests.
   1. When tests fail, click on the Details link to learn more.
   2. Write sufficient tests for your changes (CodeCov Patch Test). Your testing level must be better than the target threshold of the repository
   3. Tests may fail if you edit sensitive files. Ask to add the ignore-sensitive-files-pr label if the edits are necessary.
3. We cannot merge PRs with conflicting files. These must be fixed.

Our policies make our code better.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them.
When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

[coderabbitai]

Actionable comments posted: 4

🧹 Outside diff range and nitpick comments (10)

src/components/EventManagement/EventRegistrant/EventRegistrants.tsx (3)

101-105: Simplify conditional rendering of CheckInWrapper

Rendering CheckInWrapper with an empty eventId may not be necessary. You can simplify the code by rendering the component only when eventId is available.

Apply this diff to streamline the rendering logic:

 {eventId && (
-  <CheckInWrapper eventId={eventId.toString()} />
-)} : (
-  <CheckInWrapper eventId="" />
-)}
+  <CheckInWrapper eventId={eventId.toString()} />
 )}

---

107-116: Use semantic alt text for icons

The alt attribute for the image used in the button is set to "Sort", but the image source is /images/svg/organization.svg, which might not represent sorting. Ensure that the alt text accurately describes the icon for accessibility purposes.

Consider updating the alt text to reflect the icon's purpose:

 <img
   src="/images/svg/organization.svg"
   width={30.63}
   height={30.63}
-  alt="Sort"
+  alt="Organization Icon"
   className={styles.sortImg}
 />

---

185-186: Handle missing attendee names gracefully

When displaying {data.firstName} {data.lastName}, if either firstName or lastName is 'N/A', it may lead to awkward spacing or display issues. Consider handling cases where names are unavailable.

Apply this diff to improve name display:

-{data.firstName} {data.lastName}
+{`${data.firstName !== 'N/A' ? data.firstName : ''} ${
+  data.lastName !== 'N/A' ? data.lastName : ''
+}`}

src/components/CheckIn/CheckInWrapper.tsx (1)

30-36: Ensure correct alt text and consider dynamic image imports

The alt attribute for the image is set to "Sort", but the image source is "options-outline.svg", which may not represent sorting. Also, importing images dynamically can help with bundling and caching.

Update the alt text and consider importing the image:

+import optionsOutline from '/images/svg/options-outline.svg';

 <img
-  src="/images/svg/options-outline.svg"
+  src={optionsOutline}
   width={30.63}
   height={30.63}
-  alt="Sort"
+  alt="Options Icon"
   className={styles.sortImg}
 />

src/components/EventRegistrantsModal/EventRegistrantsWrapper.tsx (1)

29-36: Add descriptive aria-label for accessibility

The button lacks a descriptive aria-label, which can hinder accessibility for users relying on screen readers.

Provide a meaningful aria-label:

 <Button
   data-testid="filter-button"
   className={`border-1 mx-4`}
-  aria-label="showAttendees"
+  aria-label="Add Registrants"
   onClick={(): void => {
     setShowModal(true); // Show the modal when button is clicked
   }}
 >
   Add Registrants
 </Button>

src/components/EventManagement/EventRegistrant/Registrants.mocks.ts (2)

3-56: Consider enhancing mock data coverage

While the mock data structure is well-organized, consider these improvements:

1. Add more diverse test scenarios (e.g., empty attendees list, pagination)
2. Include additional fields that might be needed for future features (e.g., attendance status, check-in time)

export const REGISTRANTS_MOCKS = [
  // Existing mocks...
+ {
+   request: {
+     query: EVENT_REGISTRANTS,
+     variables: { eventId: '660fdf7d2c1ef6c7db1649ad' },
+   },
+   result: {
+     data: {
+       getEventAttendeesByEventId: [] // Empty list scenario
+     }
+   }
+ },
+ {
+   request: {
+     query: EVENT_ATTENDEES,
+     variables: { id: '660fdf7d2c1ef6c7db1649ad' },
+   },
+   result: {
+     data: {
+       event: {
+         attendees: [
+           {
+             _id: '6589386a2caa9d8d69087484',
+             firstName: 'Bruce',
+             lastName: 'Garza',
+             createdAt: '2023-04-13T10:23:17.742Z',
+             checkInTime: '2023-04-13T11:00:00.000Z',
+             attendanceStatus: 'CHECKED_IN',
+             __typename: 'User',
+           }
+         ]
+       }
+     }
+   }
+ }
];

---

58-67: Enhance error scenarios coverage

The error mock is good, but consider adding more specific error scenarios:

• Network errors
• Permission denied errors
• Invalid event ID errors

export const REGISTRANTS_MOCKS_ERROR = [
  // Existing error mock...
+ {
+   request: {
+     query: EVENT_REGISTRANTS,
+     variables: { eventId: 'event456' },
+   },
+   error: new Error('Permission denied: User not authorized to view registrants'),
+ },
+ {
+   request: {
+     query: EVENT_REGISTRANTS,
+     variables: { eventId: 'invalid' },
+   },
+   error: new Error('Invalid event ID'),
+ }
];

src/components/EventRegistrantsModal/EventRegistrantsWrapper.test.tsx (1)

Line range hint 1-91: Consider adding more test scenarios

The test coverage could be enhanced by adding:

1. Error handling scenarios
2. Loading state verification
3. Form validation tests
4. Modal content verification

Here's a suggested test structure:

// Add these test cases
test('should show loading state while fetching data', async () => {
  // Implementation
});

test('should handle network errors gracefully', async () => {
  // Implementation
});

test('should validate form inputs', async () => {
  // Implementation
});

test('should display correct modal content', async () => {
  // Implementation
});

src/components/EventManagement/EventRegistrant/EventRegistrants.test.tsx (1)

19-23: Simplify the wait function implementation

The wait function can be simplified as it's wrapping a Promise.resolve() unnecessarily.

-async function wait(): Promise<void> {
-  await waitFor(() => {
-    return Promise.resolve();
-  });
-}
+const wait = async (): Promise<void> => {
+  await waitFor(() => undefined);
+};

src/screens/EventManagement/EventManagement.tsx (1)

235-237: Consider adding error boundaries for the new tab

While the integration is clean, consider wrapping the EventRegistrants component with an error boundary to gracefully handle any rendering errors.

 return (
   <div data-testid="eventRegistrantsTab">
+    <ErrorBoundary fallback={<ErrorFallback />}>
       <EventRegistrants />
+    </ErrorBoundary>
   </div>
 );

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4bef093 and 726af82.

⛔ Files ignored due to path filters (3)

• package-lock.json is excluded by !**/package-lock.json
• public/images/svg/options-outline.svg is excluded by !**/*.svg
• public/images/svg/organization.svg is excluded by !**/*.svg

📒 Files selected for processing (14)

• package.json (3 hunks)
• src/GraphQl/Queries/Queries.ts (1 hunks)
• src/components/CheckIn/CheckInWrapper.tsx (1 hunks)
• src/components/CheckIn/tagTemplate.ts (1 hunks)
• src/components/EventManagement/EventAttendance/EventStatistics.test.tsx (2 hunks)
• src/components/EventManagement/EventAttendance/InterfaceEvents.ts (1 hunks)
• src/components/EventManagement/EventRegistrant/EventRegistrants.module.css (1 hunks)
• src/components/EventManagement/EventRegistrant/EventRegistrants.test.tsx (1 hunks)
• src/components/EventManagement/EventRegistrant/EventRegistrants.tsx (1 hunks)
• src/components/EventManagement/EventRegistrant/Registrants.mocks.ts (1 hunks)
• src/components/EventRegistrantsModal/EventRegistrantsWrapper.test.tsx (1 hunks)
• src/components/EventRegistrantsModal/EventRegistrantsWrapper.tsx (1 hunks)
• src/components/MemberDetail/customTableCell.test.tsx (1 hunks)
• src/screens/EventManagement/EventManagement.tsx (2 hunks)

✅ Files skipped from review due to trivial changes (1)

• src/components/EventManagement/EventRegistrant/EventRegistrants.module.css

🔇 Additional comments (10)

src/components/EventManagement/EventAttendance/InterfaceEvents.ts (1)

15-15: Ensure the time property is consistently used

You've added a time: string; property to InterfaceMember. Ensure that all implementations and usages of InterfaceMember across the codebase are updated to include the new time property to prevent TypeScript errors.

Run the following script to find all usages of InterfaceMember:

src/components/EventManagement/EventRegistrant/Registrants.mocks.ts (1)

1-2: LGTM: Clean import statement

The import statement correctly references the GraphQL queries needed for the mocks.

src/components/EventRegistrantsModal/EventRegistrantsWrapper.test.tsx (1)

80-80: Verify button text change matches component implementation

The button text has been changed from 'Show Registrants' to 'Add Registrants'. This change should be reflected in:

1. The actual EventRegistrantsWrapper component
2. Any related documentation or UI/UX specifications

✅ Verification successful

The output shows that "Add Registrants" text is present in the EventRegistrantsWrapper.tsx component, which aligns with the test's expectation. Let me verify the complete button implementation to ensure full consistency.

---

Button text change is consistent with implementation

The button text "Add Registrants" in the test matches exactly with the implementation in EventRegistrantsWrapper.tsx component, where it's used within a Button component that triggers the modal.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for the button text in the component
echo "Searching for button text in EventRegistrantsWrapper component..."
rg "Add Registrants|Show Registrants" src/components/EventRegistrantsModal/EventRegistrantsWrapper.tsx

# Search for any documentation references
echo "Searching for documentation references..."
fd -e md -e mdx | xargs rg "Add Registrants|Show Registrants"

Length of output: 426

---

Script:

#!/bin/bash
# Get the button implementation context from the component
echo "Searching for button implementation in EventRegistrantsWrapper..."
ast-grep --pattern 'button' src/components/EventRegistrantsModal/EventRegistrantsWrapper.tsx -A 5

# Alternative search using ripgrep for more context
echo "Getting broader context around 'Add Registrants'..."
rg -B 3 -A 3 "Add Registrants" src/components/EventRegistrantsModal/EventRegistrantsWrapper.tsx

Length of output: 654

src/components/EventManagement/EventRegistrant/EventRegistrants.test.tsx (1)

52-74: ⚠️ Potential issue

Enhance test coverage with additional test scenarios

The current test coverage is minimal and should include additional scenarios:

1. Error handling when API calls fail
2. Empty state rendering
3. Data loading states
4. User interactions (if any)
5. Edge cases for the registrants data

The second test name "Renders registrants button correctly" doesn't match its assertions which check for "stats-modal" and "filter-button".

Let's verify the component's functionality to guide the test coverage:

package.json (2)

140-140: LGTM: Good addition for cross-platform compatibility

Adding cross-env is a good practice for ensuring consistent environment variable handling across different platforms.

---

23-25: Verify compatibility with updated PDF packages

The @pdfme packages have been updated from 5.2.3/5.1.6 to 5.2.10. Ensure this update doesn't introduce breaking changes.

✅ Verification successful

The previous command failed because the file type 'tsx' wasn't recognized. Let's try with standard file extensions and also look specifically for PDF-related files that might use these packages.

---

The output shows we have PDF-related files and mocks. Let's examine their contents to understand how the @pdfme packages are used and if there might be any compatibility concerns with the version update.

---

We found the mock implementation and need to verify the actual usage of @pdfme packages in the codebase, as well as the test file to understand the complete usage pattern. This will help determine if there are any compatibility concerns with the version update.

---

We've found the main files using @pdfme packages. Let's examine their contents to understand the actual implementation and usage patterns to verify compatibility with the version update.

---

Based on the gathered information, I can now generate the final response. The code inspection shows that @pdfme packages are used in a limited way:

1. Only type imports from '@pdfme/common' for Template type
2. Basic usage of 'generate' from '@pdfme/generator' for PDF tag generation
3. Mock implementation for testing
4. Simple PDF generation with basic template and inputs validation

The usage is straightforward and doesn't rely on any complex features that might be affected by breaking changes. The update from 5.2.3/5.1.6 to 5.2.10 is a minor version bump, which typically indicates backward-compatible changes.

PDF package update appears safe to proceed

The @pdfme packages are used in a basic way for PDF tag generation, and the version update follows semantic versioning (minor version bump), suggesting backward compatibility.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for @pdfme package usage
rg "@pdfme" --type ts --type tsx -A 5

Length of output: 65

---

Script:

#!/bin/bash
# Search for @pdfme package usage with correct file extensions
rg "@pdfme" -t js -t jsx -t ts -t typescript -A 5

# Also check for any PDF-related files that might use these packages
fd -e js -e jsx -e ts -e typescript | grep -i "pdf"

Length of output: 263

---

Script:

#!/bin/bash
# Let's examine the content of these PDF-related files to understand the usage
cat src/utils/chartToPdf.ts
cat scripts/__mocks__/@pdfme/generator.ts

# Also check git history for these files to see recent changes
git log --since="3 months ago" -- src/utils/chartToPdf.ts scripts/__mocks__/@pdfme/generator.ts

Length of output: 3788

---

Script:

#!/bin/bash
# Let's check for any breaking changes in the actual usage of @pdfme packages
rg "from '@pdfme" -t js -t ts

# Let's also check the test file to see how it's being used
cat src/utils/chartToPdf.test.ts

Length of output: 5848

---

Script:

#!/bin/bash
# Let's check the actual usage in TableRow.tsx and tagTemplate.ts
cat src/components/CheckIn/TableRow.tsx
cat src/components/CheckIn/tagTemplate.ts

# Also check the generator test file
cat scripts/__mocks__/@pdfme/generator.test.ts

Length of output: 69330

src/screens/EventManagement/EventManagement.tsx (2)

20-20: LGTM: Clean import of the new component

The import follows the project's convention for component imports.

---

235-237: Verify prop requirements for EventRegistrants

The EventRegistrants component is rendered without props, but it might need the eventId that's available in the parent component.

src/GraphQl/Queries/Queries.ts (1)

331-339: LGTM! Verify query usage across components

The new EVENT_REGISTRANTS query is well-structured and follows GraphQL naming conventions. The fields returned (userId, isRegistered, _id) appear appropriate for event registration functionality.

✅ Verification successful

Let me verify the usage of EVENT_REGISTRANTS query by checking its implementation in the components.

---

Let me check the complete implementation of EventRegistrants component to verify proper error handling and usage.

---

LGTM! EVENT_REGISTRANTS query is properly implemented with error handling and caching

The query implementation in EventRegistrants.tsx shows:

• Proper usage of useLazyQuery with cache-and-network fetch policy
• Null checks in the onCompleted callback
• Proper data transformation and state management
• Clean UI handling for empty states
• Well-structured component with TypeScript interfaces

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of EVENT_REGISTRANTS query

# Check components using this query
echo "Components using EVENT_REGISTRANTS query:"
rg -l "EVENT_REGISTRANTS"

# Check for proper error handling of the query
echo "Error handling implementation:"
rg -A 5 "EVENT_REGISTRANTS.*useLazyQuery|useQuery"

Length of output: 66230

---

Script:

#!/bin/bash
# Check the implementation of EVENT_REGISTRANTS query in EventRegistrants.tsx
echo "Implementation in EventRegistrants.tsx:"
rg -A 10 "EVENT_REGISTRANTS" src/components/EventManagement/EventRegistrant/EventRegistrants.tsx

# Check for any error handling in the implementation
echo -e "\nError handling in EventRegistrants.tsx:"
rg -B 5 -A 10 "error|loading" src/components/EventManagement/EventRegistrant/EventRegistrants.tsx

Length of output: 1332

---

Script:

#!/bin/bash
# Get the full content of EventRegistrants.tsx
echo "Full content of EventRegistrants.tsx:"
cat src/components/EventManagement/EventRegistrant/EventRegistrants.tsx

# Check for any tests related to EVENT_REGISTRANTS
echo -e "\nTests for EVENT_REGISTRANTS:"
rg -l "EVENT_REGISTRANTS.*test|test.*EVENT_REGISTRANTS" --type ts

Length of output: 7276

src/components/CheckIn/tagTemplate.ts (1)

4-21: LGTM! Improved schema structure

The restructuring of the schemas array and consistent use of double quotes improves code readability while maintaining the same functionality.

✅ Verification successful

Let me gather more information about the template structure and its usage to verify the consistency.

---

Based on the results, I can see that the tagTemplate.ts file is the only template file with this schema structure, and it shows mixed usage of single and double quotes. Let me verify the actual usage pattern and impact.

---

Based on the results, I can now provide a final response as we have sufficient information about the template usage and structure:

Consistent template structure confirmed

The tagTemplate.ts file is the only template with this schema structure in the codebase, and it's only used by TableRow.tsx for PDF generation. The mixed quote usage (double quotes for keys, single quotes for values) follows a consistent pattern and is valid JSON/JavaScript syntax.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify template usage consistency

# Check for any other template files using similar structure
echo "Checking for similar template structures:"
rg -l "schemas.*\[\s*\[\s*\{" 

# Verify no regressions in template usage
echo "Checking template usage:"
rg -A 5 "tagTemplate"

Length of output: 3891

---

Script:

#!/bin/bash
# Check the content of the tagTemplate file and related files
echo "Checking tagTemplate.ts content:"
cat src/components/CheckIn/tagTemplate.ts

# Look for any other template files with similar structure
echo -e "\nChecking for other template files:"
fd -e ts -e js template

# Check for any inconsistent quote usage in template files
echo -e "\nChecking quote usage in templates:"
rg -l '"schemas":|"name"\s*:|"type"\s*:|"position"\s*:|"width"\s*:|"height"\s*:|"alignment"\s*:|"fontSize"\s*:|"characterSpacing"\s*:|"lineHeight"\s*:|"fontName"\s*:|"fontColor"\s*:'

Length of output: 66066

---

Script:

#!/bin/bash
# Check for any other files importing or using this template
echo "Checking template usage and imports:"
rg -p "tagTemplate" -B 2 -A 2

# Check for any similar schema structures in the codebase
echo -e "\nChecking for similar schema structures:"
ast-grep --pattern $'{\n  "schemas": [\n    [\n      {\n        $$$\n      }\n    ]\n  ]'

Length of output: 1950

[coderabbitai]

🛠️ Refactor suggestion

Handle potential undefined values when splitting timestamps

When matchedAttendee is undefined or createdAt is not available, timeWithMilliseconds becomes 'N/A'. Calling split('.') on 'N/A' could lead to unexpected results. Consider adding a condition to handle this scenario.

Apply this diff to safely handle the splitting:

const [time] = timeWithMilliseconds !== 'N/A'
  ? timeWithMilliseconds.split('.')
  : ['N/A'];

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const [date, timeWithMilliseconds] = matchedAttendee?.createdAt
	? matchedAttendee.createdAt.split('T')
	: ['N/A', 'N/A'];
	const [time] = timeWithMilliseconds.split('.');
	const [date, timeWithMilliseconds] = matchedAttendee?.createdAt
	? matchedAttendee.createdAt.split('T')
	: ['N/A', 'N/A'];
	const [time] = timeWithMilliseconds !== 'N/A'
	? timeWithMilliseconds.split('.')
	: ['N/A'];

[coderabbitai]

💡 Codebase verification

Based on the code analysis, I can now provide a definitive response about the ID matching between registrants and attendees.

ID matching between registrants and attendees is incorrect

The current code is trying to match attendee._id with registrant.userId, but looking at the GraphQL query response structure:

1. getEventAttendeesByEventId returns objects with:

   • userId: The actual user ID
   • _id: The event attendee record ID

2. The matching should use registrant.userId with attendee._id instead of the current implementation, as attendee._id is the user's ID while registrant.userId points to the user.

This needs to be fixed to prevent data inconsistencies.

🔗 Analysis chain

Verify matching IDs between registrants and attendees

In the data merging process, you are matching attendee._id with registrant.userId. Please ensure that these IDs correspond to the same user to prevent data inconsistencies.

Run the following script to verify the correspondence between registrant.userId and attendee._id:

---

Let me analyze the code further to verify the ID matching between registrants and attendees.

---

Let me search for the actual implementation of the event registrants component to verify the ID matching.

---

Let me search for the GraphQL schema or type definitions to verify the ID field mappings.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that registrant userIds match attendee _ids in the codebase.

# Find all occurrences of registrant userIds
rg 'userId' -A 2

# Find all occurrences of attendee _ids
rg '_id' -A 2

# Compare the IDs to ensure they match

Length of output: 103727

---

Script:

#!/bin/bash
# Search for registrant and attendee data structures and their ID fields
ast-grep --pattern 'interface $_Registrant {
  $$$
  userId: $_
  $$$
}'

ast-grep --pattern 'interface $_Attendee {
  $$$
  _id: $_
  $$$
}'

# Search for any GraphQL queries/mutations related to registrants and attendees
rg -A 5 'query.*Registrant|mutation.*Registrant|query.*Attendee|mutation.*Attendee'

Length of output: 15475

---

Script:

#!/bin/bash
# Search for the EventRegistrants component implementation
ast-grep --pattern 'const EventRegistrants = ($_) => {
  $$$
}'

# Search for any GraphQL queries related to event registrants and attendees
rg -A 10 'query.*EVENT_REGISTRANTS|query.*EVENT_ATTENDEES'

# Search for the specific file content
cat src/components/EventManagement/EventRegistrant/EventRegistrants.tsx

Length of output: 14309

---

Script:

#!/bin/bash
# Search for GraphQL query definitions and types
rg -A 5 'getEventAttendeesByEventId|event.*attendees' src/GraphQl/

# Search for any interface or type definitions related to attendees and registrants
ast-grep --pattern 'interface $_Attendee {
  $$$
}'

ast-grep --pattern 'interface $_EventAttendee {
  $$$
}'

ast-grep --pattern 'type $_EventAttendee {
  $$$
}'

Length of output: 525

[coderabbitai]

💡 Codebase verification

Date format in test is inconsistent with application's standard format

The codebase uses a standardized date format through the formatDate utility in src/utils/dateFormatter.ts. The test case's expected format '1 May 2023' doesn't match the application's standard format which includes ordinal indicators (e.g., '1st May 2023', '2nd Jun 2023', '3rd Jul 2023') as evidenced by:

• The formatDate utility tests in dateFormatter.test.ts
• Usage in production components like EventDashboard and AttendedEventList

The test should be updated to expect the date with the correct ordinal indicator: '1st May 2023'.

🔗 Analysis chain

Verify date format consistency across the application

The date format has been changed from 'May 1, 2023' to '1 May 2023'. Ensure this format is consistent with:

1. Other components displaying dates
2. User locale preferences
3. Application's date formatting standards

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for date format patterns across the codebase
echo "Searching for date format patterns..."
rg -l "toLocaleDateString|format\(.*date|moment\(.*format" --type tsx --type ts

# Search for date-related test assertions
echo "Searching for date format assertions in tests..."
rg "expect.*getByText.*\d{1,2}\s+[A-Za-z]+\s+\d{4}" --type test

Length of output: 396

---

Script:

#!/bin/bash
# Search for date format patterns across the codebase
echo "Searching for date format patterns..."
rg -l "toLocaleDateString|format.*date|moment.*format"

# Search for date-related test assertions
echo "Searching for date format assertions..."
rg "expect.*getByText.*[0-9].*[A-Za-z]+.*[0-9]{4}"

# Search for date formatting utility or helper functions
echo "Searching for date formatting utilities..."
rg "formatDate|dateFormat|formatDateTime"

Length of output: 3951

[coderabbitai]

💡 Codebase verification

Based on the shell script results, I can now generate the final response:

Time format is inconsistent across the application

The codebase shows multiple time format patterns:

• HH:MM format (e.g., "09:00") in EventStatistics.test.tsx
• HH:MM:SS format (e.g., "09:00:00") in most event-related components
• 12-hour format (e.g., "09:00 AM") in some test files

Locations requiring standardization:

• src/components/EventManagement/EventAttendance/EventStatistics.test.tsx: Uses "09:00" format
• src/screens/OrganizationEvents/OrganizationEvents.test.tsx: Uses "09:00 AM" format
• src/components/EventListCard/EventListCard.test.tsx: Uses "09:00 AM" format
• src/components/RecurrenceOptions/CustomRecurrence.test.tsx: Uses "09:00 AM" format

The API and most components use HH:MM:SS format, so this should be the standard format throughout the application.

🔗 Analysis chain

Verify time format consistency across the application

The added time property uses HH:MM format (09:00, 10:00). Ensure this format is consistent with:

1. The API contract for event attendee data
2. The time format used in the check-in functionality

Also applies to: 133-134

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check time format consistency across the codebase

# Search for time format patterns in the codebase
echo "Checking time format patterns:"
rg -A 2 '(time|Time).*:.*\d{2}:\d{2}'

# Search for time-related type definitions
echo "Checking time-related type definitions:"
ast-grep --pattern 'interface $_$ {
  $$$
  time: string
  $$$
}'

Length of output: 24000

[syedali237]

@duplixx Do I need to raise this PR with develop-postgres?

[raggettii]

Yup
Talawa-admin => develop-postgres
Talawa-api => develop

[duplixx]

• @syedali237 use color blind friendly colors
• fix type and formatting errors

[syedali237]

@duplixx should I close this PR then?

[duplixx]

@syedali237 switch to develop-postgres branch and pull changes from it

[palisadoes]

This PR has too many submitted files.

Please ensure the following:

1. Fetch the latest upstream/develop-postgres files
2. Make your PR modifications based on the local copy of this develop-postgres branch
3. Submit your PRs against our develop-postgres branch.
4. Your source branch in your local repository must not be the same as the target branch

Closing