feat(subscriptions): add weekday display to subscription summary#53154
Merged
vdekrijger merged 2 commits intomasterfrom Apr 8, 2026
Merged
feat(subscriptions): add weekday display to subscription summary#53154vdekrijger merged 2 commits intomasterfrom
vdekrijger merged 2 commits intomasterfrom
Conversation
Add WEEKDAY_SET constant and three-way branch in the summary property: single day shows the capitalized name, Mon-Fri shows "weekday", all days shows "day". Includes parameterized tests for all bysetpos values and rrule edge cases (weekend-start months, leap years).
Contributor
|
Size Change: +2.1 kB (0%) Total Size: 127 MB
ℹ️ View Unchanged
|
13e845f to
7136b64
Compare
Contributor
MCP UI Apps size report
|
7136b64 to
487c3d0
Compare
487c3d0 to
cfe33e6
Compare
Contributor
Visual regression: Storybook UI snapshots updatedChanges: 2 snapshots (2 modified, 0 added, 0 deleted) What this means:
Next steps:
|
125ba17 to
2fb5d21
Compare
Contributor
|
🎭 Playwright report · View test results →
These issues are not necessarily caused by your changes. |
2f7c891 to
cb0a8fb
Compare
Contributor
Prompt To Fix All With AIThis is a comment left during a code review.
Path: frontend/src/generated/core/api.ts
Line: 1875-1888
Comment:
**Wrong URL in generated API function**
The generated `subscriptionsDeliverCreate` function targets `/deliver/` but the backend endpoint is registered with `url_path="test-delivery"` and therefore lives at `/api/projects/${projectId}/subscriptions/${id}/test-delivery/`. If this generated function is ever called it will receive a 404.
The manually-written `api.subscriptions.testDelivery` in `frontend/src/lib/api.ts` correctly uses `test-delivery`, so runtime behaviour is fine today. However the generated file should be regenerated via `hogli build:openapi` to align the function name and URL with the actual backend path.
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix: Self review updates" | Re-trigger Greptile |
87a6ba2 to
46b154a
Compare
MattPua
approved these changes
Apr 7, 2026
inkeep Bot
added a commit
to PostHog/posthog.com
that referenced
this pull request
Apr 8, 2026
…test delivery sections Reflects changes from PostHog/posthog#53154: - Document weekday scheduling option for monthly subscriptions - Document next delivery date display in subscription list and edit views - Document manual test delivery feature
vdekrijger
added a commit
to PostHog/posthog.com
that referenced
this pull request
Apr 8, 2026
…delivery date features (#16231) Reflects changes from PostHog/posthog#53154: - Document weekday scheduling option for monthly subscriptions - Document next delivery date display in subscription list and edit views - Document manual test delivery feature Co-authored-by: inkeep[bot] <257615677+inkeep[bot]@users.noreply.github.com> Co-authored-by: Vasco de Krijger <66254686+vdekrijger@users.noreply.github.com>
MattBro
pushed a commit
that referenced
this pull request
Apr 8, 2026
) ## Problem <!-- Who are we building for, what are their needs, why is this important? --> <!-- Does this fix an issue? Uncomment the line below with the issue ID to automatically close it when merged --> <!-- Closes #ISSUE_ID --> This PR addresses several papercuts raised in [this Slack thread](https://posthog.slack.com/archives/C0ACRAMJUAG/p1775050554519159), effectively it boils down to: 1. Not being able to manually trigger a subscription 2. Unclear when a subscription is "planned" to be scheduled 3. Not being able to fire off a subscription at the "first weekday of the month" (ignoring holidays) These are all addressed in a single PR (as they are all small-ish features) and will hopefully improve the UX of the subscriptions going forward. This is also a great use case for our [SLO reliability](https://us.posthog.com/project/2/dashboard/1397132) dashboard as we can continiously monitor the impact of these changes. ## Changes **1)** **Able** **to** **trigger** **ad** **hoc** **subscription** **triggers**   **2)** **Showing** **the** **"next** **delivery"** **date** **of** **a** **subcription** (they don't align as I was toying with different options): ##  > [!NOTE] >  > > Not entirely sure about having the "next delivery" date being calculated on both the frontend and backend (even though the logic is very simple and the rrule logic is "static"). But I figured this beats having to query the backend for every adjustment which could add a negative UX as well. Happy to be challenged here if you as reviewer don't like this, I'd also be okay with removing this. The idea to add it here was to help out with the weekday scheduling and to take away possible unneeded thinking / confusion for the user. **3)** **Adding a "weekday" option to the month selector for the first/2nd/3rd/last weekday:**  ## How did you test this code? :white_check_mark: Added new tests :white_check_mark: Manually confirmed the changes as per above <!-- Briefly describe the steps you took, and what steps reviewers must take to get to where changes are, and what is the expected behavior. --> <!-- Include automated tests if possible, otherwise describe the manual testing routine. --> <!-- If you are an agent writing this, do NOT include manual tasks you have NOT completed. You can clearly outline you're simply an agent and you haven't tested this manually except for code-based unit/integration tests --> 👉 _Stay up-to-date with_ [_PostHog coding conventions_](https://posthog.com/docs/contribute/coding-conventions) _for a smoother review._ ## Publish to changelog? Yes <!-- For features only --> <!-- If publishing, you must provide changelog details in the #changelog Slack channel. You will receive a follow-up PR comment or notification. --> <!-- If not, write "no" or "do not publish to changelog" to explicitly opt-out of posting to #changelog. Removing this entire section will not prevent posting. --> ## Docs update Yes <!-- Add the `skip-inkeep-docs` label if this PR should not trigger an automatic docs update from the Inkeep agent. --> <!-- ## 🤖 LLM context --> <!-- If an LLM agent co-authored or authored this PR, uncomment this section and leave any relevant context about the session, tools used, link to the session, or anything else that may help reviewers. -->
vdekrijger
added a commit
that referenced
this pull request
Apr 8, 2026
## Problem <!-- Who are we building for, what are their needs, why is this important? --> <!-- Does this fix an issue? Uncomment the line below with the issue ID to automatically close it when merged --> <!-- Closes #ISSUE_ID --> After merging #53154 I noticed that I still had some changes in a stash that I missed to commit in the earlier PR. This PR adds those tests to the codebase. ## Changes <!-- If there are frontend changes, please include screenshots. --> <!-- If a reference design was involved, include a link to the relevant Figma frame! --> ## How did you test this code? <!-- Briefly describe the steps you took, and what steps reviewers must take to get to where changes are, and what is the expected behavior. --> <!-- Include automated tests if possible, otherwise describe the manual testing routine. --> <!-- If you are an agent writing this, do NOT include manual tasks you have NOT completed. You can clearly outline you're simply an agent and you haven't tested this manually except for code-based unit/integration tests --> 👉 _Stay up-to-date with_ [_PostHog coding conventions_](https://posthog.com/docs/contribute/coding-conventions) _for a smoother review._ ## Publish to changelog? <!-- For features only --> <!-- If publishing, you must provide changelog details in the #changelog Slack channel. You will receive a follow-up PR comment or notification. --> <!-- If not, write "no" or "do not publish to changelog" to explicitly opt-out of posting to #changelog. Removing this entire section will not prevent posting. --> ## Docs update <!-- Add the `skip-inkeep-docs` label if this PR should not trigger an automatic docs update from the Inkeep agent. --> <!-- ## 🤖 LLM context --> <!-- If an LLM agent co-authored or authored this PR, uncomment this section and leave any relevant context about the session, tools used, link to the session, or anything else that may help reviewers. -->
warpbuild-benchmark-bot Bot
added a commit
to WarpBuilds/benchmarks-posthog
that referenced
this pull request
Apr 8, 2026
## Problem <!-- Who are we building for, what are their needs, why is this important? --> <!-- Does this fix an issue? Uncomment the line below with the issue ID to automatically close it when merged --> <!-- Closes #ISSUE_ID --> After merging PostHog/posthog#53154 I noticed that I still had some changes in a stash that I missed to commit in the earlier PR. This PR adds those tests to the codebase. ## Changes <!-- If there are frontend changes, please include screenshots. --> <!-- If a reference design was involved, include a link to the relevant Figma frame! --> ## How did you test this code? <!-- Briefly describe the steps you took, and what steps reviewers must take to get to where changes are, and what is the expected behavior. --> <!-- Include automated tests if possible, otherwise describe the manual testing routine. --> <!-- If you are an agent writing this, do NOT include manual tasks you have NOT completed. You can clearly outline you're simply an agent and you haven't tested this manually except for code-based unit/integration tests --> 👉 _Stay up-to-date with_ [_PostHog coding conventions_](https://posthog.com/docs/contribute/coding-conventions) _for a smoother review._ ## Publish to changelog? <!-- For features only --> <!-- If publishing, you must provide changelog details in the #changelog Slack channel. You will receive a follow-up PR comment or notification. --> <!-- If not, write "no" or "do not publish to changelog" to explicitly opt-out of posting to #changelog. Removing this entire section will not prevent posting. --> ## Docs update <!-- Add the `skip-inkeep-docs` label if this PR should not trigger an automatic docs update from the Inkeep agent. --> <!-- ## 🤖 LLM context --> <!-- If an LLM agent co-authored or authored this PR, uncomment this section and leave any relevant context about the session, tools used, link to the session, or anything else that may help reviewers. -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
This PR addresses several papercuts raised in this Slack thread, effectively it boils down to:
These are all addressed in a single PR (as they are all small-ish features) and will hopefully improve the UX of the subscriptions going forward. This is also a great use case for our SLO reliability dashboard as we can continiously monitor the impact of these changes.
Changes
1) Able to trigger ad hoc subscription triggers
2) Showing the "next delivery" date of a subcription (they don't align as I was toying with different options):
Note
Not entirely sure about having the "next delivery" date being calculated on both the frontend and backend (even though the logic is very simple and the rrule logic is "static"). But I figured this beats having to query the backend for every adjustment which could add a negative UX as well. Happy to be challenged here if you as reviewer don't like this, I'd also be okay with removing this. The idea to add it here was to help out with the weekday scheduling and to take away possible unneeded thinking / confusion for the user.
3) Adding a "weekday" option to the month selector for the first/2nd/3rd/last weekday:
How did you test this code?
✅ Added new tests
✅ Manually confirmed the changes as per above
👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Publish to changelog?
Yes
Docs update
Yes