Skip to content

[feat] : Add schedule types, enums, constants, and utilities#41

Open
not-meet wants to merge 1 commit into
RocketChat:feature/automated-schedule-reportsfrom
not-meet:feat/schedule-types-enums
Open

[feat] : Add schedule types, enums, constants, and utilities#41
not-meet wants to merge 1 commit into
RocketChat:feature/automated-schedule-reportsfrom
not-meet:feat/schedule-types-enums

Conversation

@not-meet

Copy link
Copy Markdown
Collaborator

Description

Adds the foundational types, enums, constants, language objects etc for
upcoming scheduled spam-report feature.

@not-meet
not-meet requested a review from alfredodelfabro July 18, 2026 22:19
@@ -0,0 +1,14 @@
export function daysBetween(sinceTimestamp: number): string[] {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

nitpick: daysBetween ignores utcOffsetMinutes. Likely a bug for the eventual integration.

ScheduleDraft.utcOffsetMinutes signals that reports are anchored to the admin's local timezone, but daysBetween (src/lib/utils/scheduleSummaryUtils.ts) computes day boundaries purely in UTC (setUTCHours, toISOString().slice(0, 10)). When these are combined in a follow-up PR, a report period that spans a local-midnight boundary will bucket flags into the wrong calendar day near the edges.

Suggest reconciling now. For example: accept the offset as a parameter and shift before slicing the date. Or, for now, at minimum add a // UTC-only comment so the follow-up doesn't silently inherit the mismatch.

@not-meet not-meet Jul 22, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

hey @scuciatto ! , I Looked into this, and I believe we should not add the timezone offset into how flags are bucketed for storage. Here's why: the offset can change if someone updates the schedule later, maybe another admin with a different timezone, and if storage depends on it, old flags and new flags could end up filed inconsistently. Thus keeping one single independent source of truth for flag saving time looks more stable.

I did add one change in persistence to close a related gap: AdminActionLogStore.getActionsSince was returning the whole first day's bucket instead of cutting off exactly at the requested timestamp, fixed with a direct filter on the entry's timestamp (entry.timestamp >= sinceTimestamp), no timezone math needed.

@not-meet
not-meet requested a review from scuciatto July 22, 2026 22:16
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