search

nvbach91 / 4IZ278-2023-2024-LS

4IZ278-2023-2024-LS
MIT License
2 stars 0 forks source link

davj05-sp #144

Open KubaDavid opened 7 months ago

KubaDavid commented 7 months ago

Kartio - Aplikace na generování a správu digitálních kartiček

Popis

Zákaznické kartičky jsou u obchodníků populární, ale stále se jedná o fyzické karty, které je nutné vydávat. Tato aplikace umožní obchodníkovi vydávat kartičky bez nutnosti vytvářet fyzickou kartu. Zároveň pak bude mít zákazník kartu rovnou v telefonem integrované peněžence / walletu a nebude muset instalovat nějaké speciální aplikace. Umožníme tak i menším prodejcům vydávat karty bez vyšších nákladů.

Funkce

Architektura

Usecase Diagram

usecase

Stránky

  1. Login
  2. Homepage (s kartičkami pro vydavatele, s vydavateli pro admina)
  3. Zobrazit kartu
  4. Upravit kartu
  5. Vytvořit kartu
  6. Zobrazit vydavatele
  7. Upravit vydavatele
  8. Vytvořit vydavatele

Wireframe

wf6 wf5 wf4 wf2 (1) wf1

DB Model

Untitled

Sekvenční diagram

sequenceDiagram
    participant Zákazník
    participant Webový_prohlížeč as "Webový prohlížeč"
    participant Controller as "Controller"
    participant Databáze as "Databáze"
    participant Autentizační_systém as "Autentizační systém"
    participant Apple_Wallet_Služba as "Apple Wallet Služba"
    participant Majitel_podniku as "Majitel podniku"

    Zákazník->>Webový_prohlížeč: Přihlásit se
    Webový_prohlížeč->>Controller: Poslat přihlašovací data
    Controller->>Autentizační_systém: Ověřit uživatele
    Autentizační_systém->>Controller: Potvrzení ověření
    Controller->>Webový_prohlížeč: Uživatel přihlášen
    Webový_prohlížeč->>Majitel_podniku: Zobrazit řídicí panel

    Majitel_podniku->>Webový_prohlížeč: Zadat údaje zákazníka pro novou věrnostní kartu
    Webový_prohlížeč->>Controller: Požádat o novou věrnostní kartu
    Controller->>Databáze: Kontrola údajů zákazníka
    Databáze->>Controller: Údaje zákazníka platné

    Controller->>Apple_Wallet_Služba: Požadavek na generování věrnostní karty
    Apple_Wallet_Služba->>Controller: Věrnostní karta vygenerována
    Controller->>Databáze: Uložit údaje věrnostní karty
    Databáze->>Controller: Potvrzení
    Controller->>Webový_prohlížeč: Věrnostní karta vydána
    Webový_prohlížeč->>Zákazník: Zobrazit věrnostní kartu

Checklist

Kategorie Požadavek splnění spolehlivost komentář
Databáze M:N vztahy x
1:N vztahy x
SQL joins x
Integritní omezení x
Testovací data x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Validace a sanitace vstupů Formuláře x
Datové typy x
Regulární výrazy x
Serverová validace požadavků x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Psaní kódu Potlačení warningů - nedefinované hodnoty x
Formátování kódu x
DRY princip - minimalizace opakování kódu x
SRP princip - single responsibility x
Pojmenování proměnných x
Konzistence stylu psaní kódu x
Verzování kódu (Git) x
HTML5 validní + sémantické značky x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Objektové programování Zapouzdření x
Dědičnost x
Abstrakce x
Rozhraní x
Polymorfismus
Magické metody
---------------------------- ------------------------------------------------- --------- -------------- ----------
Připojení k databázi PDO x
Prepared statement x
SQL injection x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Performance Stránkování
Indexace databázových tabulek x
Filtrace a organizování zdrojů x
Cache (mezipaměť)
---------------------------- ------------------------------------------------- --------- -------------- ----------
Autentifikace Cookies x
Session x
Lokální strategie pro registraci a přihlášení x
OAuth, access token, login x
Ukládánní hesel x
Uživatelská oprávnění x
Uživatelské role x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Datum a čas Časové pásmo
Formátování časových hodnot
---------------------------- ------------------------------------------------- --------- -------------- ----------
Návrhové vzory Model x
View x
Controller x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Bezpečnost XSS x
CSRF x
SQL injection x
---------------------------- ------------------------------------------------- --------- -------------- ----------
API CRUD operace x
HTTP metody x
Sémantické pojmenování zdrojů x
Verzování x
Idempotence
---------------------------- ------------------------------------------------- --------- -------------- ----------
Provoz a údržba Sledovatelnost a logování x
SEO URL x
Víceuživatelský přístup k datům x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Funkcionality Generování souborů PDF
Posílání e-mailů x
Oddělení ddministrační a uživatelské části x
---------------------------- ------------------------------------------------- --------- -------------- ----------
Testování Testovací scénáře pro manuální testování x
Dostupnost aplikace na internetu x
nvbach91 commented 7 months ago
KubaDavid commented 7 months ago
  • chcete aby obchodnik mohl zakaznikovi vydat kartu do jeho apple wallet?
  • musi se obchodnik do vase aplikace zaregistrovat?
  • musi se zakaznik do vase aplikace zaregistrovat?
  • jake udaje o zakaznikovi je potreba odevzdat obchodnikovi kvuli vydani karty?
  • jak obchodnikovi zobrazite ktera karta byla komu kdy vydana?
  • muze zakaznik videt svoje karty i ve vasi aplikaci?
  • jak se karta potom pouzije? podle ceho se pri jejim pouzivani pozna, o ktereho zakaznika se jedna? @nvbach91
    1. Ano
    2. Login mu bude přidělen Adminem, takže pravá registrace to nebude.
    3. Zákazník se neregistruje.
    4. email, jmeno, telefonní číslo
    5. Podle toho jaké karty se vážou pomocí "id_issuer" k účtu obchodníka.
    6. Zákaznické rozhraní v této verzi nebude, ale do budoucna ho chci přidat.
    7. Karta bude mít na sobě název a design obchodník a pak QR nebo Barcode a jméno zákazníka pro jeho identifikaci. Zkusím to udělat tak, aby QR odkazovalo na kartu zákazníka v aplikaci.

Část věcí je závislá na tom, co mi dovolí knihovny na generování karet a samotný Apple Wallet.

nvbach91 commented 7 months ago

2/ to si nemyslim jako dobry napad, obchodnik bude posilat adminovi email s pozadavkem na registraci nebo jak? 3/ jak se pak karta dostane do zakaznikova apple wallet? 8/ na co je pak tabulka rel_users_issuers, to aby uzivatel mohl mit pristup k vice vydavatelum?

doporucuji vynechat integraci s apple wallet a udelat misto toho UI pro zakazniky, tj. zakaznik uvidi sve karty ve vasi aplikaci a muze mit vice karet od vice vydavatelu

KubaDavid commented 7 months ago

2/ to si nemyslim jako dobry napad, obchodnik bude posilat adminovi email s pozadavkem na registraci nebo jak? 3/ jak se pak karta dostane do zakaznikova apple wallet? 8/ na co je pak tabulka rel_users_issuers, to aby uzivatel mohl mit pristup k vice vydavatelum?

doporucuji vynechat integraci s apple wallet a udelat misto toho UI pro zakazniky, tj. zakaznik uvidi sve karty ve vasi aplikaci a muze mit vice karet od vice vydavatelu

2 - V této první verzi aplikace jsem to tak myslel. 3 - Pravda, tady by byl použitý email. 8 - Aby například uživatel admin mohl spravovat více obchodníků.

Máte asi pravdu, chtěl jsem si každopadně vyzkoušet generovaní kartiček do Walletu.

nvbach91 commented 7 months ago

8 - tady si dovedu predstavit, ze budou uzivatele v roli obchodnika s opravnenim vydavat karty z ruznych obchodu, to ze ktery uzivatel ma opravneni vydavat karty ze ktereho obchodu budete evidovat prave v tabulce rel_users_issuers, navic bych tabulku issuers prejmenoval na company, merchant, business, brand, ... aby to bylo v souhladu s tim co chcete delat

Takhle bych to videl:

KubaDavid commented 7 months ago

8 - tady si dovedu predstavit, ze budou uzivatele v roli obchodnika s opravnenim vydavat karty z ruznych obchodu, to ze ktery uzivatel ma opravneni vydavat karty ze ktereho obchodu budete evidovat prave v tabulce rel_users_issuers, navic bych tabulku issuers prejmenoval na company, merchant, business, brand, ... aby to bylo v souhladu s tim co chcete delat

Takhle bych to videl:

  • uzivatel (obchodnik) po loginu uvidi seznam obchodu nebo tedy znacek (brand), ke kterym ma pristup a muze si vybrat pro kterou znacku chce zrovna pracovat
  • po vyberu znacky se mu zobrazi karty, ktere byly vydany z teto znacky, respektive seznam zakazniku kteri maji kartu v teto znacce
  • uzivatel (obchodnik) si muze zakladat sve znacky a automaticky k nim ziska pristup, a jeste muze pozvat jineho uzivatele (musi byt take zaregistrovan) do nejake sve znacky a tento "kolega" dostane pristup aby mohl vydavat karty z teto znacky
  • karta se potom vydava konkretnimu uzivateli zakaznikovi na zaklade jeho jmena, emailu a telefonniho cisla, kde email bude unikatni, tj. nelze vydat dalsi kartu stejne znacky na stejny email dvakrat, karty se da pripadne zrusit zakaznikem nebo tim uzivatelem (obchodnikem) kdo ma k znacce pristup
  • uzivatel (zakaznik) se take muze zaregistrovat, a to pomoci emailu nebo oauth a po prihlaseni uvidi vsechny sve karty vsech znacek, ktere byly vydane na email tohoto zakaznika

Omlouvám se za pozdní odpověď, ale nepřišlo mi upozornění. S Vaším návrhem souhlasím, děkuji.

KubaDavid commented 6 months ago

@nvbach91 Mohl bych změnit DB na MongoDB? Rád bych si vyzkoušel NoSQL databáze. Už jsem to nadhodil v kostře práce v tomto pull requestu: #202