Skip to content
qr3.app Docs

Changelog

Changelog

A legutóbbi kiadások válogatott fénypontjai. A teljes API-verziókért és a visszamenőleges kompatibilitást érintő változások (Breaking Changes) irányelveiért lásd az API-verziókezelés és LTS-irányelvek oldalt.

Részletes változások az egyes végpontokon (endpoints): OpenAPI-specifikáció és interaktív API-referencia.

2026-10 · Színek a Dashboardon

  • Új: Egy kód részletes oldalán megjelent a Színek kártya: előtér és háttér hex-értékként, átlátszó háttér, előnézet a valódi képútvonalon keresztül. Az ellenőrzés ugyanaz, mint a PATCH /v1/codes/{id} esetén: a kritikus párokhoz megerősítés kell, az 1,5:1 alatti párok nem menthetők.
  • A visszaállítás fekete-fehérre mind a négy formátumban ismét ugyanazokat a bájtokat adja, mint színek nélkül. A színek nélküli kódok nem változnak.
  • Az átlátszó kódok a Dashboard minden előnézetében sakktábla-mintán jelennek meg. Részletek: Színek a Dashboardon.

2026-10 · Színek PDF és EPS formátumban

  • Új: A qr.pdf és a qr.eps kirajzolja az fg és bg értékeket paraméterként és mentett színként is. A fekete és minden szürke árnyalat szürkeárnyalatosként (csak fekete lemez) kerül mentésre, minden más szín pedig egész százalékos CMYK-ként, például a 1F4E79 mint C74 M36 Y0 K53.
  • Háttér, mint az SVG esetében: Amint kiválasztásra kerül egy szín, egy fedő terület jelenik meg a kód és annak csendes zónája mögött, fehér vagy bg színben. A bg=transparent nem rajzol semmit. A cím fekete marad, a logólemez pedig fehér.
  • Nincs változás színek nélkül: Az fg/bg és mentett színek nélkül mindkét formátum ugyanazokat a bájtokat adja vissza, mint korábban. A termékútlevél PDF-je színezetlen marad.
  • Korlátok: nincs ICC-profil, nincs PDF/X. Részletek: Színek a nyomtatásban.

2026-09 · Statikus kódok átirányítási gyorsítótár nélkül, egyidejű törlés

  • Módosítva: A statikus kódok már nem szerepelnek az átirányítási gyorsítótárban. A rövid linkjük (redirect_url) meghívása mindig az aktuális állapotot olvassa be. Ezért a DELETE /v1/account után egy statikus kód a következő meghíváskor már nem irányít át, míg korábban ez akár 24 óráig is eltarthatott. A díjcsomagváltás is azonnal érvénybe lép a statikus kódok esetében. A fiók törlése a dinamikus kódokat a korábbiaknak megfelelően eltávolítja. A kinyomtatott statikus kódok közvetlenül tartalmazzák a céljukat, így ezeket nem érinti a változás.
  • Javítva: Két egyidejű DELETE /v1/codes/:id hívás ugyanarra a kódra egyszer 200-as, egyszer pedig 404-es választ ad vissza. A qr.deleted webhook pontosan egyszer kerül elküldésre, a korábbi kettő helyett.
  • Új: A POST és a DELETE /v1/codes/:id/logo 409 (errors/conflict) hibakóddal válaszol, ha egy másik kérés egyidejűleg módosította ugyanazon kód logóját, és ilyenkor nem történik változtatás. Korábban előfordulhatott, hogy egy feltöltött logó használaton kívül mentve maradt. Két egyidejű DELETE /v1/codes/:id/logo hívás mindkét esetben 200-as választ ad vissza. Részletek: Logó.

2026-09 · TypeScript-SDK 1.2.0

  • Újdonság a @qr3/sdk 1.2.0 verziójában: A client.codes.update() elfogadja az appearance paramétert, és a kontrasztellenőrzés megállapításait issues mezőként adja vissza az eredményben; megállapítás hiányában ez a mező hiányzik. A client.codes.imageUrl() elfogadja az fg, bg és ecc paramétereket. Minden kód, amelyet az API visszaad (get, list, create, update, batchCreate), tartalmazza a title és appearance mezőket.
  • Frissítés: npm install @qr3/sdk@latest. A Python, Go és PHP verziók következnek. Részletek: SDK-k és CLI és Színek mentése a kódban.

2026-09 · A módosított lejárati idő körülbelül egy percen belül érvénybe lép

  • Javítva: Az expires_at mezőre küldött PATCH kérés mostantól üríti a kód átirányítási gyorsítótárát. Az új lejárati idő így körülbelül egy percen belül érvénybe lép, ahelyett, hogy akár 24 órával később lépne életbe. Korábban egy eltávolított vagy elhalasztott lejárat akár 24 órán át továbbra is 410-es kódot adott vissza, a mostanra beállított lejárat pedig akár 24 órán keresztül engedte tovább működni az átirányítást.
  • Javítva: Az expires_at értékkel létrehozott kód akkor is pontosan jár le, ha a lejárat az első 24 órán belülre esik.
  • Javítva: Ha egy kódot törölnek, miközben a logóját éppen feltöltik vagy eltávolítják, a POST és a DELETE /v1/codes/:id/logo kérések 404-es kóddal válaszolnak, és nem módosítják a törölt kódot, a PATCH kéréshez hasonlóan.
  • Javítva: Az a statikus kód is bekerül az átirányítási gyorsítótárba, amelynek a rövid linkjét (redirect_url) meghívták. A módosítás, a szüneteltetés és a törlés mostantól ezt is üríti, nem csak a dinamikus kódok esetében.

2026-09 · Színek mentése a kódhoz

  • Új: A PATCH /v1/codes/:id elfogadja az appearance paramétert a foreground_color és background_color értékekkel (#RRGGBB, a háttér transparent is lehet). A qr.svg és a qr.png paraméterek nélkül is a mentett színekkel rajzol; az olyan lekérdezési paraméterek, mint a ?fg=000000, továbbra is elsőbbséget élveznek. A PDF és az EPS formátumok csak egy későbbi kiadásban fogják támogatni a színek kirajzolását.
  • Kontrasztellenőrzés: Egy 1,5:1 alatti páros 422 hibát eredményez. A gyengébb párosok mentésre kerülnek, és a meta.issues mezőben warning vagy critical jelöléssel szerepelnek; a transzparens háttér mindig critical, de soha nem tiltott.
  • Összefésülés: A kihagyott mezők megtartják a mentett értéküket, a null visszaállítja azokat. Az ugyanazon a kódon végzett egyidejű módosítások már nem írják felül egymást.
  • Minden kód-válaszban: Az appearance szerepel minden kód-válaszban, valamint a qr.created és qr.updated webhookokban. A POST, a batch és az import 422 hibával elutasítja azt.
  • Nincs változás a meglévő kódoknál: Mentett színek nélkül minden kód ugyanazokat a bájtokat adja vissza, mint korábban. Részletek: Színek mentése a kódhoz.

2026-09 · Színek és hibajavítás mint a képútvonalak paraméterei

  • Új: Mind a négy képútvonal elfogadja az fg (előtérszín), bg (háttérszín vagy transparent) és ecc (hibajavítás: L, M, Q, H) paramétereket. Az SVG és a PNG kirajzolja a színeket; a PDF és az EPS elfogadja őket, de csak egy későbbi verzióban fogja kirajzolni. Az ecc mind a négy formátumban működik, a logó továbbra is H értéket kényszerít ki.
  • Transzparens: A bg=transparent háttér nélküli SVG-t és valódi alfacsatornával rendelkező PNG-t eredményez. Az aljzatnak világosnak kell lennie, és a csendes zónát szabadon kell hagyni.
  • Soha nem hiba: Az érvénytelen értékeket figyelmen kívül hagyja a rendszer; a kép pontosan úgy jelenik meg, mint paraméterek nélkül.
  • Gyorsítótár: Minden ténylegesen alkalmazott paraméter Cache-Control: public, max-age=300 fejlécet ad vissza az alapértelmezett kép 24 órás időtartama helyett.
  • Nincs viselkedésbeli változás paraméterek nélkül: Minden meglévő kód mind a négy formátumban ugyanazokat a bájtokat adja vissza, mint korábban.
  • Minden díjcsomagban elérhető. Részletek: Színek és hibajavítás.

2026-09 · A PDF és az EPS mostantól szintén beágyazza a logót

  • Bővítés: A qr.pdf és a qr.eps mostantól ugyanúgy beágyazza a beállított logót, mint a qr.svg és a qr.png (lásd alább) — beágyazott képként (PDF esetén egy Image XObject segítségével, EPS esetén egy PostScript kép-szótáron keresztül, ott csak %%LanguageLevel: 3 szinttel), ugyanazon a területen középre igazítva, a hibajavítás azonos módon H szintre emelésével. Mindkét formátum eddig nem tartalmazta a logót; ez most javításra került.
  • Gyorsítótár: Beállított logó esetén mostantól a qr.pdf és a qr.eps is a Cache-Control: public, max-age=300 fejlécet adja vissza a megszokott 24 óra helyett — pontosan úgy, mint az SVG/PNG.
  • Fallback: Ha maga a logókép nem dolgozható fel (például egy sérült mentett objektum miatt), a hibajavítás H szintű marad, de a fenntartott terület üresen marad a kép helyett — ez soha nem okoz szerverhibát.
  • Nincs változás logó nélkül: A logó nélküli kódok továbbra is bájt-azonos qr.pdf/qr.eps fájlokat adnak vissza, változatlan 24 órás gyorsítótárral.
  • Részletek és nyomtatási útmutató: Logó a QR-kódban.

2026-09 · Logo a QR-kódban — Dashboard és API

  • Új: Egy kód mostantól egy középen elhelyezett logót is tartalmazhat. A Dashboard-on egy kód részletes oldala egy saját logó-kártyát hoz létre: Logó kiválasztása, az első hozzáadáskor vagy az eltávolításkor egy kötelező jelölőnégyzettel ellátott figyelmeztetés megerősítése (mindkettő megváltoztatja a pontmintázatot), majd Logó feltöltése/Logó eltávolítása. A Csere nem igényel megerősítést — csak a kép változik, a mintázat nem. A viewer szerepkör látja az állapotot és az előnézetet, de a három művelet egyikét sem.
  • API: A POST /v1/codes/{id}/logo (multipart mező: file; PNG, JPEG vagy WebP, legfeljebb 1 MB, az SVG elutasításra kerül) létrehoz egy logót vagy lecseréli azt; a DELETE /v1/codes/{id}/logo eltávolítja azt, és idempotens. A túl nagy kép 413-as, a nem támogatott formátum 422-es, a viewer szerepkör pedig 403-as hibát ad vissza.
  • Megjelenítés: A qr.svg és a qr.png valódi képpontokként ágyazza be a logót (512 × 512, normalizált), és ehhez a hibajavítást H szintre emeli. A hozzáadás és az eltávolítás így megváltoztatja a pontmintázatot (M ↔ H), a csere viszont nem. A qr.pdf és a qr.eps nem ágyaz be logót, és változatlan marad. A már kinyomtatott kód minden esetben továbbra is működik, mivel a kódolt cél nem függ a logótól — csak annak kell újra nyomtatnia, aki a (új) logó megjelenését az anyagon is látni szeretné, és eközben nem keveri a régi és az új nyomtatási fájlokat.
  • Gyorsítótár: Beállított logó esetén a qr.svg és a qr.png a Cache-Control: public, max-age=300 fejlécet adja vissza a megszokott 24 óra helyett. Részletek, határértékek és nyomtatási útmutató: Logo a QR-kódban.

2026-08 · operationId mind a 75 művelethez, és egy „mikor használjuk” útmutató ágenseknek

  • Kiegészítés: Az OpenAPI-specifikáció mind a 75 művelete rendelkezik most már egy operationId azonosítóval — listCodes, createCode, getCodeStats, archiveWorkspace és így tovább. Eddig ez a mező teljesen hiányzott, így minden generátornak a HTTP-metódusból és az útvonalból kellett levezetnie a metódusnevet (postV1Codes). Az ilyen nevek az útvonaltól függenek, és minden útvonal-átalakítással változnak. A névformátum mind a 75 helyen azonos: list/get/create/update/replace/delete, egyébként az üzleti művelet igéje (validateDpp, registerGs1Identifier, pingWebhook). Az ige az üzleti logikát követi, nem a HTTP-metódust — az archiveWorkspace egy DELETE, az importDpps egy POST.
  • Hatás a saját generálású kliensekre: Azok, akik a specifikációból generálják az SDK-jukat, a következő futtatáskor átnevezett metódusokat kapnak (postV1Codes → createCode). Ez a változtatás célja, de ez egy átnevezést jelent a külső kódban — ezért említjük meg itt kifejezetten. Az útvonalak, paraméterek, válaszformátumok és állapotkódok változatlanok; a hivatalos SDK-k, a CLI és az MCP-szerverek nem érintettek.
  • Belépési pont ágenseknek: A https://qr3.app/llms.txt tartalmaz egy ## When to use qr3.app szakaszt — hat feladattal a hat funkció helyett, plusz azt a mondatot, hogy mire nem a qr3.app a megfelelő eszköz. Ugyanezt az információt nyújtja most az MCP-szerver is a kézfogás során: az initialize a https://mcp.qr3.app/mcp címmel szemben egy instructions mezővel válaszol (korábban: tizenegy eszköz mindenféle besorolás nélkül). Azt is tartalmazza, hogy mely hívásokhoz szükséges API-kulcs — az initialize és a tools/list hívásokhoz nem, de minden tools/call hívásnál igen.
  • Javítások a llms.txt fájlban: Négy adatot ellenőriztünk az éles környezettel szemben, és nem bizonyultak helytállónak: (1) a qr3app Python SDK nincs közzétéve a PyPI-n — a pip install sor pótlás nélkül kikerült; (2) az Accept: text/markdown a kezdőlapra és a blogra vonatkozik, nem minden szerveroldalon renderelt oldalra; (3) a kapcsolattartási cím [email protected], a kezdőlap JSON-LD-jében is; (4) a /de/security/ egy horgonyra való átirányítás, nem önálló oldal. Új link: docs.qr3.app/de/skills/.
  • Biztosítás: Három ellenőrzés az openapi-spec.test.ts fájlban — hiánytalanság, egyediség, lowerCamelCase —, mindegyik mutációval ellenőrizve. További kilenc teszt rögzíti a négy javított adatot, hogy azok ne térhessenek vissza.
  • Ismert korlátozás: A 75 művelet közül kettő szerepel a specifikációban, de 404 választ ad (GET /v1/codes/{id}/stats és GET /v1/account). Itt kaptak egy nevet, és el is veszítik azt, amint eldől, hogy megépülnek vagy törlésre kerülnek.

2026-08 · A csomag-visszaminősítések és lemondások mostantól a limitekre is érvényesek

  • Javítás: A Stripe-webhook csomagváltáskor és lemondáskor korábban csak a csomag nevét írta be, a szervezet négy limitoszlopát (max_workspaces, max_members, max_dynamic_codes, max_scans_per_month) nem. Mivel az érvényesítés a mentett érték és a csomag-baseline közül a maximumot veszi alapul, a visszaminősített vagy lemondott szervezet megtartotta a régi, magasabb limitjeit — így a visszaminősítés hatástalan maradt. A webhook mostantól minden tényleges csomagváltáskor az új csomag baseline-jára, lemondáskor pedig a Free-baseline-ra állítja be az oszlopokat — pontosan úgy, ahogy az adminisztrációs felület már eddig is tette.
  • Működés: Az előfizetés rutinszerű frissítései (meghosszabbítás, fizetési mód, proration) továbbra sem érintik a limiteket; az egyedileg megadott magasabb limitek változatlanul megmaradnak. Csak egy tényleges csomagváltás állítja vissza őket az új csomag baseline-jára.
  • Hatás: Nincs változás az API-ban vagy a válaszformátumban. Azok a szervezetek, amelyek visszaminősítése ezen javítás előtt történt, megtartják a régi értékeket, amíg a következő csomagváltás életbe nem lép, vagy a support nem módosítja azokat.

2026-08 · Keyset kurzor mostantól minden lista-végponton

  • Javítás: A GET /v1/codes és GET /v1/dpp végpontokhoz készült kurzor-javítás (lásd alább) mostantól az összes többi kurzor-lapozású listára is kiterjesztésre került: GET /v1/qr-codes/:id/comments, /v1/workspaces, /v1/gs1/identifiers, /v1/members, /v1/audit-logs, /v1/admin/orgs, /v1/admin/users és /v1/webhooks/:id/deliveries. Mindegyik kizárólag a created_at mező alapján lapozott; az azonos időbélyeggel rendelkező sorok (egy kötegelt művelet audit bejegyzései, Webhook-újrapróbálkozások, tagok importálása) elveszhettek a következő oldalon. A rendezési kulcs mostantól mindenhol a (created_at, id) pár.
  • API-változás: Ezeken a listákon a meta.pagination.next_cursor mostantól szintén egy opak (nem átlátszó) érték (base64url) a puszta időbélyeg helyett; az olvashatatlan kurzorok 400-as hibát adnak vissza, a régi időbélyeg-kurzorokat átmenetileg továbbra is elfogadjuk. Kivétel a GET /v1/webhooks/:id/deliveries: ott a next_cursor továbbra is az utolsó kézbesítés azonosítója marad (ismeretlen azonosító → első oldal). Azoknak a klienseknek, amelyek a next_cursor értéket változatlanul küldik vissza — Vezérlőpult, CLI, SDK-k, MCP —, nem kell semmit sem változtatniuk.
  • Hatás: Nincs szükség migrációra. Ha valaki hiányolt bejegyzéseket a lapozás során ezen listák valamelyikében (pl. az audit naplóban vagy a kézbesítési naplóban a Vezérlőpulton): Soha nem tűntek el — a listák mostantól teljes egészében megjelenítik őket.

2026-08 · Az időbélyegek szerkesztés és törlés után újra OpenAPI-konformak

  • Javítás: A PATCH /v1/codes/{id} hívás után az updated_at SQLite formátumban, időzóna nélkül tért vissza (2026-08-17 09:00:00), bár az OpenAPI-specifikáció a format: date-time formátumot ígéri, és a létrehozás (POST) az ISO időbélyeget (2026-08-17T09:00:00.000Z) adja vissza. Ugyanez vonatkozott a deleted_at/updated_at értékekre soft-delete esetén, valamint az API-kulcsok, szervezetek, Workspace-ek, tagok, megjegyzések és webhookok szerkesztési/törlési útvonalaira, továbbá az API-kulcsok last_used_at és a webhookok last_triggered_at értékeire. Mostantól minden írási útvonal ISO 8601 (UTC, T és Z) formátumú időbélyeget használ.
  • Hatás: Azok a kliensek, amelyek az updated_at értéket a new Date(...) függvénnyel elemzik (SDK-k, CLI, Vezérlőpult), a szóközös formátumot helyi időként értelmezték — a CLI az egyszer már szerkesztett kódoknál a helyi eltolódással eltolt időt mutatta (Bécs: −2 h). Ez javításra került. Emellett egy adatmigráció normalizálja a már elmentett, régi formátumú értékeket ISO formátumra, hogy a rendezés és az összehasonlítás a vegyes adatokban is helyes legyen. A mezőnevek és a válaszstruktúra nem változott.
  • Háttér: Ugyanaz a hibaosztály, mint az alábbi két javítás (API-kulcs lejárata, újraszkennelési cutoff): az SQLite datetime('now') függvénye YYYY-MM-DD HH:MM:SS formátumban ír, míg az összes többi író ISO 8601 formátumot használ. Egy forráskód-védelmi teszt (guard test) a jövőben megakadályozza az újabb előfordulásokat.

2026-08 · A listás lapozás többé nem veszít el batch kódokat

  • Javítás: A GET /v1/codes és a GET /v1/dpp kizárólag a created_at alapján lapozott. A POST /v1/codes/batch, POST /v1/dpp/batch végpontokból és a CSV/XLSX-importból származó kódok azonban egyetlen időbélyegen osztoznak — amint egy batch nagyobb volt, mint a limit (alapértelmezetten 20), a második oldal már nem adta vissza az ugyanahhoz az időbélyeghez tartozó többi sort. A kódok léteztek és elérhetők voltak a GET /v1/codes/:id útvonalon, de a listában (Vezérlőpult, CLI qr3 list, SDK-k, MCP) soha nem jelentek meg. A kurzor mostantól egy keyset a (created_at, id) felett.
  • API-változás: A meta.pagination.next_cursor mostantól egy opak érték (base64url) a puszta időbélyeg helyett. Azoknak, akik a kurzort változatlanul adják vissza ?cursor= paraméterként — ahogyan a Vezérlőpult, a CLI, az összes SDK és az MCP-szerver is teszi —, semmit sem kell változtatniuk. A régi időbélyeg-kurzorokat átmenetileg továbbra is elfogadjuk; az olvashatatlan kurzorok mostantól 400-as hibát adnak vissza ahelyett, hogy csendben az első oldalt adnák vissza.
  • Hatás: Ha egy batch-import után kevesebb kódot láttál a listában, mint amennyi létrejött: a kódok soha nem tűntek el — a lista mostantól hiánytalanul megjeleníti őket. Nincs szükség migrációra.

2026-08 · A biztonsági újraszkennelések ismét 24 órás ütemben futnak

  • Javítás: A cél-URL-ek és a landing page-linkek időszakos újraszkennelése (Google Web Risk) kihagyta azokat a kódokat, amelyek utolsó szkennelése ugyanarra a naptári napra esett, mint a 24 órás cutoff — az időponttól függően az újraszkennelés akár egy további nappal is késhetett. A cutoff kiszámítása mostantól ugyanabban az ISO-formátumban történik, amelyben a szkennelési időbélyegek tárolva vannak.
  • Hatás: Ha egy cél-URL az utolsó szkennelés után nem biztonságosnak minősül, az ismét a dokumentált 24 órás időablakon belül a kód automatikus szüneteltetését eredményezi. Nincs változás az API-ban vagy a válaszformátumban.

2026-08 · Az API-kulcsok lejárnak a lejárati időpontban

  • Javítás: Azokat az API-kulcsokat, amelyek expires_at értéke az adott napra esett, UTC szerint éjfélig továbbra is elfogadta a rendszer. A lejárat összehasonlítása mostantól időbélyegként történik karakterlánc helyett — a lejárt kulcsok azonnal 401-es hibát adnak vissza.
  • Háttér: Az expires_at érték ISO-időbélyegként van tárolva (2026-08-14T09:00:00Z), míg az összehasonlító oldal szóközös formátumot adott vissza (2026-08-14 09:00:00). A nyers karakterlánc-összehasonlítás ezért csak akkor működött helyesen, ha már a dátum is eltért.
  • Hatás: Nincs szükség migrációra, a GET /v1/api-keys válaszformátuma változatlan marad. Az olvashatatlan lejárati értékek mostantól lejártnak minősülnek az érvényes helyett.

2026-08 · API-referencia: Tenant-kezelés dokumentálva

  • OpenAPI: A specifikáció — és ezáltal az interaktív referencia — mostantól dokumentálja a szervezeteket (beleértve a GET /v1/organizations/usage végpontot), a Workspace-eket, a tagokat és szerepköröket, valamint az Audit-logokat.
  • Billing: A díjcsomag-áttekintés (GET /v1/billing/plans) nyilvános; a Checkout (POST /v1/billing/checkout) és a Stripe-ügyfélportál (GET /v1/billing/portal) a szervezet adminisztrátorai számára fenntartott végpontokként vannak megjelölve.
  • Scan-export: A beolvasási statisztikák (GET /v1/codes/{id}/scans) és a nyersadat-export (…/scans.csv, …/scans.xlsx) teljes körűen dokumentálva vannak — beleértve a GDPR-tájékoztatást: az ip_hash soha nem szerepel az exportban.
  • Hibakezelés: Újonnan dokumentálásra került a kérés-validáció 400-as válasza is: a törzs a nyers Zod-hiba, nem egy RFC-7807 problémadokumentum — ennek ellenére az application/problem+json Content-Type fejléccel kerül kiküldésre.

2026-08 · Nyilvános fájlhivatkozások másolása

  • Dashboard: A kód részletező oldalán található nyilvános fájlok mostantól rendelkeznek egy gombbal, amely a nyilvános hivatkozásukat a vágólapra másolja – ez közvetlenül használható egy QR-kód cél-URL-jeként, ha a beolvasásnak azonnal egy adott dokumentumot kell megnyitnia a fájllistát tartalmazó landing page helyett.
  • API: A fájl-végpontok (/v1/files) mostantól a public_url mezőt is visszaadják. Ez a mező csak a visibility: public beállítású fájloknál van kitöltve – a privát fájlok nem kapnak nyilvános címet.
  • Működés: A hivatkozás nem igényel bejelentkezést, és közvetlenül a böngészőben nyitja meg a fájlt. A fájl lecserélése változatlanul hagyja a hivatkozást, így a rá nyomtatott kód érvényes marad. Részletek: Fájlok és adatlapok.

2026-07 · Csapatszerepkörök: Szerkesztő törlés nélkül és Admin számlázás

  • Új: Szerkesztő (törlés nélkül) tagi szerepkör — QR-kódokat, fájlokat és Digital Product Passport-okat hozhat létre és szerkeszthet, de nem törölhet semmit, és nem hozhat létre API-kulcsokat. Minden destruktív végpont szerveroldalon ellenőrzi a szerepkört (403).
  • Számlázás: A csomag-upgrade-ek és a Stripe ügyfélportál (POST /v1/billing/checkout, GET /v1/billing/portal) mostantól a szervezet adminisztrátorai (Organisations-Administratoren) számára vannak fenntartva — az összes többi szerepkör egy írásvédett csomagáttekintést lát.
  • Dashboard: A saját szerepkör által nem engedélyezett műveletek elrejtésre kerülnek: Egy Olvasó (Betrachter) például nem látja a létrehozásra, szerkesztésre vagy törlésre szolgáló gombokat; a listák, letöltések és statisztikák láthatóak maradnak. Részletek: Csapat és szerepkörök.

2026-06 · Külső hivatkozások a kód landing page-én

  • Landing page: A qr3 által hosztolt landing page mostantól képes külső, saját hosztolású hivatkozásokat ({ label, url }) is listázni – a feltöltött fájlok mellett vagy azok helyett, például a saját webhelyen található adatlapokhoz.
  • API: A POST/PATCH /v1/codes végpontok elfogadnak egy links tömböt (0–20 bejegyzés, http(s), ≤ 2048 karakter). Minden URL-t ellenőriz a Google Web Risk; a nem biztonságos URL-ek 422-es hibát adnak vissza. Egy üres tömb törli az összes hivatkozást.
  • Dashboard: Hivatkozások hozzáadása, rendezése és eltávolítása a kód részletező oldalán.
  • Biztonság: A renderelt hivatkozások XSS-biztosak maradnak (escaped, csak http(s)), és az oldal megtartja a noindex fejlécét.

2026-04 · Dashboard-Analytics QR-kódonként

  • Dashboard: A QR-kód listában található Analytics gomb mostantól megnyitja az adott QR-kód statisztikai oldalát a /dashboard/codes/{id} útvonalon.
  • Routing: A /dashboard/codes alias továbbra is átirányít a /dashboard oldalra, de már nem kapja el a részletes útvonalakat, mint például a /dashboard/codes/{id}.
  • API: A részletező oldal közvetlenül a GET /v1/codes/:id hívással tölti be a QR-kódot; ezáltal már nem függ a listázási lapozási (pagination) korlátoktól.
  • Tesztek: A regressziós tesztek lefedik az alias-átirányítást és a közvetlen kód-betöltést.

2026-04 · Dashboard törlési párbeszédpanel QR-kódokhoz

  • Dashboard: A QR-kód listában lévő kuka ikon mostantól egy saját React párbeszédpanelt (dialog) nyit meg a natív böngészős felugró ablak (popup) helyett.
  • Visszajelzés: Törlés után egy toast értesítés jelenik meg a sikerről vagy a hibáról.
  • Tesztek: A packages/dashboard/tests/dashboard.test.ts megakadályozza a regressziókat a confirm() hívásra a QR-kód törlési folyamatában.

2026-04 · Dashboard rövid link teszt dinamikus QR-kódokhoz

  • Dashboard: A QR-kód listában szereplő shortcode-ok mostantól közvetlenül kattintható külső átirányítási (redirect) linkekként működnek. A külső link ikon például a wu3qaa mellett megnyitja a https://qr3.app/{shortCode} címet egy új lapon.
  • i18n: Bővítettük a tooltip szövegeket német és angol nyelven.
  • Tesztek: A packages/dashboard/tests/dashboard.test.ts védi a link href-et, az új lapon való megnyitást, a noopener noreferrer attribútumot és az ikont a regressziókkal szemben.

2026-04 · Redirect-Worker útvonal dinamikus QR-kódokhoz

  • Javítás: A https://qr3.app/{shortCode} alatti dinamikus QR-kódokat ismét a redirect-worker dolgozza fel. A production útvonal mostantól a qr3.app/* mintát használja, mivel a Cloudflare Worker útvonalak nem támogatják a :code útvonal-paramétereket.
  • Megerősítés: A nem egyező útvonalak továbbításra kerülnek a landing-origin felé, hogy a normál oldalakat, mint például a /de/pricing, ne blokkolja a redirect-worker.
  • Tesztek: A packages/redirect/tests/unit/redirect.test.ts ellenőrzi a wildcard útvonalat, a shortcode feldolgozást és az origin-pass-through működését.

2026-04 · Workspace DPP beolvasási áttekintés (Q3.4.2)

  • Új: GET /v1/workspace/stats/dpp?days=30 — összesíti az API-key workspace összes dpp_scans adatát (active_dpps, scans_by_day, top_dpps terméknévvel/kategóriával).
  • Dashboard: Kártya a kezdőlapon (/dashboard) 30 napos oszlopdiagrammal + toplistákkal — a QR-kód kártyákkal párhuzamosan.
  • Nyilvános: Marketing shortlink GET /dpp/dpp_<id> (egy szegmens) élő demókhoz, a /dpp/{gtin}/{serial} útvonallal párhuzamosan.

2026-04 · DPP beolvasási analitika (Q3.4.1)

  • Új: GET /v1/dpp/:id/stats?days=30 — a nyilvános GS1-resolver összesített beolvasásai DPP-nként. Mezők: total_scans, period_scans, scans_by_day, top_countries, top_devices, top_representations.
  • Új: dpp_scans tábla (migráció: 0011) — elkülönítve a scans táblától (redirect-worker). Az IP-címek naponta változó (rotáló) salt segítségével kerülnek hashelésre, a nyers IP-címek soha nem érik el a D1-et.
  • Dashboard: Mini diagramkártya (SVG, diagramkönyvtár nélkül) a /dashboard/dpp/:dppId oldalon 30 napos oszlopokkal + top 3 lebontással. Empty-state (üres állapot) jelenik meg, amint egy DPP éles, de még nem volt beolvasása.

2026-04 · Élő EU-megfelelőségi szimulátor (Q3.3.7)

  • Új: POST /v1/dpp/:id/validate-update — részleges frissítéseket szimulál stateless módon (státusz, piaclista, …) perzisztencia nélkül. A válasz tartalmazza az eu_compliance + preview.changed_fields adatokat.
  • Dashboard: Szimulátor kártya a DPP részleteiben (/dashboard/dpp/:dppId) — chipek a DE/AT/FR/IT/ES/NL + egyéni értékekhez, státusz legördülő menü, Preview EU impact / Save changes / Reset. Nem blokkoló működés Remix useFetcher segítségével.
  • Megerősítés: Kiszervezett szimulátor segédfunkciók (readUpdatePatchFromForm, marketCountriesKey) + 18 új unit teszt; hibajavítás: az egyedülálló, nem ISO formátumú bemenet már nem törli a piaclistát.

2026-04 · Élő EU-megfelelőségi előnézet a létrehozási űrlapon (Q3.3.6)

  • Módosítva: A POST /v1/dpp/validate mostantól az eu_compliance adatot is visszaadja — ugyanaz a validátor, mint a GET /v1/dpp/:id/eu-compliance, stateless módon a mentés előtt.
  • Dashboard: Előnézet a meglévő validációs panel alatt + új Save-Guard-Banner a beküldő gombok előtt, ha hibák/figyelmeztetések vannak (i18n többes szám kezelés DE/EN).

2026-04 · EU-validátor + Textil UI (Q3.3.4 + Q3.3.5)

  • Új: EU-megfelelőségi validátor 5 textilipari szabállyal (TEXTILE_AGEC_REQUIRED, TEXTILE_MICROPLASTICS_CONSISTENCY, TEXTILE_SVHC_THRESHOLD, TEXTILE_GREENWASHING, TEXTILE_ESPR_READY).
  • Új: GET /v1/dpp/:id/eu-compliance a következő mezőkkel: compliant / espr_ready / issues[] / summary.
  • Dashboard: EU-megfelelőségi szakasz a DPP részleteiben (összegző kártyák, csoportosított Issue-kártyák, ESPR-Ready-Badge a fejlécben).

2026-04 · Textil DPP-séma (Q3.3.1–Q3.3.3)

  • Új: textile kategória kötelező AGEC-lánccal (szövés/kötés → festés/nyomás → konfekcionálás), szálankénti origin_country + recycled_pct, svhc_substances[], ESPR-opt-in (PEF, élettartam, újrahasznosíthatóság).
  • Új: Alapvető market_countries: string[] mező (ISO 3166-1 alpha-2) minden DPP kategórián — vezérli a Franciaország-specifikus AGEC-szabályokat és a kötelező francia fogyasztói tájékoztatót.
  • Új: Fogyasztói HTML-sablon AGEC mikroműanyag-figyelmeztető dobozzal, 3 lépcsős származási lánccal (zászló-pille ikonok), SVHC-listával, tartóssági (durability) és újrahasznosíthatósági (recyclability) szakasszal.
  • Migráció: 0010_dpp_market_countries (D1).

2026-04 · DPP tömeges import (Q3.2.1–Q3.2.5)

  • Új: A POST /v1/dpp/import elfogad CSV és XLSX formátumokat (Worker-kompatibilis a SheetJS xlsx segítségével, ~283 KB gzip csomagméret).
  • Skálázott: csomagalapú korlát (Free 100 → Enterprise 10k) + darabolt (chunked) db.batch() 100-asával + 5 MB-os kéréstörzs-korlát (body-limit).
  • Új: Hibajelentés CSV formátumban a 201-es válasz errors_csv mezőjében; a GET /v1/dpp/import/templates/:category?format=csv|xlsx kész sablonokat biztosít az akkumulátor (battery) és textil kategóriákhoz.
  • Dashboard: Drag-and-drop feltöltés a /dashboard/dpp/import oldalon sablon-proxyval és beágyazott (inline) CSV-letöltéssel.

Nem kompatibilitást törő (Non-Breaking) — LTS-bővítések

A fent említett változások mindegyike additív:

  • A meglévő POST /v1/dpp/validate kliensek változtatás nélkül figyelmen kívül hagyják az új eu_compliance mezőt.
  • A meglévő battery folyamatok változatlanok.
  • A market_countries opcionális, és alapértelmezetten [] értékű.

Lásd az API-verziókezelés oldalt a Breaking-Change irányelvekért.