Jean-Luc Makiolaandmakiolaj
43ef4027f5
An event with several reminders posted a separate notification for each one. Each occurrence now has one notification, and every later reminder replaces the earlier one in place. - The notification tag and the snooze alarm are keyed on the occurrence. Snooze, dismiss and open actions stay per reminder, so tapping them on an outdated notification can't remove the newer one. - A different reminder alerts again; the same reminder posted twice stays silent. - If several reminders of one occurrence are due in the same scan (e.g. after the phone was off), only the latest is posted. - A newly due reminder cancels a pending snooze for its occurrence, and a snoozed reminder doesn't re-show over a newer one. - Notifications posted before this change still dismiss and snooze, and a newer reminder for the same event replaces them. - Reminder and occurrence keys share one hash in `ReminderPlan`. Closes #463 Co-authored-by: Jean-Luc Makiola <business@jeanlucmakiola.de> Reviewed-on: https://codeberg.org/jlmakiola/calendula/pulls/468
Documentation map
Where to look for what:
| Document | What it is |
|---|---|
../CONTRIBUTING.md |
How to contribute: issue-first workflow, which branch to target, translations, the rules a change is reviewed against |
BUILDING.md |
Building from source: submodule, JDK/SDK requirements, Gradle tasks, what CI runs |
ARCHITECTURE.md |
Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing |
RELEASING.md |
Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody |
../CHANGELOG.md |
Release history (Keep a Changelog, SemVer) |
| Issues + milestones | The roadmap: what's planned, in progress and shipped. A milestone maps to its release/vX.Y.Z branch |
../.planning/PROJECT.md |
What the project is: core value, stack + version pins, constraints, naming, forge/release infrastructure |
design/ |
Per-feature design notes kept for features whose provider behaviour is worth recording |
../fastlane/metadata/android/ |
Store metadata (single source of truth) for every app language, mapped in store-locales.txt: descriptions, title, graphics. Harvested directly by the official F-Droid repo, pushed to Google Play with every release, validated by ../scripts/check_store_listing.py; transformed into the self-hosted repo layout at release time by ../scripts/fastlane_to_fdroid_localized.sh |
../fdroid-metadata/ |
App-level F-Droid control file (*.yml: Categories, License, links) for the self-hosted repo's fdroid update |
fdroid-official/ |
Recipe and notes for publishing to the official F-Droid repo (reproducible build + developer-signed binary) |
Planning lives in the issue tracker and its milestones, not in this repository.
.planning/PROJECT.md describes the project itself.
ARCHITECTURE.md is updated with the code and is the place to record a lesson
learned about the calendar provider.