mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
2c333cb643d74ac590ef7c538c3d3ba30c57a92d
987 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Maurice
|
06b7f3e690 |
feat(weather): answer for the hour when a past entry carries one
A journal entry made at 14:30 wants the weather of that hour. The archive path only ever asked for daily figures, so it answered with a rainy morning and a bright afternoon averaged into one number (#1614). With a time in hand it now asks for the hourly series as well and reads that hour, falling back to the daily figures when the hour has no reading — an archive gap must not turn into no answer at all. An unparseable time is treated as no time rather than as midnight, which would have been a confident wrong answer. The cache key carries the hour, so the two do not shadow each other. Nothing changes for callers that pass no time, which is every existing one. |
||
|
Maurice
|
6e4fda897f |
refactor(journey): stop pulling trip photos into journeys
Photos live in journeys (#1614). Linking a trip used to copy its trip_photos rows into the journey gallery, which is how a photo one member had chosen not to share could reach a journey at all — PR #1967 filtered that at the door, and this removes the door. Nothing is lost by it: the trip-photo surface lost its UI in 3.1.0, so nothing writes to trip_photos on an install newer than that, and the client calls none of its routes. The table and those routes stay for one more release rather than being dropped in an append-only migration; the read paths keep working for installs that still hold rows. |
||
|
Maurice
|
56b4509b03 |
feat(journey): put photos on the map where they were taken
The visible half of the capture-metadata work (#1614). Photos that know their coordinates are drawn as thumbnails on the Journey map, in the shape the report asked for: a picture rather than an abstract pin, and a count when several collapse into one. Clustering is a screen-space grid rather than a library. The Journey maps have never had clustering, and the one the planner uses hangs off react-leaflet while this map drives Leaflet directly; bucketing by rounded pixel position is a few lines, is deterministic, and does the job — photos of one place collapse into one thumbnail with a count, and pulling the map apart separates them again. The layer sits below the entry pins, because the itinerary is the point of the map and the photos are context. Its own effect, so photos arriving do not tear down and rebuild the map the way the entry effect does, and redrawn on zoom and pan because the buckets are in screen space. The thumbnail URL is built in the page rather than the hook: it needs the share token, which is the credential the byte proxy checks. Also re-points the trailing-migration guard at the new last slot, which is what its own comment asks of anyone appending one. |
||
|
Maurice
|
11686be264 |
feat(journey): let a shared journey read newest-first
A journey shared while the trip is still running is read like a blog: the family following along wants the latest entry at the top, not to scroll past three weeks to find it (#1614). The owner sets it per share link, because it is a property of how the link is meant to be read rather than of the journey, and the reader can flip it either way. Off by default, so an already-published link does not reorder itself under its readers. Only the reading order changes. Day colours and stop numbers stay chronological, so the timeline still matches the map when the feed is upside down — which is why the day index is looked up rather than taken from the render loop. Reuses memories.newest/oldest, already translated in all 23 locales. |
||
|
Maurice
|
97220b72f6 |
feat(journey): carry capture metadata into the payload, and keep it behind share_map
The gallery rows now hand the client taken_at, lat and lng, which is what the map and a capture-ordered gallery will read. The coordinates needed a projection before they could ship. A photo's capture location is a place the owner never typed and may not expect to publish, so it follows share_map — the same switch the entry coordinates already follow. Without that, turning the map off and leaving the gallery on would have handed out exactly the locations the owner had just withheld. The capture time is not a location and stays either way; a blog-style view sorts by it. |
||
|
Maurice
|
d2cf694882 |
feat(photos): read the EXIF of an uploaded photo
Closes the third source of capture metadata (#1614). Provider photos are asked for, uploaded files carry their own answer — and until now nobody read it, so the most common case of all, a photo taken on the trip and uploaded straight into the journey, could never appear on the map. exifr rather than a heavier image library: pure JS, no native build, so no musl-pin dance in the Alpine image. Only four tags are picked, so a large file is not fully parsed. The resolved path is checked against the uploads root before it is opened. One thing worth knowing before someone files a bug about it: the client converts HEIC before upload and that conversion drops GPS, so an iPhone photo arrives here already stripped. Nothing to read is the expected outcome more often than not, which is why the empty case is silent. |
||
|
Maurice
|
359c3afc21 |
feat(photos): ask the provider where and when, and stop the album path dropping it
Second half of the capture-metadata foundation (#1614). The album paths were the asymmetry: Immich's search has always carried exifInfo.latitude/longitude, but the album mapping quietly left them out, and the Synology album listing never asked for the gps block at all. So a photo picked out of an album could never be placed on a map, and the distance sort that PR #1632 added silently had nothing to sort by. Both now carry the pair. For the add itself the client only sends an asset id. Widening that contract would have meant trusting the client for something the provider can be asked for directly, and would have left the MCP path and every already-imported photo without it — so PhotoCaptureBackfillService asks afterwards instead, detached, skipping rows that already know both so an album import is not one provider call per photo. A slow or unreachable provider cannot hold up the add, and a photo without capture metadata stays the normal case. |
||
|
Maurice
|
6185cf96b6 |
feat(photos): record when and where a photo was taken
The foundation the Journey map needs before photos can sit on it by their own coordinates, and the gallery before it can order by when a picture was taken rather than when it happened to be added (#1614). Three nullable columns on trek_photos plus a partial index over the coordinate pair; a photo with neither is the normal case, not a failure. recordCaptureMetadata merges rather than overwrites, for the same reason recordLocalThumbnail does: the sources disagree about how much they know. A provider search answers with coordinates, the same provider's album listing does not, and a local file gives them up only once its EXIF has been read. Whichever arrives first wins, and a later, emptier answer must not blank it. Coordinates are stored as a pair or not at all — half a pair is not a place, it is the null island. |
||
|
Maurice
|
3e4b36ac71 |
fix(weather): give the Open-Meteo calls a deadline
All six outbound calls ran without an AbortSignal, so a hung connection held the caller until the socket gave up on its own. Every other outbound client in the codebase carries a timeout; this one is the reference domain and did not. |
||
|
Maurice
|
630e8efca1 |
fix(journey): stop unshared trip photos leaking into journeys, and gate the link
Two things found while reading the domain for discussion #1614. A photo a trip member left unshared is denied on the trip path — memories-access requires tp.shared = 1 — but linking that trip to a journey copied every row of trip_photos into the gallery regardless. From there it was readable by every journey contributor, and with an open gallery by anonymous visitors of the share link. journey_photos.shared cannot gate that after the fact: a direct upload writes 0 into the same column, so filtering on it would empty most galleries. The fix is at the door instead — only shared rows are copied in. addTripToJourney checked that the caller could reach the trip but never that they could reach the journey, so any logged-in user could link a trip of theirs into a stranger's journey and seed skeleton entries and photos there. The MCP tool has always checked this; only the REST route was open. Now the service checks it, which covers both and the internal call from createJourney. Neither path had a test. They do now. |
||
|
Maurice
|
28765e220b |
fix(places): keep the Google feature id, and give list imports the free address lookup
Two halves of #1954, both about a place arriving through a list coming out thinner than the same place pasted as a single link. The feature id was never dropped on purpose. googleFtidFromMapsUrl only looked at the `?ftid=` query parameter, while a share link that resolveGoogleMapsUrl has followed to its final hop carries the id in the `data=!…!1s0x…:0x…` path blob — the same run the coordinates are already parsed out of two lines further down. So every pasted maps.app.goo.gl link lost it, and the Maps button opened a name search rather than the entry the link pointed at. The parser now reads the blob too, but only on a /place/ URL: a /maps/dir/ route carries one !1s per waypoint and the first is the origin, which would attach the wrong place. List imports never had a reverse lookup at all. The only pass behind them is the Google enrichment, which returns immediately without a Maps key, so an instance without one imported a list and left every address empty forever. They now get the same free Nominatim lookup the single-link path has always had: detached after the import answers, on the throttled background lane so it never queues in front of someone's search, through COALESCE so it can only fill an empty column, and each row pushed over the websocket so the sidebar fills in without a reload. Capped at 250 places — past that it stops being a backfill and starts being bulk geocoding. Not included: an osm_id for imported places. Single links do not produce one either, and one derived from a zoom-18 reverse lookup would name the building or the street rather than the POI. |
||
|
Maurice
|
02f7320c90 |
fix(mcp): name the route profile keys the router actually accepts
Both tool descriptions offered "transit" as an example. RouteCalculator only knows driving, walking and cycling plus the plugin:<id>/<profile> form, and maps anything else to driving when it draws the route, so an agent that set "transit" got a success and a car route with a car icon. Name the real keys and say plainly what happens to anything else. The incoming-leg test used "transit" too. It now uses walking, and the outgoing test seeds the incoming column first, so its "must not touch incoming" assertion proves something the factory did not already give it. |
||
|
Ida Rogalska
|
e375f9e002 |
feat(mcp): add set_day_default_transport_mode tool
Wrap DaysService.setDefaultTransportMode behind an MCP tool, mirroring the days/:id/transport REST route. Adapter only; per-segment leg modes still override the day default. |
||
|
Ida Rogalska
|
03f3c5ae36 |
feat(mcp): add set_leg_transport_mode tool
Wrap the existing per-leg transport setters (outgoing + incoming) behind an MCP tool so leg modes no longer need a raw DB write. Adapter only, no new business logic; mirrors the assignments/:id/transport REST route. |
||
|
michael-bohr
|
55aef8d55c |
fix(tests): generate trip days in UTC so a DST shift can't drop or repeat one
The test trip factory parsed date-only ISO strings as UTC midnight but stepped the cursor with setDate(), which advances local wall-clock time. Across a DST transition that step is 23h or 25h, so the instant drifts off midnight and toISOString() reports the wrong day — a day is dropped in autumn and repeated in spring. TRIP-SVC-015 already builds a trip over 2025-11-01..2025-11-03, which straddles the US fall-back, and fails on any machine in a DST-observing zone: AssertionError: expected [...] to have a length of 5 but got 4 CI runs UTC, where the loop happens to be correct, so this is invisible there and only bites contributors running the suite locally. Full server suite: 396 files, 7550 tests, green. |
||
|
Maurice
|
84d9fbff3c |
fix(scripts): rotate the instance-wide provider keys too
#1939 moved the Google Places and Unsplash keys into encrypted app_settings rows, but the rotation script walks a hardcoded list of app_settings keys and the two new ones were not on it. Rotating ENCRYPTION_KEY would have left them encrypted under the old key, which reads back as null and silently drops the install to OpenStreetMap with nothing in the log to say why. users.unsplash_api_key was missing from the users column list for as long as the column has existed. It matters now that the resolver reads that column as the per-user fallback, so it goes in at the same time. The script cannot import the canonical list, since it deliberately runs without config.ts and without the container, so the copy is pinned by a parity test that reads the script and fails when a name is missing from the app_settings loop. Wiki: the rotation page listed the Maps key as per-user and did not mention the app_settings rows an operator now has to carry across. |
||
|
Maurice
|
1e166ab0d9 |
test(server): raise the coverage floor for the four domains this branch covered
Measured values with a point of slack, from scripts/coverage-thresholds.mjs: atlas, audit, settings and unsplash all gained cases here. Only those four. The script prints a block for every domain, and taking it whole would have lowered src/nest/auth lines from 96 to 95 and tightened domains this branch never touched, which would fail the open PRs for no reason. unsplash is the one that needed the work rather than just recording it: dropping the "any admin's key" fallback removed covered branches, so the parse-failure ternary that was already uncovered started dominating the ratio and the gate failed at 80.85% against a floor of 82%. Covered it instead of lowering the floor, which put branches at 89.36%. |
||
|
Maurice
|
0a7e460253 |
fix(planner): keep a parked car off the days between drop-off and pickup
A parking booking spanning the trip showed up on every day, sometimes in between planned activities. It now appears on its first and last day only, with drop-off and pickup wording, and contributes nothing to the days in between, not even a badge in the day header. Applied to the day plan, the mobile timeline, the PDF export and the shared trip view, so a shared link shows what the app shows. Rental cars stay as they are. The report names the car's smaller tag as the thing it does not want for parking, not as something to change, and a car's middle days move into the day header, which is what people expect from a vehicle they are driving around. The distance connector between legs is keyed off the row that gets hidden, so hiding it naively takes the "2 km" label with it, which is what #1504 was about. There is a test that fails without that guard. Each segment of a stopover flight or train can also carry its own booking reference now, since airlines often issue one per flight rather than one per booking. Legs already live as a JSON array on the reservation, so this is an optional field per entry: no migration, no contract change, and a booking without it renders exactly as before. Readable everywhere it can be entered, desktop and mobile, through the same blur treatment other booking codes get, plus the PDF and the calendar description. create_transport and update_transport preserve it too, otherwise they would accept the field and silently drop it. Closes #1937 Closes #1943 |
||
|
Maurice
|
54693474f1 |
fix(atlas): stop counting a connection airport as a country visited
The role IN ('from','to') filter from #1486 is correct and still in place, but it
cannot see the case this issue actually reports. Joining AirTrail legs into one
booking with a layover stop is opt-in, so legs imported separately store the hub
as the legitimate `to` of one booking and the `from` of the next, which no role
filter can tell apart from two real arrivals.
Pair them where the countries are counted instead: an arrival and a departure at
the same airport, in different bookings of the same trip, within 24 h of each
other are a connection, and neither endpoint counts as reached. 24 h is the same
window the importer already uses to chain same-PNR legs. Doing it on the read side
means the databases that already hold these flights heal on the next request.
Only flights pair, and never cancelled ones, so a rental car picked up at the
airport still counts its country (#1366). A booking that returns to where the
chain started is a return flight, and that check compares distance rather than
airport identity, so flying home into a different airport of the same metro area
does not erase the country you spent the day in. A country with a place logged in
it, or marked by hand, is untouched.
Closes #1535
|
||
|
Maurice
|
1a0834b866 |
fix(maps): resolve the Places key per instance, not per whoever is asking
Searching worked for the admin and 403'd for every other member. getMapsKey read the calling user's own row first and then fell through to "any admin" via LIMIT 1 with no ORDER BY, so the admin who pasted the key hit their own row while everyone else got a non-deterministic stranger's. That fallback is what CLAUDE.md forbids. The Places and Unsplash keys bill the install, not the account that pasted them in, so they become instance configuration: an encrypted app_settings row, resolved as env -> instance -> the caller's own row, the same shape #1772 chose for the LLM endpoint. The per-user column stays as the last step because /me/api-keys has always accepted a personal key. The trailing migration carries an existing install's key into the instance row so nothing degrades to OpenStreetMap on upgrade, but only where that key already was the whole install's: as soon as a second row holds one, it is left alone, because the instance row outranks everybody's own column and an upgrade must not move a member onto someone else's key and bill. Two things from the same report: The key test button probed with field mask places.displayName while the search asks for places.rating and more, which is a separate SKU and can be restricted on its own, so the button could pass while every search failed. It now probes the resolved key with the search's own mask. Saving API keys wrote no audit line. It now writes one settings.api_keys_update row naming which fields changed, never their values, comparing cleartext because the random IV makes every ciphertext look different. Closes #1939 |
||
|
Maurice
|
c9124c9b63 |
fix(places): only attach tags owned by someone on the trip
A tag belongs to a user, not to a trip, and the place create/update body is an open record the Zod pipe does not police — so any tag id could be attached, and the tag projection ships tags.user_id, which answers who owns a tag the caller has no way to see. collection_place_tags had it verbatim. Scoped to the roster rather than to the caller on purpose: a member tags a shared place, another member re-saves it and, because the update is delete-then-insert, sends that id back. Caller-scoping would drop a co-traveller's tag on every foreign edit; roster-scoping keeps it. Collections resolve the same question through their own member list. No client sends a tags array today, so this only closes the hand-crafted path. |
||
|
Maurice
|
244eb56e4c |
fix(budget): confine payers, split members and settlement parties to the trip
knownUserIds asked whether a user exists at all, not whether they are on this trip, so any id on the instance could be made a payer or a split member. Both read-backs join users, and the settlement projection carries the avatar through avatarUrl, which passes an absolute URL straight out — for an OIDC account that is the picture claim. Payers and split members drop off-roster ids, as before, only against the right set. Settlements cannot: they name exactly two parties and both columns are NOT NULL, so dropping one would either break the constraint or move money to the wrong person. Both wrappers refuse the write and return null, which lands on the 404 the update path already had. That answer is deliberately the same one a missing settlement gets, so the endpoint says nothing about whether an id exists — and it retires the foreign key error that used to surface as a 500 and drew exactly that distinction. createSettlement grows the 404 its sibling had; the MCP tool reuses the error string already at hand. Money rules are untouched: a settlement is a transfer, so refusing one cannot unbalance the sum, and the cent arithmetic is unchanged. |
||
|
Maurice
|
0337ebbbd2 |
fix(assignments): confine day participants to the trip roster
setParticipants took the ids on trust. The caller is proven to be on the trip and the assignment is proven to sit on it, but nothing said the same about the ids in the body, and the read-back joins users — so a stranger's name and avatar came back to the writer and went out over the assignment:participants broadcast to everyone else in the room. Takes the tripId both callers already hold and filters against the roster. Same drop-rather-than-reject rule as bag members and reservation travellers: the participants box posts the whole list on every edit, so a trip whose membership changed underneath it would otherwise be stuck. ASG-SVC-028 covered a foreign key error rolling the replace back. The filter takes an unknown id out before the insert can reach it, so that path is gone and the case now pins what happens instead: a list of nothing but strangers clears, like the empty list ASG-SVC-018 already pins. |
||
|
Maurice
|
1eb29f8b77 |
fix(trips): confine assignee writes to the people on the trip
Holding packing_edit or todo_edit says you may edit this trip's lists, not that any user id you name belongs to it. Both updateCategoryAssignees loops wrote the body's ids straight through, and both end by re-selecting through a JOIN on users — so an id from anywhere on the instance came back with a display name and an avatar attached, in the response and in the WebSocket fan-out to the room. The packing item recipient writes had the same gap. packing already had tripRosterIds for exactly this and used it only for bag members; its doc comment said "assigned to a bag", which is probably why the other three writes grew up without it. The query moves to DatabaseService next to canAccessTrip, which asks the same question as a predicate, and the helper now delegates. Every service that needs it already injects DatabaseService. Off-roster ids drop rather than 400: a copied trip carries assignee ids over before its members exist, and rejecting the whole request would stall the picker there. Guests are unaffected — a guest is a trip_members row, so the roster includes them, which is the point of #1362. |
||
|
Maurice
|
c8607ba234 |
fix(places): pin the image and website URL fields on the way in
image_url and website were bare strings in the contract, and the create/update bodies are open records, so the Zod pipe never looked at either. Both leave the database for something that treats them as a URL: the thumbnail is interpolated into hand-built marker HTML, and the homepage is handed to window.open, where a javascript: value would run in this origin rather than opening a page. Both are allow-listed on the way in now, next to hexColorSchema and checked in the handler the way validateRouteColor already is, on all three write surfaces so REST, the plugin RPC and MCP agree on what they accept. The entity schemas stay open: rows written before this still have to round-trip. safeHttpUrl covers the read side for exactly those rows, the same split safeHexColor uses, and the window.open calls it guards pick up noopener,noreferrer while they are being touched. |
||
|
Maurice
|
0f0bf50cd3 |
fix(assignments): guard the per-assignment routes like the day routes
AssignmentOpsController declared @RequirePermission('day_edit') on its
mutations but carried only JwtAuthGuard. TripAccessGuard is what reads that
decorator and what resolves :tripId, so on this controller the permission
markers were metadata nobody looked at and the trip in the URL was never
matched against the caller. Its sibling, DayAssignmentsController, has had the
pair since the migration.
The two participants handlers also went straight to the service with the id
from the path, unlike move/time/transport, which ask getAssignmentForTrip
first. They ask now too.
|
||
|
Maurice
|
ff27624e02 |
fix(reservations): scope the per-day position write to the trip
updatePositions has two branches. The legacy one updates `WHERE id = ? AND trip_id = ?`; the per-day one, three lines below it, bound the caller's ids straight into reservation_day_positions and never touched the tripId it was handed. That table has no trip_id of its own and its two foreign keys only require the ids to exist, so nothing further down caught a pair that did not belong together. The trip now comes from the join, so the row materialises only when the reservation and the day agree on it. Doing that in the statement rather than as a pre-check also turns a stale id into a quiet no-op instead of a foreign-key error surfacing as a 500, and lets an omitted day_plan_position bind the way the wire contract has always said it may. reorder_reservations reports a day that is not on the trip, the way its sibling tools in that file already do, and a migration clears rows whose reservation and day disagree. |
||
|
jubnl
|
b1e4c830b2 | fix(immich): strip leading / in immich url (#1948) | ||
|
jubnl
|
2bffee8fd4 | fix(auth): preserve remember-me when password change re-issues the session (#1927) | ||
|
jubnl
|
72221a2e45 | feat(auth): sliding session renewal past half the token lifetime (#1927) | ||
|
jubnl
|
61e03fdfde | feat(oidc): honor remember-me in SSO login (#1927) | ||
|
Maurice
|
3a0604b3f5 |
feat(config): put the operator-owned surfaces behind TREK_MANAGED (#1946)
* feat(config): put the operator-owned surfaces behind TREK_MANAGED The switch landed last release with nothing behind it. This is what it turns off, plus the four fixes that came out of walking every one of these surfaces. Nothing here changes anything for an install that does not set the flag. That is not a hope, it is what managed-inert.test.ts asserts: the mode stays off for any unparseable value, no other variable can turn it on, every settings key stays writable, and splitManagedKeys hands back the same object rather than a copy so no write path can quietly diverge on self-hosted installs only. WHAT THE MODE WITHHOLDS Fourteen routes carry @ManagedForbidden: key validation, static MCP tokens, JWT rotation, the OIDC admin pair, restore and auto-backup, plugin sideload and reload, the Ollama model list and pull, and the SMTP test send. Each names the reason it is not the instance admin's, and the reason is mandatory. Eighteen settings keys are filtered instead of refused. SMTP, the OIDC toggles and the WebAuthn pair share one handler with keys the admin does own, and the llm_* family is reachable through per-user settings, the instance defaults and the addon config alike, so a route-level refusal would be both too coarse and incomplete. A locked key is skipped and reported as managed_keys; the rest of the save goes through. Refusing the request would take the registration toggles down with the SMTP block. GET /api/auth/me/settings stops returning the three API keys in the clear. It is the only endpoint that decrypts a stored credential back to the caller, which is fine when the admin pasted it in and wrong when the operator supplied it. Two multipart routes check in the handler rather than the guard: a guard throws before the parser drains the body and the client gets an ECONNRESET instead of the 403 (PROFILE-015). They still carry the marker so the boot gate sees them. WHAT KEEPS IT FROM DRIFTING validate-managed-routes.ts refuses to boot on a marking that is not on the reviewed list, a list entry whose route lost its marking, or a marking with no reason. The third case has no equivalent in the guard gate next door and is the one that matters most: a blank reason destroys the only record of why a control was taken away, and nothing recovers that later. It found two wrong entries in my own list while I was writing this. managed-keys.test.ts asserts that every key in ADMIN_SETTINGS_KEYS and DEFAULTABLE_USER_SETTING_KEYS belongs to exactly one of two sets. A key added to either list belongs to neither until somebody decides, and that is the failure this prevents: the lists grow, the mode does not. PLACES_API_BASE AND PLACES_API_KEY The nine Places endpoints spell out googleapis.com, so an install that wants those calls to leave through something of its own has no way to say so. One variable, substituted where every call already funnels through. A second one supplies the key, and when it is set the users table is not consulted at all — a per-user key would route around whatever the endpoint counts, and those columns are readable by any admin of the instance. FOUR FIXES THAT ARE NOT ABOUT THE MODE An admin setting somebody's password now bumps password_version and clears their MCP tokens. An admin sets a password for one reason, and until now verifyJwtAndLoadUser kept accepting every cookie the intruder already had: the one action taken to lock them out was the one action that did not. The four OIDC provider calls go through the SSRF guard. Three are worse than they look — the token, userinfo and JWKS URLs come out of the discovery response, so they are chosen by the other end, not by an admin. safeFetchLlm is renamed safeFetchAdminConfigured and keeps its old name as an alias, because it is the variant that allows loopback and LAN: a self-hoster with Authentik on localhost:9000 must keep working. The token exchange follows no redirect at all, since one would hand client_secret to a second host. DELETE /api/admin/users/:id/mfa clears another account's TOTP. The passkey half has existed since passkeys landed; the TOTP half never did, which left "somebody on the trip lost their phone" with no answer short of an operator in the database. Never for the caller themselves. TREK_PLUGIN_PERMISSIONS=off refuses to boot when the install is centrally administered. A warning is right for a machine its owner chose to trust; where the person who set the flag and the people whose data is in the database are not the same person, fail closed. TEXTS Four strings lose the phrase "self-hosted" because they describe somebody else's software — an Ollama endpoint, an AirTrail instance, a service a plugin talks to — and read better without it in both modes. The one string that describes TREK itself keeps it, and the mode picks a second key instead, so self-hosters lose nothing. A grep gate in shared/ keeps the canonical locale honest, because the parity check compares the file set and the top-level keys and never looks at a value: re-wording a string is invisible to CI today, and so is putting it back. * feat(maps): supply the map credential with the instance when centrally administered MAPBOX_ACCESS_TOKEN joins PLACES_API_KEY as an operator-supplied value. SettingsService injects it when the settings are read, and picks GL as the provider if the reader is still on Leaflet, since a token is always present. The key moves from the customer set to the locked set. It is the one locked key whose value is public by design — a pk.* token has to reach the browser to be useful — so this is not about secrecy: a per-user save landing on top of the instance token would only break the map for that user. Both settings fields for it go away with it. * fix(auth): count the operator key when reporting whether Google features work has_maps_key only looked at the users table, but getMapsKey prefers the PLACES_API_KEY env over anything stored there. On an install that supplies the key that way and has an empty column, every lookup worked while the client was told there was no key and hid the search, the autocomplete and the place photos. Found by walking the running instance rather than the code: the map came up, the search box did not. * feat(admin): hide the settings a centrally administered install cannot act on A control that answers 403 is worse than no control: the AI section rendered the refusal as "Request failed with status code 403", which tells an admin they broke something rather than that the decision is not theirs. So the surfaces go rather than being disabled in place: - AI parsing and AirTrail leave the addon list, and the AI addon route now refuses outright. The endpoint, the model and what a document costs come with the instance, so there is no instance decision left — not even whether it runs. - Immich and Synology Photos leave it too. Both connect to a server the reader runs at home, and there is no route from here to one. - The SMTP block, the admin webhook and ntfy targets, and the passkey RP ID and origins follow the same rule: they configure something the operator owns, and a wrong RP ID on a shared parent domain reaches past this instance entirely. - The About tab goes. It is about the project — what TREK is, where to file a bug, where to support it — and is aimed at the person running the software. The version and the link to the source move to the sidebar footer, on both the desktop page and the mobile twin, because AGPL 13 wants that offer wherever people reach the software over a network. - The update check stops asking GitHub and reports nothing available. Separately, the version footers lose the "self-hosted" suffix everywhere, not just here. It read as a label on the software rather than on the install, and the version alone says what it needs to. * feat(config): refuse to boot centrally administered without an at-rest key Measured on a running instance rather than assumed: with ENCRYPTION_KEY unset, the at-rest key falls back to a file in the data volume, and backupService bundles that file into every archive it builds. The archive is downloadable by any instance admin, so the encryption ships with its own key in the same zip. The skip in backupService already handles this — it only omits the file when the key came from the env — but nothing made sure the env actually carried one. Provisioning sets it; forgetting it was silent. validateEnvAtBoot now carries a second kind of check next to the schema: cross- field rules that only apply with the flag set, for combinations where every value is individually valid and the result is wrong. Empty without the flag, so an install that never asked to be centrally administered cannot meet it. * feat(client): add an attachment point for install-specific screens Two empty exports on the client, an empty module on the server, and the four places that read them. Nothing here adds a route, a nav entry or an endpoint — the arrays are empty and the module contributes nothing, which managed-ext.test pins so it stays that way. Read unconditionally, never behind a flag. On the server a conditional import would tie the module graph to an environment variable, and the graph is built once per app while the flag is read live; on the client an empty array costs nothing to spread, so every build walks the same path instead of one build walking a path nobody tests. Anything attached here follows the same rules as the rest of src/nest and src/components: a real module with a controller and a provider, bodies through the Zod pipe, routes under the global guards, tests. * test(shared): move the wording gate out of src so shared typechecks again CI installs shared with its own dependencies only (npm ci --workspace shared), so there is no @types/node and the `node:fs` import inside src/ failed to compile. The tests passed the whole time — vitest supplies the module — which is why this only showed up in the typecheck step. The walk moves to scripts/, next to i18n-parity.mjs, and the spec imports it the same way that one does. It also runs on its own now (`node scripts/i18n-selfhost-wording.mjs`), which is what you want when CI names a line you have to go find. * test(server): repair the call sites typecheck:tests caught tests/ sits outside the build tsconfig, so none of this showed up in a green test run — which is exactly the gap `npm run typecheck:tests` exists to close. Three kinds, all mine: - Seven `import type` paths for RuntimeEnvService carried one `../` too many. Type-only imports are erased, so vitest never resolved them and nothing failed. - VersionCheckJob and PluginsController grew a constructor parameter and eleven hand-wired `new` calls kept passing the old count. The argument arrived as undefined and no assertion happened to read it. - ConditionContext grew `managed`, and the shared context object in the conditions suite did not. The condition also had no test of its own, so it has one now: both directions, since the registry uses `is: false` to keep a notice away and a notice that only belongs on a centrally administered install would use `is: true`. |
||
|
Maurice
|
bfb3bcd63c |
feat(config): mark an install as centrally administered
Some installs are run by somebody other than the person who administers them. The operator owns the credentials, the configuration and the upgrade schedule, and the admin of the instance is a user of the result rather than the one who set it up. Nothing in the app knows that today, so it keeps offering settings whose values are not the admin's to change, and the honest answer to half of them would be a 403 the UI never anticipated. TREK_MANAGED says it once. It is a single boolean and the surfaces that care read it themselves, so adding one never comes back to the config layer. Runtime-toggled, in the same class as DEMO_MODE, rather than a registerAs token: roughly sixty tests mutate env mid-lifetime, and a value frozen per built app breaks all of them. `=== true` on the way in, so an unset, empty or misspelled value means off — a managed install sets it deliberately, and a typo must not quietly take settings away from an admin who never asked for it. The guard keys on a decorator, not on a path. MfaPolicyGuard documents where the two literal path lists it replaced ended up: they stopped being maintained, and every endpoint added afterwards silently fell on the wrong side. A marker on the handler cannot drift away from the handler. It carries a mandatory reason, which is for the next reader of the source rather than for the client, so the marks stay auditable. It registers third, after the auth and MFA guards, so a stranger still gets the 401 those two would have given them instead of a 403 that would confirm the route exists. And it checks the mode before it touches metadata, because it runs on every request of every install and almost all of them are self-hosted. One 403 body, shared by REST and MCP. DEMO_MODE grew two texts for the same condition and neither can be changed now without hunting for the other. The flag reaches the client through app-config so the UI can stop offering what the server would refuse anyway, but it is deliberately not persisted the way demo_mode is: two installs can share a browser profile, and a stale "this one is managed" would take settings away on an install that never set it. No route carries the marker yet. The per-domain marks follow. Unset, which is every self-hosted install, nothing about this changes anything. |
||
|
Maurice
|
c9193e0621 |
fix(maps): answer a keyless place lookup with an empty result, not a 400
An instance without a Google key already runs on the OpenStreetMap stack: search falls back to Nominatim, autocomplete does too, photos fall back to Wikimedia. The two details lookups were the exception. Both threw a 400 with "Google Maps API key not configured" the moment they were handed a Google place id. A Google id has no OpenStreetMap equivalent, so without a key there really is nothing to resolve. That is an empty result, not a caller mistake. The callers already treat a null place as a miss and fall back to the text-search path, so they were doing the right thing with the wrong signal, at the cost of an error round-trip and a logged exception each time. It bites whenever a place that was saved while a key existed is opened after the key is gone, and on any instance that never had one but imported Google-sourced places from a shared trip. The declared return type said the place was non-nullable while the OSM branch could already return null and the wire contract has always had it nullable. It now says what it does. |
||
|
Maurice
|
f02a4b5654 |
feat(maps): bill a place search as one session instead of per keystroke
Google charges autocomplete per request unless the requests carry a session token. With one, the keystrokes of a single search and the details lookup that ends it are charged together, which is also how a user experiences it: they looked up one place. TREK sent no token at all, so every debounced keystroke was its own billable request. On a busy trip that is the largest line on the Places bill, and it is paid by whoever owns the key, which for a self-hosted instance is the person running it. A session opens with the first suggestion request and closes when the user picks a result. It has to close on the abandoned paths too: a token carried into the next search would merge two searches into one billed session and scope the suggestions wrongly. So the search box clearing it, the text-search fallback and the error paths all end it. The token is validated on the way in. The autocomplete body goes through the Zod pipe, the details query does not, so the controller shape-checks it there. Anything that does not match Google's URL-safe 36-character form is dropped rather than forwarded, which falls back to per-request billing instead of breaking a lookup. A cached details hit never reaches Google and so never closes its session. That is billing-neutral: an unclosed session is charged as a plain autocomplete session, which is still cheaper than the per-request behaviour it replaces. |
||
|
Maurice
|
f23de88b74 |
fix(packing): authorize every single-item path against the item, not just the trip
A packing item is Common, Personal or Shared with named recipients. listItems() always applied that rule, but every path that touches one item resolved it by trip id alone, so trip membership plus packing_edit was enough to reach an item the member could not see. Update, delete, clone, the contributor routes and the sharing route all shared the lookup, and the same service methods sit behind the MCP tools and the plugin RPC, so all three transports carried the gap. The update was a read as well: it answered with the enriched row, which hands back the name, category, quantity, weight, the owner's username and the recipient list of an item the caller was never shown. Two flows laundered restricted items into places they do not belong. Saving a trip as a template read every row in the trip, so a template captured the names and categories of everyone's Personal items. Copying a trip did the same and re-inserted without is_private/owner_id, so both fell back to the column defaults and another member's Personal or Shared item reappeared in the copy as a Common item. That path needs only trip_create and trip access, not even packing_edit. There is now one visibility rule in the service and every single-item lookup goes through it. The actor is threaded through the HTTP, MCP and plugin-RPC entry points, and a missing actor denies rather than falling through unfiltered. An item the actor may not see is reported as missing, not as forbidden, so the routes cannot be used to confirm that an id exists. Two deliberate contract changes fall out of that. The sharing route answers 404 instead of 403 when the caller cannot see the item at all; a visible item they do not own still answers 403. And a template or a trip copy now carries the Common list plus the actor's own items, with a restricted item staying restricted and owned by the copier. Reported privately by Chichi (@vickyzer027-hash). |
||
|
Maurice
|
4cab17a6b9 |
fix(airtrail): read and write the passenger list under both its names
AirTrail 3.12.0 renamed the flight's passenger list from `seats` to `passengers` and moved flightReason from the flight onto each passenger. There is no alias in either direction: a 3.12.0 instance returns `passengers` and `null` for `seats`, and its save schema accepts only `passengers`. TREK read `raw.seats` everywhere, so against a 3.12.0 instance it found nothing. The seat never made it into the import, and because a pull rebuilds the metadata from the AirTrail payload, flights that had already been imported lost the seat they had. That is the report. Flights whose sync is switched off were never re-pulled, which is why theirs survived. Two more breaks came from the same rename and were not reported. The flight reason stopped importing for the same reason. And the writeback pushed the seat under `seats`, which the new schema strips, so a seat edited in TREK was quietly dropped on the way out; it did not fail loudly because the spread of the fetched flight carried AirTrail's own `passengers` through untouched. Both shapes are handled rather than switched between, because instances on 3.11 and older are still out there: reads take `passengers ?? seats`, and the save body carries the manifest under both keys. Neither schema is strict, so each version keeps the key it knows and strips the other. The snapshot hash deliberately keeps feeding the manifest in under the same key. An unchanged flight on an older instance therefore hashes exactly as before and does not re-sync, while a 3.12.0 flight hashes differently once and pulls the missing seat back in. There is a pinned-hash test guarding the first half. Verified against real instances rather than the docs: a 3.11.1 and a 3.12.0 container, seat imported from each, a seat edited in TREK written back and read out of AirTrail again, and the pre-fix build failing the same checks on 3.12.0. Closes #1931 |
||
|
Maurice
|
681fe1fee3 |
fix(dashboard): keep hotels out of the upcoming reservations widget
A stay covers a range rather than a moment, so one week in a hotel would hold a slot in a six-entry widget for the whole week and push out the bookings that actually happen on a day. The accommodation belongs to the day plan, which shows it across its span. They never worked here either, which is what the report is about. A hotel keeps its dates on the linked stay, not on the reservation, so the two ways one can exist behaved differently: The booking form writes reservation_time = NULL and sends no day_id, so a form-created hotel matched neither arm of the date test and was silently absent. That is the "incomplete" half. The accommodation panel auto-creates its booking with day_id and with the start day's date stamped into reservation_time. That row did show, but updateAccommodation syncs only metadata and the confirmation number to its linked bookings, so moving the stay left the stamp untouched and the widget kept the old date. That is the "no effect when I change the date" half. The type test is NULL-safe: the column defaults to 'other' but nothing stops a NULL, and a bare `type != 'hotel'` evaluates to NULL there and would have dropped those rows from the widget instead. Closes #1934 |
||
|
Maurice
|
041997e5e6 |
fix(feed): keep the TZID when a clock already carries seconds
fmtDateTime's time-only branch appended '00' for seconds no matter what it was given. The booking import stores what KItinerary hands it, which is '10:00:00', so the value came out 17 characters long. dtLine only attaches the TZID to a well-formed 15-character value, so those events lost their zone and went out as floating times, which is the #1453 regression by another route. It pads the way the ISO branch above it already does, so every caller is covered rather than only the rental markers. |
||
|
michael-bohr
|
7d580efce9 |
feat(feed): car rental pickup and drop-off events in the ICS feed
Rentals now emit two additional timed markers, Pickup and Drop-off, the same additive shape hotels already get for check-in/check-out (#1721, last unported piece). The rental's existing single-block event is untouched. Sides are derived in priority order: the endpoint role (from = pickup, to = drop-off, reusing the already-loaded endpoints map); if no endpoint on the reservation carries either role, positional first/last by sequence (only once there's more than one endpoint, so a lone endpoint is never both sides); otherwise reservation_time / reservation_end_time, since imports frequently carry only that window. Per side, an event only fires once a usable date and clock resolve; zone resolution prefers the endpoint's stored timezone, then its coordinates, then the reservation's linked place. Follows the hotel `marker` closure's pattern closely (same esc/uid/ dtLine/isDate/isTime/usedZones usage, same Pickup:/Drop-off: summary convention, same per-kind UID shape) without touching the hotel path itself. |
||
|
Maurice
|
9dd0a851ca |
fix: eleven reported bugs across atlas, budget, collections, journey, vacay and the LLM settings (#1923)
* fix(mcp): accept per-leg times on create_transport and update_transport metadata was pinned to Record<string, string>, so a legs array could not get through and a multi-leg flight built over MCP lost every intermediate time. The booking ended up with correct endpoints and no legs, which every reader then treats as a single segment. legs is now a real, typed parameter with its contract in @trek/shared, shaped exactly the way the planner form and the importers write metadata.legs. The folding checks what the readers depend on: one leg fewer than endpoints (the AirTrail dedupe builds its signatures on that), day ids that belong to the trip, airport codes that agree with their endpoint, and the times, where a stopover endpoint carries the departure and the last one the arrival. metadata keeps its type and its replace semantics. Segments smuggled through metadata.legs as a JSON string used to be stored and then ignored by everything that read them; they are refused now and point at the legs parameter instead. Closes #1914 * fix(atlas): refuse a bucket list entry that is already on the list Nothing gave a bucket entry an identity, so the same country could be added as often as it was clicked. A wish is now identified by name, country, target date and, where it has them, coordinates. A different target date is a different wish and still lands, which is what the report asked for; two real places sharing a name stay separate because their coordinates differ. Empty string and NULL are normalised on both sides of the comparison, otherwise the dateless case, which is the one that was reported, would slip through. Deliberately no unique index and no migration. better-sqlite3 is synchronous and the server is a single process, so the race an index would guard against cannot happen here, and an index would have needed a destructive dedupe of existing rows first. create_bucket_list_item had no target_date parameter at all, so over MCP the allowed "same place, other date" case was unreachable. It takes one now. The plugin RPC reports the duplicate as bad params instead of letting it surface as an internal error. Closes #1898 * fix(settings): keep a free-form LLM endpoint in admin hands Any account could name the address the server calls, and the guard in front of it deliberately allows loopback and LAN so a self-hosted Ollama works. That is a reasonable trade for whoever runs the instance, because the network is theirs. It is not one for an arbitrary account, which could aim a request from inside that network at a target only it chose and read how the target answered. A free base URL, and the local provider that is one by another name, now come only from an admin controlled source: the addon config, the instance-wide defaults, or an admin's own settings. OpenAI and Anthropic stay available to everyone, because they go to a fixed address with the user's own key. The resolver is where this is enforced, since it is the single point both the booking import and the plugin host pass through, and the only one that also covers values already sitting in the database. The write path refuses as well, so nothing is stored that would never be read. The hint text promised something users no longer have, so it changed with it. Closes #1772 * fix(calendar): span a date-only booking to its end date A DATE event without DTEND is exactly one day per RFC 5545, so a multi-day booking that carries an end date still collapsed onto its first day. It gets an exclusive DTEND now, built the same way the stay branch already builds one. A booking without an end date serialises byte for byte as before. While in here: the stays query joins reservations on the accommodation, and two bookings pointed at the same stay fanned it out into two events sharing one UID. Duplicate UIDs in a feed are undefined behaviour and calendar clients pick one at random. The same "at most one booking per stay" assumption sat in the accommodations service, where it was worse than cosmetic: accommodation_id carries no foreign key, so deleting a stay took only the first booking and left the second pointing at something that no longer existed. Both the sync and the delete walk all of them now. The callers keep reading linkedReservationId; the list is additional. Refs #1869 * fix(vacay): say that the region is required, because it is The placeholder called the region optional while the add button stayed disabled until one was picked. The wording predates multiple calendars per plan, which is what introduced the gate. Only the value of the existing key changed, in all locales, so the key set stays identical. Two things the same screen got wrong were in the way of a clean answer: The button was clickable while the region list was still loading, which put the user in exactly the state the wording describes, and it is the state the report was filed from. It waits for the list now. Changing the country on an existing calendar kept the previous country's regions on screen, so a German region could be picked for the Netherlands. The list is cleared with the country, which only works in combination with the loading gate: without it, the empty list would happen to enable the button instead. Closes #1813 * fix(collections): let a saved place's address be corrected The edit form offered name, category and labels, and the address only on the way in. The cause was not the form: the update contract never declared address, so the validation pipe stripped it and the UPDATE had no column for it. Coordinates were pulled through for #1435 and the address was missed. It travels the whole chain now, contract to service to both forms. No migration, the column has always been there. The mobile add sheet had no address input at all, showing whatever the search result carried as read-only, so editing would have worked while creating still would not. It has one. The MCP tool description had drifted further than the address, never having mentioned the coordinates either. Both are in it now. Closes #1870 * fix(collections): keep the place search usable after the first save The add dialog stays open on purpose so several places can be added in a row, but after a save it gave no way back into the search. A search with no results was silent, with no empty state and no toast, so typing another name and pressing enter looked like nothing happened. The reporter described both halves and it is the silent search that matches "nothing happens" most closely. There is an empty state now, using a key that already existed in every locale and was unused. The search row is sticky inside the dialog body, so it stays reachable after the save instead of sitting above the scroll position. Also fixed while in here: refreshing the collection after each add reset the select mode, the selection and the label filter. In the very flow this dialog is built for, the user quietly lost all three. Closes #1921 * fix(vacay): make the phone year grid and the dock button do what they look like Two separate faults met on this screen. Tapping a day in the year grid did nothing unless the edit mode was already on, and the only way into it was a floating button that looks exactly like the one the dock draws in the same spot. A tap now opens that month in the editor, where the cells are big enough to hit. At 390px the grid cells are around 21px, which is too small to be mutating data with in the first place. The dock's plus was not wired for this route, so it fell through to creating a trip on the dashboard. Two different actions were stacked in one place, and the wrong one was on top whenever the screen had not painted yet, which includes the time its chunk is still loading. The dock leaves the slot to the screen now, and holds the geometry so the tab groups stay symmetric. Closes #1811 * fix(budget): settle in whole cents so balances stop drifting The report is a balance that moves on its own, with nothing added, edited or removed, on a trip where everything is in euro. Two mechanisms were behind it and both are real. The display currency is a fourth value, a per-user setting, so "everything is in euro" never covered it. Each balance was converted and rounded on its own, and the set no longer summed to zero: at 0.855 and 0.9312 it came out one cent over, at 0.94 it came out even. That cent appears and disappears with the six hour rate cache alone, which is exactly the symptom. The flows were rounded separately from the balances, so the two never had to agree. And a receipt line nobody was ticked for counted toward the total, and therefore toward the payer's credit, while landing in no share. That difference is permanent, and the client sent it that way. The settlement converts once, at the edge, and does integer arithmetic after that. Equal splits distribute the credited cents by largest remainder rather than the entered total, so credits and debits of one expense cancel exactly even in a foreign currency. Display conversion goes through the same largest-remainder allocation, so the sum survives it. With that, the 0.01 epsilon can go. It could never create a cent, but it stranded them: a one cent balance was filtered out of the flows while staying visible in the list, which is the "settle up offers nothing" half of the report. Closes #1382 * fix(journey): reach the book export and the suggestion toggle on a phone Below 1024px the hero card is dropped, and it held the only way to either action. The floating bar that replaces it was never given them. It has them now, and the hero is unmounted rather than hidden, so there is no second invisible copy of the same controls in the document. The bar's own buttons moved onto the appearance tokens while they were being touched. The phone screen never had either action at all and now carries both. The book itself was hardwired to English, cover and dates included, while the keys for it had been sitting in every locale unused. It takes the page's translator and locale, sets the document language, and prints mood and weather, which were on screen but never in the book. Closes #1848 * fix(journey): offer the connected photo providers in the phone entry editor The desktop editor grew an external photo source in #1632; the phone editor that came out of the mobile rewrite never did, so editing an entry on a phone had no way to Immich or Synology. It mirrors the desktop mechanics, including the part that is easy to miss: a save that creates the entry and then fails on the photos keeps the sheet open, and without remembering what was just created the retry creates a second entry. The sheet no longer kicks off its own addon load. The list is loaded once on boot and this only reacts to it; a second load races the other consumers and overwrites the store when it lands. Closes #1808 * fix(mobile): let the document scroll so Safari can collapse its URL bar iOS Safari only shrinks its address bar when the document scrolls, and TREK's never did: the root was locked and the mobile shell put a scroll container inside it. On the bottom tab layout that costs about a sixth of the viewport, permanently. Below 768px the document is the scroller again and the full-bleed screens measure their own height instead of leaning on the shell. That makes the body scroll locks real for the first time on a phone, and they were not ready for it. Three of them reset the overflow unconditionally, one of those on every run of its effect rather than on unmount, so a system notice could hand the page back while a sheet was still open. They all go through one reference counted lock now, which is the part that had to land first. Worth knowing for the issue: this reaches the flow screens. The trip planner, the journal, the atlas and the vacay screen keep their own full-height scrollers and still will not collapse the bar. Closes #1809 * fix(mobile): keep the screen gradient visible behind the translucent cards The gradient layer introduced with the scroll change sat at z-index -10. A negative layer paints above the canvas but below the backgrounds of ordinary blocks, and body carries an opaque one, so the gradient was hidden behind it. The mobile cards are translucent and take their depth from what is behind them, so every surface ended up compositing against a single flat colour and the whole phone UI read as one tone. The layer is positioned at z-index 0 now and the content above it at 10, which puts both over body's background. Same visual as before the scroll change, and the shell still owns no scroll container. * test(reservations): teach the accommodation delete stub about the id lists The RPC walks every linked booking since the delete stopped stopping at the first one. The stub still answered with the two singular fields, so the loop had nothing to iterate and the cascade events never fired. * fix(settings): move the free-form LLM endpoint out of user settings entirely Hiding it from non-admins closed the hole, but it left the option sitting in the admin's own personal settings, which is not what was asked for and not where it belongs: an instance has exactly one address it calls out to, and there was a second, invisible place to set it. The provider list is now the two hosted ones for everybody, the endpoint field is gone, and the resolver takes the address from the admin-controlled instance defaults for every caller including an admin. It no longer reads the users table at all. The write path refuses the keys for everyone, so nothing can be stored that would never be read. The endpoint is configured on the addon in the admin settings, which already carries provider, model, base URL and key, plus the Ollama model list. Nothing is lost, it just has one home now. Behaviour change worth a release note: an admin who set a personal Ollama endpoint has to move it to the addon config. A non-admin was already in that position after the previous commit. Refs #1772 * fix(journey): make the book preview usable on a phone The preview document carried no viewport, so a phone laid it out at its default 980px while the page is A4 landscape and about 1123px wide. It spilled out of the frame, which reads as being zoomed far in. Declaring the real width lets the browser scale the page to fit. Printing is unaffected, it goes by @page. The preview chrome had the same problem in miniature: a title and two labels on one row, sized inline, which does not fit a phone and fits translated labels even less. It moved to a stylesheet, and below 640px the card goes full-bleed, the decorative title steps aside and the two actions share the width. Refs #1848 * fix(mobile): stop the shell trapping the screens' own overlays Lifting the background layer into the positioned range meant the content wrapper had to be positioned too, and a positioned wrapper with a z-index is a stacking context. Every fixed overlay a screen renders inside it got clamped to that level: the vacay view/edit FAB sits at z-50 precisely so it beats the dock at z-40, and it disappeared behind it. The layer goes back to a negative z-index and the wrapper back to no positioning at all. What it needed in the first place was for body to stop painting over it, which is one line in the phone media block rather than a new stacking context. * fix(mobile): let the phone background override actually win A media query adds no specificity, so the themed body rule further down the file kept winning on source order and painted over the shell's background layer. The override is on html body now. The gradient was back to being invisible, which is the flat single-tone phone UI again. * fix(vacay): draw today's ring around the day instead of replacing it On the phone, today short-circuited the day-cell matrix and returned a ring on an empty cell. A vacation day or a company holiday logged for today was stored and counted in the totals, but the cell showed nothing, so it read as if the tap had not taken. Today is an annotation now, layered like the school band and the shared-calendar rings, which is how the desktop month card has always treated it. The strong ink stays only where the cell has no fill of its own, since --m-ink is light in dark mode and would disappear on a pastel. * fix(map): stop serving a stale GL style document from the service worker The Workbox rule for Mapbox matched every URL under api.mapbox.com, and the style document lives there too. Under StaleWhileRevalidate the map was built from the previous revision on every load, with the refresh landing one load too late, so a style republished in Studio with different label languages kept rendering the old ones. The network tab showed a 200 throughout, because the service worker's own answer is a real 200, which is why this looked like the app rewriting text-field at runtime. The style now has its own rule ahead of the tile rules, on NetworkFirst so it is current whenever the network is, and still cached so the map opens offline. Its own small cache too: sharing an LRU with three thousand tiles made the staleness come and go at random. OpenFreeMap styles had the same problem and are covered by the same rule. Closes #1924 |
||
|
Maurice
|
3c5e406229 |
feat(places): link an expense to a place, the way bookings already do (#1917)
* feat(places): link an expense to a place, the way bookings already do Recording what a museum ticket or a guided tour cost meant leaving the place, opening the Costs tab and typing it in again — while a booking has had a Costs block in its own form all along. The place form now carries that block. Same component, same flow: with nothing linked it offers Create expense, which saves the place and then opens the Costs editor for a new expense pointing at it; once linked it shows the expense with edit and remove. budget_items gains place_id beside the reservation_id it already had, with the same nullable FK and the same ON DELETE SET NULL. Desktop and phone both, and the mobile editor carries the link through its own save path rather than the desktop one. The expense belongs to the place, not to a day assignment, so a place sitting on five days is not five tickets. Hanging it off the assignment would have meant adding a place to three days quietly creating three expenses and removing a day quietly deleting one. Deleting a place takes its expense with it in the same transaction and announces it, on every path that deletes a place: REST, both MCP tools and the plugin RPC. Closes #1298 * test(places): teach the RPC stubs about linkedExpenseIds The delete paths read the linked expense before the place is gone, so the two hand-built PlacesService stubs threw on the new method instead of reaching the hook, the remove and the broadcast — four failures out of one missing line. |
||
|
Maurice
|
df3edac7b9 |
feat: six community requests — import dedup, accommodations in the feed, OAuth refresh race, visited-from-trip, journal jumps, phone packing rows (#1915)
* fix(places): match imports on the provider id so renamed places are not duplicated Re-importing a Google Maps list duplicated every place the user had renamed. buildDedupSet only ever collected names and, for unnamed places, coordinates, and isPlaceDuplicate returns on the name before it reaches the coordinate fallback, so a renamed place was findable by neither. The ids were stored all along, and even backfilled onto matched places, they were simply never read. Match on google_place_id / google_ftid / osm_id first, keeping name and coordinates in their old roles below it. Widening the coordinate check instead would have merged the restaurant and the bar in the same building. The collection copy carried a hand-mirrored port of the same predicate; it now uses the shared helpers and gets the fix with them. Closes #1550 * feat(calendar): put accommodations into the subscribed feed as all-day stays A hotel keeps its dates on the linked stay, not on the reservation: the booking form writes reservation_time = NULL for type 'hotel', and day_accommodations carries start day, end day and the check-in/out clock. The feed only ever read the reservation, so a stay showed up once on the arrival day at best, and not at all when it came from the booking form. Join the stay in and emit the reservation as an all-day range over every night, which also keeps it correct when days are reordered later — the dates now come from the day rows rather than from the copy stamped at creation time. Check-in and check-out become their own timed events when the stay records a clock, because an all-day event cannot carry the time you actually need reminding of. The check-in window, when set, becomes that event's DTEND. Closes #1586 * fix(oauth): treat a concurrent refresh as a race, not as a stolen token Refresh rotation is a race by construction. Several MCP clients share one refresh token, both post it within the same second, and the loser was read as a replay: chain revoked, MCP sessions torn down, browser window asking to log in again. That is the daily re-authentication people were seeing, not a short lifetime — access tokens last an hour and refresh tokens roll for thirty days. A revoked refresh token now only counts as a replay once it is outside a 30-second grace window, and only when the rotation that revoked it left a successor still alive. Inside the window the caller gets its own pair branched off the same parent, so both clients walk away with a working token. Explicit revocation leaves no live successor and a chain killed by a real replay has none either, so neither can slip through the window. Closes #1007 * feat(collections): mark a place visited from the trip it belongs to A place saved in several lists had to be opened in each of them to say you had been there, which is the wrong way round: you find out you have been somewhere while looking at the trip, not while browsing the library. The save picker now shows each list's own status and cycles it in place, with one action for "visited, wherever this is saved". The planner's selection bar and the mobile bulk toolbar carry the same thing for a whole selection — select all, one tap, done. Matching happens on the server with the signals findMembership already uses plus the source link a place saved from this trip carries, so a copy renamed inside a list is still found. Lists you may only read are skipped rather than refused; a shared list you cannot edit should not stop you marking your own. Closes #1469 * feat(journey): jump to the top or back to the last entry in a long journal Everything that adds to a journal sits at the top — the entry button, the gallery upload — and where you left off sits at the bottom, so adding one photo to a long journey meant scrolling the whole way twice. Two buttons float over the middle of the feed, clear of the Add Entry column on one side and the reorder arrows on the other, each appearing only when there is more than a screenful to travel in that direction. They live in a zero-height sticky box so they take no layout space and never push the timeline around. While in the header, the status pill also picks up the height of the round buttons beside it. Closes #1088 * fix(packing): give the item name the row back on phones An item name had roughly a third of the row to itself: a spelled-out sharing sentence, an empty weight column and two round action buttons took the rest, so anything longer than a word was cut off. Sharing is now the icon it always was next to a label rather than a sentence in the layout, an unset weight prints nothing instead of a dash, and edit/delete sit behind one overflow button that opens the same inline menu the bag picker already uses. The to-do list needed none of this — it wraps its chips onto a second line already. Closes #1525 * docs(wiki): cover the six community changes - Calendar feeds: accommodations as an all-day range plus check-in/check-out - Collections: setting the visited status from a trip, and how places are matched - Journey: the jump buttons on a long journal - Packing: what the phone row keeps and what moved behind the overflow button - Places: re-importing a list no longer duplicates renamed places - MCP setup: the rotation race no longer ends an OAuth session * test(collections): assert the stored status instead of a private method tests/ sits outside the build tsconfig, so reaching into getPlaceById only showed up in the dedicated typecheck step. Reading the row is the better assertion anyway — it pins what was persisted, not what a getter returns. |
||
|
Maurice
|
870bd6131f |
feat(journey): draw the trips' GPX tracks on the journey map (#1911)
* feat(journey): serve the GPX tracks behind a journey A journey has no trip of its own, but every entry records the trip it came from, and a trip's routed geometries live on its places. So the tracks are derivable without any new storage: GET /journeys/:id/tracks walks that link and returns the geometries, dropping elevation nothing on the map reads and skipping anything that is not a usable line. * feat(journey): draw those tracks on the journey map Both renderers, Leaflet and GL, plus the mobile map-timeline that shares them. Solid and in the track's own colour with a white casing, so it reads as a recorded route rather than as the dashed line that merely connects entries in time order, and stays legible on satellite tiles. * feat(journey): load the tracks alongside the journey Fetched separately from the journey itself: most journeys have no tracks, and a failed lookup should cost the map its lines rather than the whole page. * docs(journey): document the GPX tracks on the map * fix(journey): label tracks with the house map tooltip bindTooltip's default box ignores the appearance tokens, so it sat there in Leaflet grey next to markers already using .map-tooltip. Same class now, and an unnamed track gets no tooltip at all instead of an empty one. |
||
|
Maurice
|
767dc662b7 |
feat(atlas): search by place, and count cities that are actually cities (#1908)
* refactor(atlas): drop the last-trip tile from the stats bar The row beside the continent counts is statistics; a single trip sitting in it was neither, and the trip it named is already one click away in the country detail below. Its two locale keys go with it, along with atlas.lastVisitLabel, which nothing had rendered for a while. * feat(atlas): resolve a coordinate to its country and region Groundwork for searching the atlas by place: /locate answers with the admin1 region a point falls in, resolved against the same bundled polygons the visited colouring uses, so the answer is always something the map can highlight. A country without admin1 coverage resolves to a country and a null region, which is a real answer rather than a failure. * feat(atlas): search the map by place, not only by country Typing a city geocodes it through the same /maps/search everything else uses and offers the hits below the instant local country matches. Picking one flies there and opens the dialog for the region it sits in, so Milan marks Lombardy without the user knowing that is where Milan is. The country list stays offline and instant; only the place lookup waits on the network, debounced and sequence-guarded so a slow answer cannot overwrite a newer query. * fix(atlas): count cities instead of shop names The visited-cities figure scanned the address left to right and took the first part that was not a country and matched a latin-only pattern. The first part of a geocoded address is the place itself, so a trip to Tokyo counted Shibuya Sky, Shibuya Parco and Family Mart as three cities, while an address written in Japanese, Cyrillic, Greek or Korean counted none at all. Read from the administrative end instead, skipping the country, anything with digits, and the region already resolved for that place in place_regions, which is what separates the city from the region above it. On one real trip the count went from 20 entries, nearly all of them streets and shops, to Paris, Shibuya, Minato and three Berlin boroughs. * i18n(atlas): translate the place-search heading * docs(atlas): document place search and how cities are counted * fix(atlas): stop the search panel closing itself while results arrive The dropdown closed on mouseleave, which was survivable while it held only local country matches and appeared complete in one go. Geocoded places land a moment later and grow the list under a cursor already resting there, so the panel shut itself seconds after opening. Closes on a click outside now, Escape unchanged. |
||
|
Maurice
|
9ce6eed9ad |
feat(places): export a trip as GPX (#1907)
* feat(places): hand a trip back as GPX TREK reads GPX but never wrote it, so a planned trip could not reach the offline map or the handheld it was planned for. The importer already fixes the mapping: a wpt is a place, a rte or trk is a place with route_geometry, so writing is that reversed. Days have no import counterpart and become routes of their stops in order, which is the part that puts a plan on a device. XMLBuilder comes from the same fast-xml-parser the importer parses with, so nothing new is pulled in. * feat(dayplan): a GPX button beside PDF and ICS Scopes are worded by what someone wants on their device rather than by the GPX element: the whole trip, just the places for an offline map, just the days to follow a plan. An empty trip says so instead of reporting a failed download. * feat(mobile): GPX in the export sheet, which is no longer calendar-only The sheet held the PDF export next to the calendar entries and was still called Export Calendar; with GPX beside them the name was simply wrong. * i18n(dayplan): translate the GPX export into all locales * docs(map): document the GPX export * fix(dayplan): drop the GPX tooltip and centre both export menus The tooltip sat under the cursor exactly where the menu opens, so hovering the button produced both at once. The label lives on as an aria-label. Both menus now open centred under their button instead of hanging off its right edge. |
||
|
Maurice
|
b842d74a5d |
feat(collections): import a whole trip's places into a list (#1903)
* feat(collections): preview which of a trip's places a list already holds The bulk import endpoint has been there since the select-mode copy, but nothing calls it and it only reports duplicates after the fact. A dialog needs the verdict up front, so /:id/importable/:tripId returns the trip's places with the duplicate check the import itself applies, plus whether any day holds the place. * feat(collections): import a whole trip's places into a list Two steps: pick a trip, then tick its places. Places already on the list are greyed out and unpickable, and the ones no day holds start selected — those are the plans a trip left behind, which is the reason to import at all. Sorted so a mostly-saved trip reads as the two that are left rather than a wall of grey. * feat(collections): reach the trip import from the filter row and an empty list * i18n(collections): translate the trip import into all locales * fix(collections): stop the label dialog's buttons wrapping mid-word Three actions in a max-w-sm footer wrapped into two lines each. The assign button also painted white text on the accent, which disappears on a light one. * docs(collections): document the trip import |
||
|
Maurice
|
27ffd3ec68 | fix(db): append the incoming leg mode migration so upgrades pick it up | ||
|
Ida Rogalska
|
f5e06e0dea | test: outgoing and incoming leg modes persist independently | ||
|
Ida Rogalska
|
cedbe39b35 | api: PUT /assignments/:id/transport gains direction (outgoing|incoming) |