Mate 4.13.0 — trips show where they started and ended

Mate 4.13.0 — trips show where they started and ended

@arekm's #404: every trip says where it
started and ended, kept as an address of its own instead of text in the trip's note.

---

Where a trip started and ended — #404, @arekm

• A trip's row reads "A → B": in the middle of the row on a computer, on a line of its own on a
  phone. The Trip summary on the trip's page names both ends in full, and the trip's start and end
  rows in Events name theirs.
• An end inside one of your charging places shows the place's name, marked "(charging place)", so
  renaming the place renames those trips. Elsewhere it is the address: a shop or a station by its name,
  else the street and number, then the town.
• Mate looks the addresses up shortly after a trip ends, with the provider set in Settings ▸
  Address lookup (OpenStreetMap's Nominatim unless a provider with its key is set there). Each spot,
  19 m by at most 38 m, is asked about once and shared by every trip and car that starts or ends there. At most
  4 requests a minute, 1.1 s apart; a failure is asked again from 15 minutes up to 6 hours; an address
  found is asked again after 90 days.
• A new switch in that card, Look up where trips start and end, turns the lookups off: nothing is
  then sent by itself, and the addresses already found stay shown.
• 🧭 beside a missing address in the Trip summary looks that trip's ends up at once, on any trip,
  whatever the switch says.
• Only the trips that ended in the last three days are looked up by themselves. An older trip that
  started or ended where a newer one did shows that address too.
• The search on Trips and on Events finds a trip by either end, its name or its full address.
• The trips CSV export gains two columns at the end, start_place and end_place.
• Where an address from OpenStreetMap is shown, the view credits it once.

Upgrade impact

• A new table, addresses, is created when Mate starts. Nothing already stored is migrated,
  recomputed or deleted.
• The new switch starts as "Write the note by itself" was, since on 4.12.1 that automatic note is
  what sent a trip's ends to the lookup service: an install that had it off sends nothing by itself, the
  others keep sending the start and end of each new trip, as before. From then on the two switches are
  separate.
• Mate no longer writes a trip's note by itself. The automatic trip note (address, time and
  temperature) and the 🧭 beside the note are gone; Write the note by itself now covers charges only.
  The notes written before stay as they are.
• Trips older than three days at the update get no lookup of their own: their ends show "—" until
  🧭 is pressed or a newer trip starts or ends at the same spot.
• The demo seeds its own addresses and asks no one.

Verification

• CI green on the tag: 5,472 passed, 1 skipped (a test that needs a local-only file), plus 48
  on the Windows job; the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added — so that nothing is
  skipped: 5,473 passed.
• The new and changed tests, run on 4.12.1, give 7 failures and 10 errors (the lookup and its table do
  not exist there); now all 138 pass. Four deliberate breaks of the new code — no check of the switch,
  the switch always on after the update, the Settings card not saving it, 🧭 obeying the switch — each
  turn one of them red.
• In Chromium, on a copy of a real database with no network and the provider replaced by a stub, and on
  the demo, at 1280 and 390 px: trip rows, the Trip summary and Events name both ends; the search finds
  trips by a place; the CSV has the two new columns; no new script errors. A database where "Write the
  note by itself" was never changed starts with the new switch on; one where it was off starts with the
  switch off and sends nothing when Trips opens. With the switch off, 🧭 on a September trip made 2
  requests and drew both addresses. The Settings card turns the switch off and on again without touching
  the note's. With no network, the first lookup fails and waits 15 minutes; 🧭 then leaves the dashes,
  with no message.
• The Docker image, built from this commit, ran on the test instance with a real database before the
  tag: every page answers, the new switch is on after the update, the trip page shows the ends' lines
  and 🧭, the CSV has the two new columns, and the first pass asked Nominatim about 4 spots and found all
  4.
• Not tried: a real phone, Safari, Firefox, and the add-on behind Home Assistant.

---

Italiano

Mate 4.13.0 — i viaggi mostrano da dove sono partiti e dove sono arrivati

La #404 di @arekm: ogni viaggio dice da
dove è partito e dove è arrivato, tenuto come un indirizzo a sé invece che come testo nella nota del
viaggio.

---

Da dove a dove — #404, @arekm

• La riga di un viaggio dice «A → B»: al centro della riga sul computer, su una riga a sé sul
  telefono. Il Riepilogo del viaggio nella sua pagina nomina per intero i due estremi, e le righe di
  inizio e di fine del viaggio in Eventi nominano il loro.
• Un estremo dentro uno dei tuoi luoghi di ricarica mostra il nome del luogo, con «(luogo di
  ricarica)», quindi rinominare il luogo rinomina quei viaggi. Altrove è l'indirizzo: un negozio o un
  distributore per nome, altrimenti la via e il civico, poi la località.
• Mate cerca gli indirizzi poco dopo la fine del viaggio, con il servizio scelto in Impostazioni ▸
  Ricerca indirizzi (Nominatim di OpenStreetMap, se lì non c'è un servizio con la sua chiave). Ogni
  punto, 19 m per al massimo 38 m, viene chiesto una volta sola e vale per tutti i viaggi e le auto che partono o
  arrivano lì. Al massimo 4 richieste al minuto, a 1,1 s l'una dall'altra; un errore viene richiesto da
  15 minuti fino a 6 ore; un indirizzo trovato viene richiesto di nuovo dopo 90 giorni.
• Un interruttore nuovo in quella scheda, Cerca partenza e arrivo dei viaggi, spegne le ricerche:
  allora non viene inviato nulla da solo, e gli indirizzi già trovati restano visibili.
• Il 🧭 accanto a un indirizzo mancante nel Riepilogo del viaggio cerca subito i due estremi di quel
  viaggio, su qualsiasi viaggio, comunque sia l'interruttore.
• Vengono cercati da soli solo i viaggi finiti negli ultimi tre giorni. Un viaggio più vecchio partito o
  arrivato dove è passato uno più nuovo mostra anche lui quell'indirizzo.
• La ricerca in Viaggi e in Eventi trova un viaggio da uno qualsiasi dei due estremi, dal nome o
  dall'indirizzo completo.
• L'esportazione CSV dei viaggi ha due colonne in più in fondo, start_place e end_place.
• Dove compare un indirizzo di OpenStreetMap, la vista lo cita una volta.

Impatto dell'aggiornamento

• All'avvio Mate crea una tabella nuova, addresses. Niente di quello già salvato viene migrato,
  ricalcolato o cancellato.
• L'interruttore nuovo parte com'era «Scrivi la nota da sola», perché nella 4.12.1 è quella nota
  automatica che mandava gli estremi di un viaggio al servizio di ricerca: un'installazione che l'aveva
  spenta non manda nulla da sola, le altre continuano a mandare la partenza e l'arrivo di ogni viaggio
  nuovo, come prima. Da lì in poi i due interruttori sono separati.
• Mate non scrive più da solo la nota di un viaggio. La nota automatica dei viaggi (indirizzo, orario
  e temperatura) e il 🧭 accanto alla nota non ci sono più; Scrivi la nota da sola ora vale solo per
  le ricariche. Le note scritte prima restano come sono.
• I viaggi più vecchi di tre giorni al momento dell'aggiornamento non hanno una ricerca propria: i loro
  estremi mostrano «—» finché non si preme il 🧭 o un viaggio più nuovo parte o arriva nello stesso punto.
• La demo porta con sé i suoi indirizzi e non chiede niente a nessuno.

Verifica

• CI verde sul tag: 5.472 passati, 1 saltato (un test che ha bisogno di un file solo locale), più
  48 sul job Windows; il controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti — così che non si
  salti niente: 5.473 passati.
• I test nuovi e modificati, fatti girare sulla 4.12.1, danno 7 fallimenti e 10 errori (la ricerca e la
  sua tabella lì non esistono); adesso passano tutti e 138. Quattro rotture fatte apposta del codice
  nuovo — nessun controllo dell'interruttore, l'interruttore sempre acceso dopo l'aggiornamento, la scheda
  delle Impostazioni che non lo salva, il 🧭 che obbedisce all'interruttore — fanno diventare rosso ognuna
  uno di loro.
• In Chromium, su una copia di un database vero senza rete e con il servizio sostituito da uno finto, e
  sulla demo, a 1280 e 390 px: le righe dei viaggi, il Riepilogo del viaggio ed Eventi nominano i due
  estremi; la ricerca trova i viaggi da un luogo; il CSV ha le due colonne nuove; nessun errore nuovo
  negli script. Un database dove «Scrivi la nota da sola» non era mai stato toccato parte con
  l'interruttore nuovo acceso; uno dove era spento parte con l'interruttore spento e non manda nulla
  aprendo Viaggi. Con l'interruttore spento, il 🧭 su un viaggio di settembre ha fatto 2 richieste e ha
  disegnato i due indirizzi. La scheda delle Impostazioni spegne e riaccende l'interruttore senza toccare
  quello della nota. Senza rete la prima ricerca fallisce e aspetta 15 minuti; il 🧭 lascia allora i
  trattini, senza messaggi.
• L'immagine Docker, costruita da questo commit, ha girato sull'istanza di prova con un database vero
  prima del tag: ogni pagina risponde, l'interruttore nuovo è acceso dopo l'aggiornamento, la pagina del
  viaggio mostra le righe degli estremi e il 🧭, il CSV ha le due colonne nuove, e il primo giro ha chiesto
  a Nominatim 4 punti e li ha trovati tutti e 4.
• Non provati: un telefono vero, Safari, Firefox, e l'add-on dentro Home Assistant.