32 lines
5.2 KiB
Markdown
32 lines
5.2 KiB
Markdown
# Configurable habits and project terminology
|
||
|
||
Owners can create any number of named habits and deactivate all of them. Each active habit has a daily integer counter with explicit increment/decrement controls. Deactivation preserves records. Names are trimmed and unique irrespective of case within the owner.
|
||
|
||
Four independent optional bounds are configurable: daily minimum/maximum and weekly minimum/maximum. Counts below minima and above maxima remain writable. Text and red styling identify shortfalls or excess; reaching a maximum does not disable increment. Only negative counts are forbidden. Bounds must be nonnegative integers, and a minimum must not exceed its corresponding maximum. Null removes that bound; zero remains a real bound. Monday–Sunday totals use a long integer to avoid overflow when summing valid daily integers.
|
||
|
||
A configuration takes effect from the device's current Monday, including daily bounds. Previous weeks retain their configuration, and repeated edits within a week replace that week's configuration. The current configuration form and historical counter display deliberately use their respective dates. The full monthly calendar remains a separate implementation node.
|
||
|
||
`AccountDefaults` initializes each owner once, inside the same owner transaction: customer/project Allgemein and habits Lesen and Spaziergänge, each with daily minimum 1, weekly minimum 5 and no maxima. Existing matching records and selected catalog preferences are retained. The persistent marker prevents resurrection after renaming or deactivation. Initialization also applies once to the existing guest account on first access after upgrade. No habits are special after insertion.
|
||
|
||
Optimistic versions reject stale configuration/count writes, including concurrent first writes to a day. Request receipts make replayed count requests idempotent. All service operations enforce the current owner. The shared guest owner remains the explicitly requested interim authentication model.
|
||
|
||
Domain terminology is now Project throughout application code, UI and specification. SQL migration renames the old table and reference columns while keeping identifiers, constraints, preferences and work entries. The old identifiers occur only where necessary for migration. The new generic baseline creates missing structures without dropping existing account or catalog data. Historical changesets are retained in database history and Git; their existing checksums are not rewritten. Extra old tables/columns remain untouched and are not used by the application.
|
||
|
||
## Verification
|
||
|
||
- `tools/ci-jvm`: 34 application/persistence tests and 12 authentication-prototype tests passed, plus 3 existing operational tests and production JAR smoke.
|
||
- Eight `HabitServiceTest` tests cover independent counters, optional limit history and null removal, all four advisory boundaries, stale writes, request replay, foreign owners, one-time defaults, large weekly totals, and migration of existing identifiers/preferences/entries with referential integrity.
|
||
- A separate local database was created with the actually published `aec192f` JAR. A customer and its former module were created through that UI. Starting the new production JAR migrated the database successfully; both records remained selectable as customer/project. This did not touch the public database.
|
||
- Browser checks exercised maximum configuration, increments beyond both maxima, decrements below both minima, red text feedback, deactivating both defaults and reloading the dashboard without active habits, and creating/counting an additional habit with all bounds blank.
|
||
- English and German rendered successfully. At 390 px viewport width the German habit page had no horizontal overflow. Browser error logs were empty. This is a responsive browser check, not a real Android push/PWA acceptance test.
|
||
|
||
Werkator also built commit `634d690` successfully in 153 seconds. The public application was updated to `6e6daa1` on 2026-09-09 using the closed-file backup and data-aware deployment; see `deployment.md`. Work entry/draft completion, the monthly habit calendar and remaining application nodes are not claimed complete here.
|
||
|
||
## Daily calendar and configuration dialogs
|
||
|
||
The Habits route now presents one selected habit in a month calendar. Rows span complete Monday–Sunday weeks, including adjacent-month dates, and show independent daily counts plus weekly totals. Each week uses its historically effective bounds. Clicking a past or current day opens its counter; future days cannot be counted. Closing the counter refreshes the calendar. The month header integrates previous/next navigation and a period dialog.
|
||
|
||
Creation and editing are dialogs with four optional advisory bounds. Configured creation is transactional: invalid bounds roll back the new habit, including its reserved name. Habit selection includes inactive records so their history and configuration remain accessible.
|
||
|
||
Validation: HabitServiceTest covers daily values, complete month/year-boundary weeks, leap day, historical bounds, owner isolation and atomic configured creation. Production build passed. Local browser checks at 390px and 1200px verified calendar rendering, month navigation, dialogs, invalid-bound correction, creation, a past-day increment and its updated weekly sum with the other day unchanged. Browser error log was empty.
|