4.3.3
Fixed
- Logging in through a self-hosted identity provider works again when its host name also has an IPv6 link-local record. Since 4.3.0 a single blocked address refused the whole name, and LAN DNS servers commonly publish a host's
fe80::address next to its IPv4, so every OIDC login failed with "Requests to link-local / cloud-metadata addresses are not allowed". Immich, Synology and the other integrations on such a name failed the same way. TREK now leaves the blocked address out and connects over the host's other addresses, and a name that resolves to nothing else is still refused.ALLOW_INTERNAL_NETWORKandALLOW_LINK_LOCAL_IPSwork as before, except that the AWS and Alibaba metadata addresses now stay blocked for URLs a user types even withALLOW_INTERNAL_NETWORKon, as they already were for the admin settings, and a link-local or metadata address written as an IPv6 form of its IPv4, such as::169.254.169.254, is now refused everywhere. (#2529, Closes #2506) - Trips can be deleted on a container without a writable temp directory, such as one with a read-only root filesystem and no tmpfs on
/tmp. Deleting a trip failed there withSQLITE_IOERR_GETTEMPPATH, because SQLite moves a large statement journal into a temp file. It now keeps its temporary data in memory, on the main database, the plugin databases and a backup checked before a restore. (#2529, Closes #2518) - After an update, a device no longer gets stuck on "A new version is available" with "Failed to fetch dynamically imported module", whatever the reload or the cleared browser cache. The server answered a request for a build file the update had removed with the app page, so the import failed, and a service worker that met it during install kept the page as the file, carrying the broken entry into every later release that kept that file's name. A missing build file now gets a plain 404. The app repairs a broken cached stylesheet, font or icon on its own, and a reload after a dead chunk drops the broken offline copy first and asks for the page under a fresh URL that no cache has kept, so it reaches the build the server runs. Offline, the app keeps its copy. The recovery starts with the first launch that runs 4.3.3; until then, a reverse proxy or CDN that keeps
index.htmlorsw.jsregardless of their headers can still hand out the old copy until its cache is cleared. An install living under a directory whose name starts with a dot no longer answers every deep link with a 404. (#2529, Closes #2524) - An expense entered in the display currency reads exactly as it was typed as long as the rate has not moved since it was entered. On a euro trip read in dollars, a bill of $12,345.67 showed as $12,346.05 in the Costs list the moment it was saved, and $250.00 as $250.01, while its dialog showed the amount entered; the totals and settle up drifted with it, and paying back what settle up offered left the trip open with the debt flipped the other way. The Costs screen and the settlement now convert with the same quote the entry rate was frozen from, on the desktop, the phone and the shared trip page, and paying the amount settle up offers leaves both balances at zero. When the rate really moved since the expense was entered, the row shows the value the totals count, with the amount entered and the booked trip amount underneath, and the split summary in the expense dialog puts what each share counts as next to the share entered, such as $400.88 → $390.53 each. Nothing stored changes, so expenses entered before the update read correctly as well. When the trip currency differs from the display currency, both CSV exports get an
Amount (<trip currency>)column betweenCurrencyandAmount (<display currency>), so the display amount moves one column to the right. (#2529, Closes #2525) - A price read from an imported booking keeps the currency it was quoted in, at the rate of the day it is saved, on the desktop, the phone,
create_budget_entryon the REST API and through plugins. The review showed $801.76, but saving sent the amount alone, so the linked cost was stored as 801.76 in the trip currency. Costs imported that way before this release keep the amount and currency they were saved with. (#2529) - An expense saved without a currency, such as a booking's linked cost, opens in the trip currency. It opened in the display currency, so its amount stood under the wrong currency and saving it stored it in that currency; expenses already saved that way keep what was stored. A booking's window also labels such a linked cost in the trip currency, so a 120 EUR deposit no longer reads as $120.00, and a payment recorded before payments carried their own currency reads in the display currency on the Costs list, as the balances always counted it. (#2529)
- The shared trip page values each expense at the rate it was booked at, as the Costs tab does, instead of at today's rate, and prints whole cents. On the desktop, the Costs totals follow the exchange rates once they arrive, where they kept counting foreign amounts 1:1 until the next change. (#2529)
get_trip_summary, the budget overview prompt and the per-person budget summary added up expenses in different currencies as they were stored and labelled the sum with the trip currency. They now count each expense in the trip currency at the rate it was booked at;get_trip_summaryaddsby_categoryand the per-person summary names itscurrency. (#2529)- An expense or payment in another currency is no longer counted 1:1 in the trip currency when there is no exchange rate for it. When the server could not fetch rates itself while the browser could, such an expense was saved without a rate and settled at its face value, so a VND bill on an AUD trip turned into balances in the millions. Such an expense or payment is now left out of the balances, settle up and the final budget until a rate is known. When you save an expense or a payment, the browser passes on the rate it already has, and when someone who may edit costs opens Costs while such rows exist, every expense and payment in another currency without a frozen rate gets one, the server's own rate where it has one and the browser's otherwise. In the same setup, a trip read in another currency than its own showed its balances and settle up in trip currency figures under the display currency's sign; the browser's rate now converts them. Changing an expense's currency while no rate is available no longer keeps the old currency's rate; an expense that already kept one keeps it until its currency is changed again.
get_settlement_summarylists the expenses and payments it left out and names the currency of its figures,get_trip_summarylists the expenses it could not count, and the newfreeze_budget_rates, which needs permission to edit the budget, pins the server's rate of the day on every expense and payment in another currency that has none yet. (#2529) - Place pins open their place again after the map was dragged. Since dragging places onto days arrived, one drag of the map made every later pin click count as the end of that drag, so pins did nothing until something else on the map was clicked. This affected the default map in the trip planner and on the collections map when used with a mouse; the GL maps never were. A pin click still closes an open menu or map popup. (#2529, Closes #2504)
- Moving a place to another country moves it on the Atlas too. The country and region Atlas had worked out for a place stayed cached after its location was corrected, so Atlas, the dashboard and the journey stats kept counting the country the place had left. The cached country now follows every change of a place's coordinates or address, from the editor, MCP, plugins or an import. Places that were already wrong are checked once, on the first start after the update, against the country borders TREK ships with: a place those borders put in another country is corrected then, and one they cannot place is looked up again on the next Atlas load when its coordinates and its address both disagree with the cached country. (#2529, Closes #2527)
- Photos uploaded to a Journey keep their GPS location and their capture time. The location was never read, so no uploaded photo showed on the journey map, and the capture time ignored the photo's own time offset and was read in the server's time zone, so a photo taken at 15:52 in France was stored hours off on a server in another zone; a photo that records no offset is still read in the server's time zone. Impossible dates in a photo are dropped instead of being rolled over into real ones, and a GPS block of zeros counts as no location instead of a pin at 0,0. Photos uploaded before this release keep their stored time and location for now. (#2529, Closes #2512)
- The public share page says a link has expired only when it really has. Any failed load, a server restart, a proxy error, a rate limit, a timeout or a viewer briefly offline, showed "Link expired or invalid" and sent people back to the owner for a new link. Such a failure now shows "This trip could not be loaded" with a button to try again, and a sign in page from an auth proxy in front of TREK, returned in place of the trip, no longer crashes the page. (#2529, Closes #2505)
- The TREK logo at the top of notification and password reset emails shows in Gmail and Outlook. It was an SVG inlined as a data URI, which neither displays, so they showed a broken image; it is now a small PNG embedded in the mail as an inline image. (#2529, Closes #2507)
- On the phone, a plan timeline day that starts with a flight and also has the hotel's place as one of its stops no longer opens with a hotel row and a drive above the flight. The route draws no drive from the hotel on such a morning; the drive shown there was the hop from the hotel stop to the next place, which then showed a second time in its own spot. The timeline now shows exactly the hotel legs the route drew. (#2529, Closes #2501)
- The phone's plan timeline shows the drives around a booked ride, as the desktop day plan already did: from a flight's arrival airport, or a train's or ferry's arrival station, to the next place, from the last place to the departure airport or station, and past a booking saved without a location, such as a taxi or a concert between two stops. (#2529, Closes #2502)
- On the desktop, a transport can be deleted from its edit window. The window had no delete button, and the only way to delete a transport there was its card in the Transports tab, which the day plan never leads to; the phone's transport sheet already had one. The button asks for confirmation first and shows to everyone allowed to manage bookings. (#2529, #2530, Closes #2528)