Pás produktů, které si zákazník naposledy prohlížel, na nástěnce a pod výpisem kategorie. Historie se drží u účtu, přežije odhlášení i změnu zařízení. Jádro MasterShopu má tabulku, endpointy i pravidla viditelnosti hotové.
Odběratel se k produktům vrací. Chce je najít bez hledání v katalogu, i když se mezitím přihlásil z jiného počítače. Jádro MasterShopu k tomu má modul ProductsRecentlyViewed s tabulkou per zákazník a dvěma FrontAPI endpointy. Žádná obálka ani SFX ho zatím nepoužívá.
Kam patří. Jádro MasterShopu (větev front-api): tabulka, oba endpointy i systémová volba už existují, beze změny. Obálka: pás naposledy zobrazených a zápis zobrazení v SFX. Názvy nových tabulek a endpointů jsou pracovní, v jádru je pojmenuje programátor.
Jedna otázka pro klienta o počtu, jedna pro vývoj o limitu v jádře. Ani jedna neblokuje.
| # | Otázka a náš návrh |
|---|---|
| K1 | Kolik produktů má pás ukazovat? Návrh: 8 na nástěnce, 12 pod kategorií. Jádro si pamatuje 24, zobrazovaný počet je systémová volba. |
| # | Otázka |
|---|---|
| D1 | Jádro drží 24 produktů a maže po 30 dnech. Dokument inovací slibuje „přežije týden pauzy", to sedí. Stačí to, nebo se má expirace pro B2B prodloužit? Obojí je konfigurace modulu, ne kód. |
| D2 | Zápis z SFX: volat POST hned při otevření detailu, nebo sbírat v prohlížeči a poslat dávkou při odchodu ze stránky? Endpoint je merge, umí obojí. Navrhujeme hned při otevření, je to jednodušší a nezávislé na zavření karty. |
customer_recently_viewed_products (zákazník, produkt, čas), ne do prohlížeče. Jiné zařízení vidí totéž.customer_recently_viewed_products: customer_id, product_id, add_time. Existuje, migrace v modulu ProductsRecentlyViewed. Nic se nepřidává.POST /api-recently-viewed/products s jednou položkou: id produktu a čas zobrazení. D2
GET /api-recently-viewed/products a dostane produktové karty ve stejném formátu jako výpis kategorie.
Nesahat na modul ProductsRecentlyViewed v jádře. Limity a expirace jsou jeho konfigurace, viditelnost produktů řeší jeho dotaz.
Jedna nová komponenta pásu, dvě umístění, jedno volání navíc v detailu produktu. Karty produktů jsou stávající komponenty katalogu.
| Místo | Chování |
|---|---|
| Nástěnka (F03) | Blok „Naposledy jste si prohlíželi". Až 8 karet, na mobilu vodorovný posuv. Když je historie prázdná, blok ukáže větu „Zatím nic. Otevřete si detail produktu v katalogu." s odkazem. |
| Výpis kategorie | Pás pod výpisem produktů, nad patičkou. Až 12 karet. Bez historie se nevykreslí. |
| Detail produktu | Pás se NEZOBRAZUJE. Detail má alternativy a příslušenství, další pás by ho zahltil. Detail jen zapisuje. |
GET /api-recently-viewed/products. SFX jádro repozitář nemá, albi.eu obálka má jen vygenerované typy. Repository vzniká v obálce SFX.Nový je jen pás. Karty jsou stávající komponenta katalogu. Pořadí: nejnovější vlevo. Na mobilu vodorovný posuv, na desktopu čtyři karty v řadě.
Oba endpointy existují v jádru, modul FrontApi, skupina RecentlyViewed. Vyžadují JWT zákazníka.
| Endpoint | Stav | K čemu |
|---|---|---|
GET /api-recently-viewed/products | existuje | Vrátí produktové karty naposledy zobrazených produktů, jen ty aktuálně viditelné pro zákazníka. Varianta /{slug} vynechá jeden produkt. |
POST /api-recently-viewed/products | existuje | Merge položek items[{ id, viewedAt }]. Umí jednu i dávku. Jiný zápisový endpoint není. |
POST /api-recently-viewed/products
{ "items": [ { "id": 7701, "viewedAt": "2026-09-25T10:14:00+02:00" } ] }
Jedna systémová volba, kterou vidí jen superadmin. Bez ní endpointy nic neukládají.
visited_products_enabled). Zapnout pro každou ze čtyř prezentací B2B.Stávající obrazovka jádra, nic nového. Přesné názvy voleb jsou v konfiguraci modulu ProductsRecentlyViewed.