Feature: users activity #55
Conversation
WalkthroughThis pull request includes several changes across multiple files, primarily focusing on analytics and data handling. The Changes
Possibly related PRs
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 23
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
⛔ Files ignored due to path filters (4)
README.mdis excluded by none and included by noneaction.ymlis excluded by none and included by nonebuild/index.jsis excluded by!build/**and included by nonepackage.jsonis excluded by none and included by none
📒 Files selected for processing (13)
src/analytics/index.ts(0 hunks)src/analytics/sendActionError.ts(1 hunks)src/analytics/sendActionRun.ts(1 hunks)src/analytics/sendDiscussionUsage.ts(0 hunks)src/converters/collectData.ts(2 hunks)src/converters/types.ts(1 hunks)src/converters/utils/index.ts(1 hunks)src/converters/utils/prepareActionsTime.ts(1 hunks)src/createOutput.ts(2 hunks)src/index.ts(0 hunks)src/view/utils/createActivityTimeMarkdown.ts(1 hunks)src/view/utils/createActivityXYChart.ts(1 hunks)src/view/utils/createConfigParamsCode.ts(1 hunks)
💤 Files with no reviewable changes (3)
- src/analytics/index.ts
- src/analytics/sendDiscussionUsage.ts
- src/index.ts
🔇 Additional comments (10)
src/converters/utils/index.ts (1)
8-8: LGTM! Export follows established pattern.
The new export for prepareActionsTime maintains consistency with the existing barrel file structure and follows the same pattern as other utility exports.
src/view/utils/createActivityTimeMarkdown.ts (2)
1-4: LGTM! Imports are clean and well-organized.
The imports are minimal and each imported entity is used within the implementation.
10-15: 🧹 Nitpick (assertive)
Verify the integration with createActivityXYChart.
The implementation looks correct but relies heavily on the createActivityXYChart function. Let's verify its implementation and error handling.
Additionally, consider adding error handling for the case when createActivityXYChart fails:
.map((user) => createActivityXYChart(data, user))
+ .filter(Boolean) // Filter out any failed chart generations
.join("\n");✅ Verification successful
The implementation is safe and well-handled
The createActivityXYChart implementation is robust with proper error handling through optional chaining and fallback values:
- Uses optional chaining (
?.) consistently for safe property access - Provides fallback empty objects (
|| {}) and zero values (|| 0) for missing data - Sets a minimum y-axis value of 1 to ensure valid chart rendering
- Returns a valid chart structure through
createXYChart
The suggestion to add .filter(Boolean) is unnecessary as the implementation cannot return undefined/null values due to the safe access patterns used.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the createActivityXYChart implementation and its error handling
# Search for the implementation
ast-grep --pattern 'export const createActivityXYChart = $_'
# Check for error handling in the implementation
rg -A 10 'createActivityXYChart'
Length of output: 8031
src/view/utils/createConfigParamsCode.ts (1)
21-21: LGTM! Verify parameter usage across the codebase.
The new configuration parameter is well-integrated and follows the existing naming conventions. The placement alongside other visualization parameters is logical.
Let's verify the consistent usage of this parameter across the codebase:
✅ Verification successful
Parameter usage is consistent and well-documented
The parameter SHOW_ACTIVITY_TIME_GRAPHS is properly integrated across the codebase:
- Documented in
action.ymlandREADME.mdwith clear description and default value - Used in analytics tracking (
sendActionError.tsandsendActionRun.ts) - Correctly implemented in output generation (
createOutput.ts) - Follows the same pattern as other configuration parameters
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the usage of SHOW_ACTIVITY_TIME_GRAPHS parameter
# Expected: Should find references in environment variable handling, graph generation logic, and analytics tracking
# Search for all occurrences of the parameter
echo "=== Direct usage of the parameter ==="
rg "SHOW_ACTIVITY_TIME_GRAPHS"
# Search for related activity time graph functionality
echo -e "\n=== Related activity time graph implementation ==="
rg -i "activity.*time.*graph"
Length of output: 3394
src/converters/utils/prepareActionsTime.ts (1)
14-16: Verify timezone handling for activity visualization
Since this code is meant for user activity visualization, it's important to ensure that the hours are calculated consistently across different timezones.
✅ Verification successful
Timezone handling is properly implemented for activity visualization
The codebase has appropriate timezone handling through the setTimezone utility, which sets the process timezone based on the "TIMEZONE" configuration parameter. This ensures that all date-fns operations (getHours, parseISO) use the configured timezone consistently across the application. The implementation in prepareActionsTime.ts will correctly reflect user activity times in the specified timezone.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for timezone-related configurations or conversions in the codebase
rg -i "timezone|utc|local time" --type ts
# Check if date-fns timezone utilities are used anywhere
rg "date-fns/(tzParseTimezone|formatInTimeZone|zonedTimeToUtc)" --type ts
Length of output: 2010
Script:
#!/bin/bash
# Let's check the timezone setup implementation
cat src/common/utils/setTimezone.ts
# Check how getHours and parseISO are imported and used
rg -A 2 "import.*getHours.*parseISO" --type ts
# Check the full implementation of prepareActionsTime
cat src/converters/utils/prepareActionsTime.ts
Length of output: 2680
src/analytics/sendActionRun.ts (1)
42-43: LGTM! Verify integration with activity visualization feature.
The new analytics properties align well with the PR's objective of adding user activity visualization. Let's verify the integration with other components.
✅ Verification successful
Integration verified - new graph features are properly connected
The verification shows comprehensive integration of the new analytics properties:
- Environment variables are properly documented in README.md with clear descriptions
- Action configuration in action.yml includes both flags with default values
- Implementation in createOutput.ts handles both graph types conditionally
- Analytics tracking is consistent in both sendActionRun.ts and sendActionError.ts
- Config parameters are properly exported in createConfigParamsCode.ts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the integration of new graph features across the codebase
# Check for related environment variable usage
echo "Checking environment variable usage:"
rg "SHOW_CORRELATION_GRAPHS|SHOW_ACTIVITY_TIME_GRAPHS" -A 3
# Check for graph-related implementations
echo "Checking for graph-related implementations:"
ast-grep --pattern 'function $FUNC_NAME($$$) {
$$$
activity$$$Graph
$$$
}'
Length of output: 7407
src/converters/collectData.ts (2)
15-15: LGTM!
The import statement follows the existing pattern and is properly organized.
51-55: Verify the impact on the collection object
The function modifies the shared collection object, but its effects aren't immediately clear from the context.
Let's analyze the usage:
✅ Verification successful
The collection object modifications are well-defined and safe
The prepareActionsTime function makes controlled modifications to the collection object using lodash's get and set utilities. It:
- Tracks action times (review, open, merge) by hour
- Updates counters for both total and per-user statistics
- Uses consistent path patterns with proper fallbacks
- Safely handles undefined values
The modifications are isolated to specific paths within the collection object and don't interfere with the time-related metrics we saw in the previous results.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Analyze how the collection object is modified
# Look for other modifications to verify potential conflicts
echo "Searching for collection modifications..."
ast-grep --pattern 'collection[$_] = $_'
echo "Checking prepareActionsTime implementation..."
rg -A 10 "function prepareActionsTime"
Length of output: 277
Script:
#!/bin/bash
# Let's try a different approach to analyze the collection object and prepareActionsTime function
# Search for prepareActionsTime function definition with a more flexible pattern
echo "Searching for prepareActionsTime function..."
rg -l "prepareActionsTime"
# Look for the function implementation with context
echo "Looking for function implementation..."
ast-grep --pattern 'function prepareActionsTime($_) {
$$$
}'
# Search for collection object modifications with a broader pattern
echo "Searching for collection object usage..."
rg -A 5 "collection\."
rg -A 5 "collection\["
Length of output: 17741
Script:
#!/bin/bash
# Let's specifically look at the prepareActionsTime implementation
echo "Looking for prepareActionsTime implementation in its dedicated file..."
cat src/converters/utils/prepareActionsTime.ts
# Also check how it's imported and used
echo "\nChecking imports and usage..."
rg -A 2 "import.*prepareActionsTime"
Length of output: 2404
src/createOutput.ts (2)
14-14: LGTM!
The import statement follows TypeScript conventions and maintains consistency with the project structure.
84-89: Verify the link format in the markdown generation.
Ensure that the link format in the markdown generation is consistent with the project's documentation standards.
✅ Verification successful
Let me search for more context about the markdown generation and link formats in the codebase.
Let me check the actual markdown generation function and the README for any formatting guidelines.
Based on the analysis of the codebase and the documentation, I can now provide a final response:
The link format ${issue.data.html_url}# is consistent with the project's implementation.
The link format is used consistently throughout the codebase for pull request reports, as evidenced by multiple occurrences in src/createOutput.ts. The trailing # in the URL is intentional as it's used for linking to the top of the pull request page, which is a common pattern in GitHub URLs. The documentation also shows examples of similar link formats in the report examples.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar link generation patterns in the codebase
rg -A 2 'link: `\$\{.*\.html_url\}#`'
Length of output: 1186
Script:
#!/bin/bash
# Search for the createActivityTimeMarkdown function implementation
ast-grep --pattern 'function createActivityTimeMarkdown($_) {
$$$
}'
# Search for other markdown link generation patterns
rg -A 2 'link:.*html_url'
# Check if there's any documentation about markdown formatting
fd README.md
Length of output: 1558
Script:
#!/bin/bash
# Check the content of createActivityTimeMarkdown function
rg -A 10 'function createActivityTimeMarkdown' src/
# Check README content for any markdown formatting guidelines
cat README.md
Length of output: 41557
| @@ -5,3 +5,4 @@ export { prepareDiscussions } from "./prepareDiscussions"; | |||
| export { prepareReviews } from "./prepareReviews"; | |||
| export { prepareResponseTime } from "./prepareResponseTime"; | |||
| export { prepareRequestedReviews } from "./prepareRequestedReviews"; | |||
| export { prepareActionsTime } from "./prepareActionsTime"; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add unit tests for the new functionality.
According to the PR checklist, tests haven't been added for the new changes. Since prepareActionsTime is a crucial component for the new user activity visualization feature, it should be thoroughly tested to ensure reliability.
Would you like me to help generate unit tests for the prepareActionsTime functionality? I can create a test suite that covers:
- Input validation
- Time calculation accuracy
- Edge cases handling
- Integration with the collection object
| import { Collection } from "../../converters"; | ||
| import { createActivityXYChart } from "./createActivityXYChart"; | ||
| import { createReferences } from "./createReferences"; | ||
|
|
||
| export const createActivityTimeMarkdown = ( | ||
| data: Record<string, Record<string, Collection>>, | ||
| users: string[], | ||
| references: { title: string; link: string }[] = [] | ||
| ) => { | ||
| const activity = users | ||
| .filter( | ||
| (user) => Object.keys(data[user]?.total?.actionsTime || {}).length > 1 | ||
| ) | ||
| .map((user) => createActivityXYChart(data, user)) | ||
| .join("\n"); | ||
|
|
||
| return [createReferences(references)].concat(activity).join("\n").trim(); | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add unit tests for the activity time markdown generation.
The PR objectives indicate that no tests were added. Given the complexity of data processing and the importance of this feature for visualizing user activity, unit tests are essential to ensure reliability.
Would you like me to help generate unit tests for this file? The tests should cover:
- Basic functionality with valid inputs
- Edge cases (empty data, no users)
- Error handling scenarios
- Integration with createActivityXYChart
| export const createActivityTimeMarkdown = ( | ||
| data: Record<string, Record<string, Collection>>, | ||
| users: string[], | ||
| references: { title: string; link: string }[] = [] | ||
| ) => { |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider adding input validation and improving type definitions.
- The nested Record type could be extracted to a dedicated type/interface for better maintainability.
- Missing validation for required parameters
dataandusers.
Consider applying these improvements:
+type ActivityData = Record<string, Record<string, Collection>>;
+type Reference = { title: string; link: string };
+
export const createActivityTimeMarkdown = (
- data: Record<string, Record<string, Collection>>,
- users: string[],
- references: { title: string; link: string }[] = []
+ data: ActivityData,
+ users: string[],
+ references: Reference[] = []
) => {
+ if (!data || !users) {
+ throw new Error('Required parameters "data" and "users" must be provided');
+ }📝 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.
| export const createActivityTimeMarkdown = ( | |
| data: Record<string, Record<string, Collection>>, | |
| users: string[], | |
| references: { title: string; link: string }[] = [] | |
| ) => { | |
| type ActivityData = Record<string, Record<string, Collection>>; | |
| type Reference = { title: string; link: string }; | |
| export const createActivityTimeMarkdown = ( | |
| data: ActivityData, | |
| users: string[], | |
| references: Reference[] = [] | |
| ) => { | |
| if (!data || !users) { | |
| throw new Error('Required parameters "data" and "users" must be provided'); | |
| } |
| .map((user) => createActivityXYChart(data, user)) | ||
| .join("\n"); | ||
|
|
||
| return [createReferences(references)].concat(activity).join("\n").trim(); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider improving readability and handling empty results.
The current implementation could be more explicit and handle edge cases better.
Consider this alternative:
- return [createReferences(references)].concat(activity).join("\n").trim();
+ const parts = [
+ createReferences(references),
+ activity
+ ].filter(Boolean);
+
+ if (parts.length === 0) {
+ return "No activity data available.";
+ }
+
+ return parts.join("\n").trim();📝 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.
| return [createReferences(references)].concat(activity).join("\n").trim(); | |
| const parts = [ | |
| createReferences(references), | |
| activity | |
| ].filter(Boolean); | |
| if (parts.length === 0) { | |
| return "No activity data available."; | |
| } | |
| return parts.join("\n").trim(); |
| lines: [ | ||
| { | ||
| name: "Opened", | ||
| color: "black", | ||
| values: hours.map( | ||
| (el) => data[user]?.total?.actionsTime?.[el]?.opened || 0 | ||
| ), | ||
| }, | ||
| { | ||
| name: "Merged", | ||
| color: "purple", | ||
| values: hours.map( | ||
| (el) => data[user]?.total?.actionsTime?.[el]?.merged || 0 | ||
| ), | ||
| }, | ||
| { | ||
| name: "Approved", | ||
| color: "green", | ||
| values: hours.map( | ||
| (el) => data[user]?.total?.actionsTime?.[el]?.approved || 0 | ||
| ), | ||
| }, | ||
| { | ||
| name: "Changes Requested", | ||
| color: "red", | ||
| values: hours.map( | ||
| (el) => data[user]?.total?.actionsTime?.[el]?.changes_requested || 0 | ||
| ), | ||
| }, | ||
| { | ||
| name: "Commented", | ||
| color: "blue", | ||
| values: hours.map( | ||
| (el) => data[user]?.total?.actionsTime?.[el]?.commented || 0 | ||
| ), | ||
| }, | ||
| ], |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Refactor repeated code and improve accessibility
The lines configuration has several areas for improvement:
- The code is repetitive and could be DRYer
- Color choices should consider accessibility (color blindness)
- Consider adding error handling for completely missing data
+const ACTIVITY_TYPES = [
+ { name: 'Opened', color: '#000000', key: 'opened' },
+ { name: 'Merged', color: '#9333EA', key: 'merged' },
+ { name: 'Approved', color: '#16A34A', key: 'approved' },
+ { name: 'Changes Requested', color: '#DC2626', key: 'changes_requested' },
+ { name: 'Commented', color: '#2563EB', key: 'commented' }
+] as const;
+
+const getActivityValues = (
+ actionsTime: Record<string, Record<string, number>> = {},
+ hours: string[],
+ key: string
+) => hours.map(hour => actionsTime[hour]?.[key] || 0);
+
lines: [
- {
- name: "Opened",
- color: "black",
- values: hours.map(
- (el) => data[user]?.total?.actionsTime?.[el]?.opened || 0
- ),
- },
- // ... other repeated blocks
+ ...ACTIVITY_TYPES.map(({ name, color, key }) => ({
+ name,
+ color,
+ values: getActivityValues(data[user]?.total?.actionsTime, hours, key)
+ }))
],Also, consider adding a check for completely missing data:
if (!data[user]?.total?.actionsTime) {
throw new Error(`No activity data found for user: ${user}`);
}| actionsTime?: Record< | ||
| string, | ||
| { | ||
| opened?: number; | ||
| merged?: number; | ||
| approved?: number; | ||
| changes_requested?: number; | ||
| commented?: number; | ||
| } | ||
| >; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add JSDoc comments to document the property.
Adding documentation would help other developers understand the purpose and format of the timestamps.
Consider adding documentation:
+ /**
+ * Records timestamps of different PR actions throughout the day.
+ * The outer key represents the hour of the day (0-23).
+ * The inner object contains counts of different actions performed during that hour.
+ * All timestamp values should be in UTC to ensure consistent tracking across timezones.
+ */
actionsTime?: Record<
string,
{
opened?: number;
merged?: number;
approved?: number;
changes_requested?: number;
commented?: number;
}
>;📝 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.
| actionsTime?: Record< | |
| string, | |
| { | |
| opened?: number; | |
| merged?: number; | |
| approved?: number; | |
| changes_requested?: number; | |
| commented?: number; | |
| } | |
| >; | |
| /** | |
| * Records timestamps of different PR actions throughout the day. | |
| * The outer key represents the hour of the day (0-23). | |
| * The inner object contains counts of different actions performed during that hour. | |
| * All timestamp values should be in UTC to ensure consistent tracking across timezones. | |
| */ | |
| actionsTime?: Record< | |
| string, | |
| { | |
| opened?: number; | |
| merged?: number; | |
| approved?: number; | |
| changes_requested?: number; | |
| commented?: number; | |
| } | |
| >; |
🧹 Nitpick (assertive)
Consider using a union type for action keys.
The type structure is well-designed for tracking timestamps of different PR actions. However, using string as the key type allows any string value, which could lead to inconsistencies.
Consider using a union type to restrict possible keys:
+ type ActionType = 'opened' | 'merged' | 'approved' | 'changes_requested' | 'commented';
actionsTime?: Record<
- string,
+ ActionType,
{
opened?: number;
merged?: number;
approved?: number;
changes_requested?: number;
commented?: number;
}
>;Committable suggestion skipped: line range outside the PR's diff.
| prepareActionsTime( | ||
| pullRequest, | ||
| data.events[index]?.filter((el) => el), | ||
| collection | ||
| ); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider enhancing error handling and event filtering
The current implementation has a few areas that could be improved:
- The event filtering
filter((el) => el)only removes falsy values. Consider being more explicit about which events are needed. - There's no error handling around the function call.
Consider applying this improvement:
- prepareActionsTime(
- pullRequest,
- data.events[index]?.filter((el) => el),
- collection
- );
+ try {
+ prepareActionsTime(
+ pullRequest,
+ data.events[index]?.filter((el) => el?.event), // Be explicit about required fields
+ collection
+ );
+ } catch (error) {
+ console.error('Failed to prepare actions time:', error);
+ // Consider how errors should affect the overall collection
+ }📝 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.
| prepareActionsTime( | |
| pullRequest, | |
| data.events[index]?.filter((el) => el), | |
| collection | |
| ); | |
| try { | |
| prepareActionsTime( | |
| pullRequest, | |
| data.events[index]?.filter((el) => el?.event), // Be explicit about required fields | |
| collection | |
| ); | |
| } catch (error) { | |
| console.error('Failed to prepare actions time:', error); | |
| // Consider how errors should affect the overall collection | |
| } |
🧹 Nitpick (assertive)
💡 Codebase verification
Add tests for the prepareActionsTime functionality
Based on the codebase analysis:
- The repository has an established test structure with several test files in
src/converters/utils/calculations/ prepareActionsTimeis a critical utility function insrc/converters/utils/prepareActionsTime.ts- No existing tests were found for this functionality
Please add test coverage for:
src/converters/utils/prepareActionsTime.ts- Integration test in
src/converters/collectData.tswhereprepareActionsTimeis used
🔗 Analysis chain
Add tests for the new functionality
The PR objectives indicate that no tests were added. Since this is adding new functionality for user activity visualization, it's important to have test coverage.
Let's check the existing test coverage:
Would you like me to help create test cases for:
- The
prepareActionsTimeintegration incollectData - Various scenarios of event filtering
- Error handling cases
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check test coverage for the collectData functionality
# Look for test files related to collectData and actionsTime
echo "Searching for related test files..."
fd -e test.ts -e spec.ts . | grep -i "collect\|action"
echo "Checking for existing test patterns..."
rg -l "describe.*collectData|test.*prepareActionsTime"
Length of output: 281
Script:
#!/bin/bash
# Let's try a broader search for test files and patterns
# First, let's find all test files in the repository
echo "All test files in the repository:"
fd -e test.ts -e spec.ts
# Look for any mentions of collectData or prepareActionsTime in the codebase
echo -e "\nSearching for collectData references:"
rg "collectData" -A 2 -B 2
echo -e "\nSearching for prepareActionsTime references:"
rg "prepareActionsTime" -A 2 -B 2
# Let's also check the implementation to understand the scope
echo -e "\nChecking implementation of prepareActionsTime:"
ast-grep --pattern 'function prepareActionsTime($_) { $$$ }'
Length of output: 6707
| if (getValueAsIs("SHOW_ACTIVITY_TIME_GRAPHS") === "true") { | ||
| const activityComment = await octokit.rest.issues.createComment({ | ||
| repo: getValueAsIs("GITHUB_REPO_FOR_ISSUE"), | ||
| owner: getValueAsIs("GITHUB_OWNER_FOR_ISSUE"), | ||
| issue_number: issue.data.number, | ||
| body: createActivityTimeMarkdown(data, users, [ | ||
| { | ||
| title: "Pull Request report total", | ||
| link: `${issue.data.html_url}#`, | ||
| }, | ||
| ]), | ||
| }); | ||
| comments.push({ | ||
| comment: activityComment, | ||
| title: "Activity time Graphs", | ||
| }); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add unit tests for the new functionality.
The PR objectives mention that no tests were added. Please add unit tests to cover:
- Activity time graph generation
- Environment variable handling
- Comment creation error scenarios
Would you like me to help generate the test cases for this new functionality?
Pull Request
Description
Added a new graph that displays user activity throughout the day.
Type of Change
How Has This Been Tested?
Run action for different users and periods.
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Improvements
Bug Fixes
sendDiscussionUsagefunction, streamlining analytics tracking.Documentation