Skip to content

Log any category retrospectively via an editable date on the log screen - #171

Open
mapgie wants to merge 2 commits into
mainfrom
claude/retrospective-category-logging-9zatrn
Open

Log any category retrospectively via an editable date on the log screen#171
mapgie wants to merge 2 commits into
mainfrom
claude/retrospective-category-logging-9zatrn

Conversation

@mapgie

@mapgiemapgie commented Aug 17, 2026

Copy link
Copy Markdown
Owner

Summary

All categories, whether built-in or user-defined, can now be logged retrospectively for a past date.

Previously the log screen always recorded against the date it was opened with, and the main "Log" button always opens on today. So there was no way to open, say, a custom "Mood" category from the Log button and record it for last Tuesday. The date shown in the screen header was display-only.

Change

The log screen now shows a tappable Date card that opens a date picker, so the user can set the day they are logging for. This works from every entry point (the Log button, the speed dial, the day sheet), not just from a specific calendar day.

  • LogCategoryViewModel.kt — Added setDate(newDate), which re-resolves any existing entry for the new (date, category) pair: switching to a day that already has an entry loads it for editing, and a blank day starts a fresh entry. It never moves or duplicates data. Saving always writes to the currently shown date. Added a canEditDate flag, true only for new entries.
  • LogCategoryScreen.kt — Added the DateSelectorCard (shown for new entries) and a DatePickerDialogWrapper mirroring the one on the Log Period screen.
  • changelog/unreleased/retrospective-category-logging.json — Added changelog fragment (minor).

Notes

  • The date stays fixed when editing one specific existing entry by id (opened from the day sheet's "edit"), where changing it would be ambiguous (it would abandon that entry rather than move it). Moving an existing entry to another day is intentionally out of scope.
  • For "Plus One" categories that track against time, changing the date reloads that day's timestamped entries so Log +1 now records against the chosen day.
  • a11y_check.py passes (the Date card carries role = Role.Button).

🤖 Generated with Claude Code

Long-pressing an empty past day previously only ran the single
configured quick-log action, so custom categories and the Symptoms
system category could not be logged retrospectively on a day that had
no entries yet. The one branch that did open the full log menu also
dropped the tapped date, logging against today instead.
Long-press now opens the full log menu (speed dial) targeting the
tapped day, giving every category, built-in or user-defined, a
retrospective logging path. Quick-log-on-tap for empty days is
unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013cQThXMdC9pWKCF1RQUqDn
Replaces the earlier long-press gesture change with a more discoverable
fix that works from every entry point, including the "Log" button, which
always defaults to today.
The log screen now shows a tappable Date card (for new entries) that
opens a date picker. Changing the date re-resolves any existing entry
for that (date, category) pair, so switching to a day that already has
an entry loads it for editing and a blank day starts a fresh entry. It
never moves or duplicates data: saving always writes to the shown date.
The date stays fixed when editing one specific existing entry by id
(opened from the day sheet), where changing it would be ambiguous.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013cQThXMdC9pWKCF1RQUqDn
@mapgiemapgie changed the title Make all categories retrospectively loggable from the calendarLog any category retrospectively via an editable date on the log screenAug 19, 2026
@mapgie
mapgie marked this pull request as ready for review August 19, 2026 08:24
Sign up for freeto 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

@mapgie@claude