Skip to content

Reflection notification time setting#4738

Closed
kodjima33 wants to merge 5 commits intomainfrom
cursor-agent-1770782434
Closed

Reflection notification time setting#4738
kodjima33 wants to merge 5 commits intomainfrom
cursor-agent-1770782434

Conversation

@kodjima33
Copy link
Collaborator

Add user-configurable time setting for daily reflection notifications in the Omi mobile app.

Previously, daily reflection notifications were hardcoded to 9 PM local time. This PR introduces a new setting in the app's notification settings page, allowing users to select their preferred hour for these notifications. The chosen time is persisted in the backend, ensuring cross-device sync and persistence across app restarts, and updates the local notification scheduling logic.


Open in Cursor Open in Web

cursoragent and others added 5 commits February 11, 2026 04:02
- Add database functions to store/retrieve reflection hour preference
- Add GET/PATCH endpoints for daily reflection settings
- Default hour is 21 (9 PM) local time
- Store enabled state and hour in Firestore user document

Co-authored-by: Nik Shevchenko <kodjima33@users.noreply.github.com>
- Add API client methods for reflection settings (GET/PATCH)
- Update notification scheduler to accept configurable hour
- Add time picker UI in notifications settings page
- Add Mixpanel tracking for reflection time changes
- Add localization key for reflection time setting
- Default hour is 21 (9 PM) if not set

Co-authored-by: Nik Shevchenko <kodjima33@users.noreply.github.com>
…ttings

- Update home page to load hour from API before scheduling
- Update developer mode provider to fetch and use stored hour
- Update desktop settings to use API-stored preferences
- Add Mixpanel tracking to desktop settings
- Ensure all notification scheduling uses configured hour

Co-authored-by: Nik Shevchenko <kodjima33@users.noreply.github.com>
…e setting

- Document all test scenarios and edge cases
- Include API testing examples
- Provide manual verification checklist
- Document known limitations and rollback plan

Co-authored-by: Nik Shevchenko <kodjima33@users.noreply.github.com>
- Document all changes with clear explanations
- Include verification steps and test results
- Document assumptions and how they were verified
- Provide reviewer guidance and key files to review
- Include API testing examples and edge cases
- Follow context-communication best practices

Co-authored-by: Nik Shevchenko <kodjima33@users.noreply.github.com>
@cursor
Copy link

cursor bot commented Feb 11, 2026

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
Learn more about Cursor Agents

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces a user-configurable time setting for daily reflection notifications, which is a great enhancement for user experience. The changes are well-implemented across both the backend and the mobile app, with good attention to consistency and backward compatibility. The new API endpoints are robust, and the UI changes are intuitive. I've found one high-severity issue related to the fallback behavior on app launch, which could prevent notifications from being scheduled under certain network conditions. Addressing this will make the feature more resilient.

Comment on lines +63 to +71
Future<void> _scheduleDailyReflectionIfEnabled() async {
final settings = await getDailyReflectionSettings();
if (settings != null && settings.enabled) {
DailyReflectionNotification.scheduleDailyNotification(
channelKey: 'channel',
hour: settings.hour,
);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

high

The current implementation of _scheduleDailyReflectionIfEnabled does not handle the case where getDailyReflectionSettings() returns null (e.g., due to a network error). This will cause the daily reflection notification to not be scheduled on app launch if the API call fails, which contradicts the intended fallback behavior mentioned in the pull request description ("If API call fails, system falls back to local default (9 PM)").

To ensure notifications are scheduled reliably even with intermittent network issues, you should provide default values for enabled and hour when the API call fails.

Future<void> _scheduleDailyReflectionIfEnabled() async {
  final settings = await getDailyReflectionSettings();
  // Fallback to default values if API call fails
  final enabled = settings?.enabled ?? true;
  final hour = settings?.hour ?? 21;

  if (enabled) {
    DailyReflectionNotification.scheduleDailyNotification(
      channelKey: 'channel',
      hour: hour,
    );
  }
}

@beastoin
Copy link
Collaborator

Closing this stale draft — no activity in 3+ days. Feel free to reopen when it's ready for review.

@beastoin beastoin closed this Feb 17, 2026
@github-actions
Copy link
Contributor

Hey @kodjima33 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

  • Project standards — Ensuring consistency across the codebase
  • User needs — Making sure changes align with what our users need
  • Code best practices — Maintaining code quality and maintainability
  • Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜

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.

3 participants

Comments