fd75833707903591f1d93235f848f8f91c26f325
13
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 tajniak81andClaude Opus 5
|
fd75833707 |
The cabin's temperature, and the one it is heading for
The climate cards landed with the endpoint migration, but only as two more folded dumps of key/value pairs. What a driver opens that tab for in January is one number, and it was three taps down inside a card called Climate. So currentTemperature and targetTemperature join the headline readings, beside the pair of electric ranges and for the same stated reason: neither figure answers the question on its own. A cabin at 12° means nothing until you know it is climbing towards 21°, and the gap between them is how long to leave the scraper in the boot. Being derived from headlineMetricSpecs, both are arrangeable the moment they exist — a car's saved order of readings can name them without anything else being told they are there, and a test now says so rather than leaving it to be noticed when a PATCH starts rejecting a key. The unit is fixed at Celsius, because Toyota Connected is the European service and there is no imperial reading to convert from. That is a default and not a claim: a payload that names its own unit is still believed over it, the way every other reading here works, so a service that one day reports Fahrenheit is labelled Fahrenheit rather than relabelled into a wrong Celsius. The two apps needed the two labels in three languages each and nothing else. That is the shape working: a section is an id the app localizes and a reading is a key it localizes, so a card added on the server arrives in both clients already folded, already arrangeable, already translated. The one thing the Web App did need was a corrected comment — the note explaining why cards fold still said Toyota reports eight sections, and it is the argument for folding them, so it should count the ten there now are. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 5
|
22a22ec43a |
Toyota: the status route the car answers, not the one it retired
Toyota put the /v1/global/remote read routes behind AWS SigV4 in mid-2026. A bearer token is no longer a credential there, so the doors-and-windows card has been asking a gateway that answers 403 — the one section of the provider tab that could only ever have been in error. The MyToyota app reads that state from /v1/vehicle/status now and pytoyoda followed it in 5.2.0; so does the connector. The electric route did not move, and the comment above the endpoint block says which of the two namespaces each one lives in, because the obvious tidy — sweep the rest onto /v1/vehicle/* — would break the ones that still work. The same migration gave the climate reads a home worth porting: /v1/vehicle/ climate-status is what the cabin is doing, climate-settings the preset it was told to do it at. Both are GETs with a vin, both are new cards on the tab, and their headings are in all three languages on both apps. Nothing about the tab's plumbing changed to hold them — a section is an id, an action, and whatever JSON comes back, which is the point of that shape. Left where they are: the POST wake calls. Upstream refreshes a stale reading by waking the modem, and this connector is documented as read-only, so climate and status show what the car last reported rather than what it would say if asked twice. The cost is a reading that can be hours old, and it is the honest one to pay for a connector that promises not to touch the vehicle. Two tests keep the migration from being undone by hand: one fails if any advertised capability points back at a retired route, the other if a capability is advertised without being wired into Invoke, which is the way the next endpoint would go missing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 5
|
a203414ceb |
Phone App: the garage on the car's own screen
The one place a service badge is worth reading is the car it belongs to, and that is the one place the app could not be opened: Android Auto runs no Flutter engine, so a Flutter app is simply absent from the head unit. The same APK now carries a second face — Car App Library templates the host draws itself, in Kotlin under android/app/src/main/kotlin/com/drivervault/phoneapp/car/. Two screens. The garage lists a car per row with its due badge on the second line, worst first, because the host renders only the first handful of rows and the car this list exists to mention is the overdue one rather than whichever was added first. A tap opens what that car has coming: the odometer, the next service, and the reminders the server holds for it — typed in and auto-derived from documents and the service schedule alike, in the order it sorted them. None of it is a second implementation of the app. VaultStore reads the session the phone signed in with — the active server's base and token — out of shared_preferences' own store, which both halves share, so a server switched on the phone is the server the car reads from with nothing to keep in step; only cc_active_base is new, because an untouched home entry carries no address of its own, its base being kDefaultApiBase, a compile-time define nothing outside Dart can see. CarStrings reads the same assets/i18n files by the same dot paths, so a badge on the head unit is the string format.dart already puts on the phone, in the language the account chose: of the 32 keys the car screens ask for, 28 are keys a phone screen already used, and only carApp.* is theirs. CarFormat is format.dart's twin — same date pattern and number grouping from the account's settings, same worst-of-date-and-km service badge. A new test reads the Kotlin for the keys it looks up and fails if any is missing from a language file, since the analyzer's reach stops at the Dart. It only reads. A screen you cannot type into is a poor place to edit a car and a driver is a poor person to ask, so VaultApi has no write in it to reach for by accident. Three things the README now says out loud. The service is declared IOT, the closest category the library defines for something that is a garage rather than a map or a media player, which matters to a store submission and not to a sideload. The app lock does not reach the head unit: the flag is in memory and the credentials behind it in encrypted storage, neither readable from the car service, and there is no fingerprint reader in a dashboard to satisfy it with. And the home charger is not on there — the chargers endpoint relays its plugin's payload verbatim with no shape to read, and the serial the control card is driven by is never persisted, so the car would have nothing to name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 5
|
12ec10a797 |
Phone App: more than one server, and a session for each
The web app can be pointed at two DriverVault stacks and switch between them in a click. The phone had one address and one session: reaching a second garage meant retyping the API base in Server settings and signing in again, losing the first server's token on the way — the same act, undone, every time you switched back. So lib/servers.dart is the web's servers.js ported rather than reinvented, down to the storage keys: cc_servers holds the list, cc_active_server the one being read, cc_session_<id> the token minted by that server and no other. The two apps describe the same thing the same way, and the upgrade path falls out of it — cc_token, cc_user and cc_server_url are read once at boot and folded onto the home entry, so the build carrying this signs nobody out. Home is the address the build ships with (kDefaultApiBase, still overridable per device from the login screen) and cannot be removed: it is what a dropped session falls back to. Any other server is added by address, with /api appended if the path is left off, because a server a phone can reach is internet-facing already. The part worth reading twice is which session a rejection ends. ApiClient no longer holds a base or a token — it pins the active server's id, base and token at the moment a request goes out, so a 401 arriving after a switch clears the session of the server that actually refused it rather than whichever one is active by then. The fallback is the web's: a remote server timing out drops its own token, the app returns to home while home is still signed in, and only when nothing is left to fall back to does the login screen come back. Log out still clears every server at once, since leaving the app means leaving all of them. Switching rebuilds the shell, keyed on the active id, because record ids belong to the server that issued them — a garage, a charging page and a settings panel still holding the other server's rows would each have to be told to forget them separately. The appearance prefs come across with the profile of whoever owns the account on the server now active. Where the picker lives is the one place the phone cannot copy the web. There is no app rail here, so it became the first button in the Garage header, beside the theme toggle and log out, which is that same cluster. It names the active server once there is a choice and goes straight to adding the second when there isn't; the eyebrow reads GARAGE · Work for the reason the rail names it — two garages otherwise look identical. The login screen gets its own way in, because a remote session can expire and land you there with that server still active, and a picker reachable only from inside the app would leave nowhere to go. One judgment call inside the sheet: saving a connected server at a new address saves and stops, rather than falling through to the sign-in it now needs. The token was minted by the PocketBase behind the old address and is dropped with it, but the credentials to replace it were never asked for, so treating the save as a login would report an empty password as the error. The strings are copied out of Web App/web/src/i18n/ like the rest of the shared wording. Two are not the web's: home reads "the address this app ships with" rather than "served with this app", since the phone has no origin to be served from, and sameOrigin has no meaning here at all and was dropped. Biometric sign-in stays global. It was never per-server and replays its stored credentials against whichever server is active; making it per-server is a change of its own, and the login screen now names the server it is about to sign into. Nothing changes on the API Server. On Android there is no origin to allow, so the CORS list the web app has to satisfy to reach a second server doesn't enter into it. Verified: flutter analyze is clean and flutter test passes, 35 tests to 46. The new ones cover the registry — a bare origin gaining its /api, a fresh install knowing one unnamed server on the built-in address, the legacy keys landing on home and being cleared, two servers holding their tokens apart, a rename keeping a session where a move drops it, removing the active server falling back to a home that is still signed in, home refusing to be removed, and a restart reading the list, the active id and every session back. Not verified: none of it has been run. There is no device or emulator on this machine and no API Server to answer, so the picker, the add sheet, a real connect, the 401 fallback and the shell rebuild on a switch exist only as code the analyzer is happy with — the tests reach the registry, not a screen. No APK was built. The legacy migration was exercised against mocked SharedPreferences, which is not a phone that had the old build on it: that is the first thing to check on a device, since the failure mode is a silent sign-out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 5
|
35e6c511b7 |
Changed parts: the list is the car's, not the app's
The Changed parts section offered all three parts to every car. An EV changes no
oil, and a checkbox nobody will ever tick is one more thing to read past on every
service — so which parts a car records now belongs to the car, the same way its
tabs, its Information rows and its Service history columns already do.
It works the way those three do because a fourth mechanism for the same idea
would be a fourth to keep in step: hidden_service_parts on the car, validated by
the endpoint that already does this, stored as the hidden set so a part added in
a later release is on by default, and needing write access because the choice
belongs to the car and everyone it is shared with sees it.
There is no order beside it, which is the one place this departs from the other
three. Those arrange things whose position means something — a tab bar reads left
to right, a table's columns are read across. The parts are a checkbox list inside
a single column, and moving Cabin air filter above Oil says nothing. Adding one
later is the same shape as the others if that turns out to be wrong.
A part switched off leaves the form and the history together — the chips on the
phone's cards, the web column's summary and the panel it opens. "I don't record
this" means it stops taking up room, not that it takes up room saying nothing,
which is the rule a hidden column already follows. That is the judgment call
here: a car with five years of oil changes hides them all by switching the part
off. Nothing is written to the records, so switching it back on brings every one
of those chips back, which is what makes the call safe to reverse.
The part that would have been a silent data bug: the API rewrites all three
booleans from the body of a service update, so a form that simply stopped
sending a hidden part would set it false on the next edit of any old record.
Both forms therefore keep every part in their state and submit every one — only
the checkboxes are filtered. The mirror of that is a *new* record, where a hidden
part starts false rather than at its `initial`, since ticking a box nobody was
shown is not a default, it's a guess. Oil is the only part with initial: true, so
that case is live the moment anyone hides it.
Verified: go vet and go test ./... pass, with a new test covering that every part
is hideable (unlike the tabs and the columns — a service that changed nothing is
a real service), that the "parts" column key is refused as a part key and a part
key as a column key, and that no part is also a column. flutter analyze is clean
and flutter test passes 32 to 35, the new ones covering visibleParts, that a
hidden part's chips go while its stored boolean stays, and the picker's fourth
section. npm run build is clean.
Both apps were driven against throwaway stub APIs. Web: the picker saved
{"hiddenServiceParts":["oil"]}, the table's parts cell went from "Oil & Oil
filter +2" to "Engine air filter, Cabin air filter", the record whose only part
was oil went to an empty cell, the panel dropped to two rows, the add form
offered two unticked boxes where oil's initial: true would have ticked one, and
editing the three-part record sent changedOil:true back with a box that was never
on screen. Phone: the same car rendered chips "Engine air, Cabin air", "Changed
parts —" for the oil-only record, and an add sheet with exactly two unticked
boxes.
Not verified: no automated test guards the web behaviour — the web app still has
no test runner, so the above was read out of the live DOM and the outgoing
request bodies by hand. The phone's picker was checked by widget test and by
rendering, but its Save was not driven end to end. Neither app was run against
the real API Server: bootstrap appends the new field on the next start, and until
that start a client sending hiddenServiceParts takes a 400 — they deploy together
from this repo, but the server must go first.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
tajniak81andClaude Opus 5
|
6b7abb4b84 |
Phone App: a service card laid out by the car's own columns
The Service history columns became a property of the car two commits ago, and
the phone was left out of it on the grounds that it has no table to arrange.
But the arrangement is not the table's — it belongs to the car, and everyone it
is shared with sees it. A reader who switched Oil off on the web still had it
on every card here, which makes the setting look broken rather than absent.
A card is not a table, so the columns cannot be cells. Consecutive short ones
share a wrapping line, which flows left to right and then down and so keeps the
arrangement intact; the parts, the notes and the file each take a line of their
own. That means the grouping follows the car's order rather than the
catalogue's — move Notes between Km and Next date and the short columns split
around it — which is the part a hand-written card gets wrong by collecting the
short columns first and appending the blocks after them, quietly undoing the
arrangement it was asked to honour. serviceColumnRuns is a function for exactly
that reason: it is the piece worth a test.
The date carries no heading where every other column does. A card list is read
down its dates, and "Date" in front of one says nothing the date doesn't — the
same judgment the server makes by refusing to hide it. It is offered in the
picker anyway, ticked and locked, because a row missing from that list is a row
nothing on this screen can drag; the web drags the column headings themselves,
which on a touch screen is the scroll's gesture. A column that is on but empty
says so ("Notes —") rather than vanishing: it was switched on deliberately, and
a card that silently drops it reads as a record that failed to load.
Changed parts arrives with it. Every part shares the one column — they are a
growing list and a column apiece would widen the web's table without end — and
lib/service_parts.dart is the twin of the web's lib/serviceParts.js, so the
form's checkboxes and the card's chips come from one list and adding a part is
one entry plus its boolean on service_records. The chips keep their own shorter
wording; the form keeps the web's, which is what stops the two apps naming the
same part differently.
Verified: flutter analyze is clean and flutter test passes, 22 tests to 32 —
the new ones cover that the arrangeable set is the hideable one plus the date,
that a field key is not a column key, that adding a part adds no column, the
run grouping, and a widget test of the picker showing the date's is the only
locked checkbox. The screen itself was driven against a throwaway stub API: a
default car renders date, Km, Next date, Next km, chips, notes and file in that
order, and a car hiding km and file with the order [notes, date, nextKm, parts,
km, nextDate] rendered exactly that — notes first, both hidden columns gone, the
short columns split around the chips. updateCarView round-trips both new fields
under the names records.go decodes.
Not verified: the picker's own Save button — the tap landed in the harness but
the request never reached the stub, which reads as the fire-and-forget future
being cut off at teardown, since the same call made directly worked. Drag was
exercised through the reorder callback, not by a finger. Nothing here needs the
API Server to change: both fields already ship, and a phone running against an
older one simply reads empty lists and shows every column.
Two commits needed nothing: the web's masked date box answers <input
type="date"> rendering in the browser's locale, which a picker-only field
cannot have, and the garage card's width answers a badge that wrapped, which
this badge cannot. car.services.next goes, its prose replaced by the columns
that now say it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
tajniak81andClaude Opus 5
|
e5759df52c |
Say how far the next service is, not only how long
The service badge has always watched two triggers - the next-due date and the next-due odometer reading - and shown one of them. It ranked the two and printed the worse one's sentence, so a car comfortable on both read "OK · 354d" and never said that the odometer target was 13.612 km away, even though the Information card right under it prints the 15.000 km the badge is counting towards. Whichever trigger arrives first ends the interval, so naming only one of them describes half the thing. Both are named now. With both signals known the label is a severity headline followed by each trigger as a bare quantity - "OK · 354d · 13.612 km", "Due in 12d · 13.612 km" - which is the shape reminderStatus in the same file already uses, it having had the two-trigger problem first. The signals gained the number behind their own wording to make that possible; they were returning only a formatted sentence. Wording is unchanged wherever only one signal has data, which is the case this rewrite most risked disturbing: a car with no odometer target still reads "OK · 354d" exactly as before, one with no service date still reads "13.612 km left", and neither still reads "No data". The new keys are only reached when there are genuinely two numbers to print. An overdue badge lists only the triggers that have actually passed. "Service Overdue 30d · 13.612 km" would read as overdue by 13.612 km, which is the opposite of what that number means, so the trigger that is still comfortable stays out of a sentence headed "Overdue". It costs the remaining distance on a date-overdue badge; the alternative costs the reader's trust in the number. The phone carried a line-for-line copy of this logic and gets the same treatment rather than being left a version behind - the two would otherwise disagree about the same car on the same day. Its signals become a private record type, since Status is public and shared with the expiry, reminder and warranty badges that have no second trigger and no use for the field. Two new keys (status.okIn, status.serviceOverdueBy) in all three languages in both apps. The day and km fragments they interpolate were already translated for the reminder badge, so the parts assemble in Polish and Danish without new wording: "OK · 354 dni · 13 612 km", "OK · 354 d · 13.612 km", each with its own grouping separator. Verified by flutter analyze (clean), flutter test - 21 pass, including the key-parity test that would have caught a key added in English alone - and npm run build for the web. The web function was driven through the real module in a browser over ten cases: both signals known at each severity, each of the two overdue alone, both overdue together, either signal missing, neither, and a zero-odometer car, in all three languages. Not verified: no new automated test covers this. The web app has no test runner and the phone's format tests cover the catalogue lookups rather than the badge, so the ten cases above were checked by hand and are not guarded against the next edit. The deployed Web App still serves the previous build and will keep reading "OK · 354d" until it is redeployed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 5
|
4372b870ac |
Phone App: take the admin users screen off hardcoded English
The last screen the phone rendered in English regardless of the language
picker. Its strings are the web AdminUsers.vue's, which have been translated
since
|
||
|
tajniak81andClaude Opus 5
|
a2d9efec7e |
Phone App: take the car screen off hardcoded English
The previous commit left the car screen half translated: its tab labels went
through t(), and everything underneath them did not. A Polish user opening a
car got translated tabs over English tiles, English forms and English
dialogs, which is worse than either extreme because it reads as a bug rather
than as a missing translation.
So the whole screen and everything it opens now reads from the language
files: the record tiles, the share and delete-car dialogs, the service and
part sheets it hosts, record_form_sheets.dart, car_form_sheet.dart, and the
attachment field whose buttons surface inside all of them.
Almost none of these strings are new. The Web App has said all of this in
three languages since
|
||
|
tajniak81andClaude Opus 5
|
e249c2f4d8 |
Phone App: connected service, charging cost, a tab picker and data export
Both READMEs claimed web parity with data export/import as the only
omission. That was three gaps out of date: the car screen had no
connected-service tab, no per-car charging-cost tab, and no way to say what
a car's page shows - all three of which the web has had since the car view
became a property of the car rather than of the browser.
The tab bar was the thing blocking the rest. It was a fixed list of eight
Tab(text: "Information") literals, so it could neither grow a tab nor read
an arrangement, and it sat outside the translation system that the rest of
the app has used since
|
||
|
tajniak81andClaude Opus 5
|
cd16d4383f |
Orgs: let any user create an organization and become its admin
Organization writes were superadmin-only, so standing up a tenant needed an out-of-band superadmin. Creating one is now self-service, and an admin manages the org they belong to. - POST /api/orgs is open to any authenticated user. A creator who isn't a superadmin must have no organization yet (a single-valued membership relation means a second one would abandon the first), and is promoted to the new org's admin and first member in the same request. If that promotion fails the org is rolled back, so it is never left stranded with nobody able to administer it. Superadmins still create tenants without joining them. - PATCH/DELETE are manager-gated and scope an admin to their own org. An admin deletes theirs only as its sole member: they are detached and demoted to a plain user before the record goes, so the org is empty when it is removed. Other members still block deletion with a 409. - /api/me now carries organization + organizationName, which the clients need to tell "no org yet" from "org you administer". The panel, Web App (new OrgManager.vue in Settings) and Phone App (new _OrganizationSection) all mirror the server's gates rather than re-deciding them. The Phone App cached its role at login and gates the Users tab on it, so AuthService.adoptRole refreshes that from the profile instead of making a freshly promoted admin sign in again. Covered by orgs_test.go, which drives the real handler + middleware chain against a stand-in PocketBase: promotion, the already-a-member refusal, superadmin staying unattached, the rollback, own-org scoping, the detach-and-demote, and the blocking-member 409. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 4.8
|
13f50aa9a4 |
Phone App: add Charging screen + Settings integration tabs
Brings the Flutter app to parity with the recent Web App changes, which touched features the Phone App did not yet have — so this builds the Charging and Integrations subsystems, then applies the tab/fold structure. Charging (new nav destination): split into "Public chargers" (stylized discovery map + demo session + nearby public stations) and "Home chargers" (the real Anker Solix OCPP control card — serial refresh, connector/energy tiles, start/stop, current limit, password step-up on reset — plus the user's home charger list). Gated by the per-user control mode, degrading to a Settings hint when off. Settings: split into "Personal settings" (the existing account/appearance/ profile/security/privacy/danger sections) and "Integrations". The latter holds foldable Toyota and Anker Solix cards over the superadmin -> org -> user cascade: locked fields with "inherited from" notes, org-admin scope switch, enable toggle, save/test with health result, and Anker OCPP token provisioning. Both tabs stay mounted (IndexedStack) so in-flight edits survive a switch. Adds the integration + OCPP control endpoints to api.dart, the resolved IntegrationView/Scope/Field, IntegrationHealth and AnkerControl models, and charging.*/settings.tabs.*/nav.charging strings (en/pl/da) plus settings.integrations.* (en) — mirroring the Web App's own pl/da coverage, which leaves integrations and charger control untranslated as an English fallback. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
tajniak81andClaude Opus 4.8
|
b6bb6b1df0 |
Add a language-switch system with per-language files
Introduce a hand-rolled i18n layer across all three UIs, each reading its
text from per-language JSON files (English base + Polish + Danish). Nothing
in the converted screens hardcodes English any more.
- Web App (Vue): src/i18n/{en,pl,da}.json + index.js exposing t()/tSplit(),
reactive to the signed-in profile locale. Every view, component, form and
the status labels in lib/format.js go through t().
- API Server panel (Vue): src/i18n/ with its own localStorage-persisted
language (the panel has no user profile) and a header language picker.
Chrome, cards, login and API section titles translated; endpoint reference
descriptions intentionally kept in English. Rebuilt embedded dist.
- Phone App (Flutter): assets/i18n/ + lib/i18n.dart loaded at startup,
driven by AppSettings.locale. Nav, login, lock, dashboard, the full
Settings panel (incl. language picker) and format.dart status labels
translated; remaining detail screens fall back to English.
Language = the language half of the existing BCP-47 locale; the region half
still drives date/number/currency formatting. Missing keys fall back to
English, and plurals use Intl.PluralRules / Intl.plural so Polish gets the
correct one/few/many forms. Settings flags languages without a translation.
Tests updated to assert the localized (Polish) status wording; all pass.
See TRANSLATIONS.md for the format and how to add a language.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|