jana19-sp

[jana19-vse]

E-shop s čajem

Základní eshop vycházející z práce na cvičení.

Popis užití

Z pohledu uživatele zákazníka lze prohlížet celou nabídku (po stránkách) a nebo filtrovanou nabídku dle:

• kategorie (černý, zelený,...)
• obsahu kofeinu (ano/ne)
• dárkových sad (ano/ne)

A nabídku seřadit dle ceny a názvu (asc/desc).
Každý produkt lze prohlédnout v detailu na samostatné stránce.

Po registraci a přihlášení (přímo nebo přes Oauth) může zákazník produkty přidávat do košíku nebo je odebírat a objednat zboží (na email bude odesláno potvrzení).

Z pohledu uživazele operátora, při dostatečném oprávnění, lze:

• přidávat a odebírat zboží
• editovat atributy zboží
• editovat oprávnění uživatelů

Use case diagram

Procesní diagramy

Oprávnění

Operátorem se rozumí uživatel, který má větší oprávnění než základní. Oprvánění je definováno pomocí parametru v DB. Každý vyšší stupeň v sobě obsahuje práva nižších stupňů.

• 0 – Degradovaný uživatel: Uživatel může pouze prohlížet. Byla mu odebrána práva k nákupu (aka dostal ban). Při pokusu nakoupit/přejít dokošíku dostane stránku, že má smůlu.
• 1 – Běžný uživatel: Uživatel může využívat všechny funkce určené pro zákazníky.
• 2 – Operátor pracovník: Může na zboží editovat parametr dostupnosti.
• 3 – Operátor manažer: Může na zboží editovat všechny parametry. Může přidávat a odebírat zboží z nabídky.
• 4 – Oprátor admin: Má právo editovat oprávnění uživatelů.

Stránky

• registrace - slouží k registraci
• přihlášení - slouží k přihlášení
• homepage - výchozí stránka, prohídka zboží + lze přidat do košíku
• stránka produktu - stránka konkrétního produktu s detaily + lze přidat do košíku
• košík - stránka košíku, prohlížení a správa obsahu
• objednávka - stránka pro dokončení objednávky (vyplnit adresu atd.)
• správa uživatelů - výčet a správa uživatelů
• správa zboží - výčet a správa zboží

Přičemž predpokládám existenci dalších technických stránek ve smyslu jednotlivých php souborů a případné stránky oznamující úspěch akce. To pak bude záležet na logice aplikace.

Databáze

• User
  • role – atribut představující výši oprávnění
  • isExternalAuth – jestli je externí autentizace uživatele. Nevím, jak ten OAuth funguje z hlediska kódu a DB (ještě to na cvičení nebylo), ale předpokládám, že někde to nějaký příznak bude muset mít?
• ProductType
  • typ produktu = typ čaje (černý, zelený,...)
  • vazba na Product M:N je záměrně
  • jeden produkt může teoreticky spadat do více kategorií najednou. Např. Dárková sada může obsahovat černé i zelené čaje zároveň.
• Product
  • price – stálá cena
  • discount – napadlo mě, že případné slevy bude lepší definovat zvlášť, v procentech.
  • Pro Operátora bude pohodlnější než dopočítávat cenu a editovat sem a tam (třeba kdyby byla sleva po dobu 1 týdne).
  • Bude tak možné zobrazit slevu zvlášť pro uživatele (typu "- 30 %")
  • a reálná cena by tak šla vypočítat z price a discount.
  • isCaffeineFree – obsahuje kofein ano/ne
  • isGiftSet – je dárková sada ano/ne
  • isAvailable – vyjadřuje zda je produkt dostupný ano/ne
  • Pokud se stane (dočasně) nedostupným, může operátor označit, že není dostupný aniž by byl vyjmut z nabídky.
  • True -> normální chování
  • False -> Nebude možné přidat do košíku (asi nejjednodušší bude dát na tlačítko disable)
  • Poznámka: Ano, v reálu by to muselo být řešeno složitěji. Záznam by musel obsahovat minimálně timestamp od kdy je nedostupnost validní. Ideálně by to bylo propojené se skladovou evidencí a nestalo by se, aby tohle řešil člověk.
    Bylo by to spíš takový demo. Osobně to beru tak, že je to příležitost udělat "něco trochu zajímavýho", aby v té práci bylo co hodnotit.

[nvbach91]

• tabulku OrderProductList prejmenovat na OrderProducts
• discount by mel byt take v tabulce OrderProducts
• v tabulce Users to nebude isExternalAuth, ale authType (ENUM - local, google, facebook, ...)
• do tabulky Orders pridejte stav objednavky - state (pending, confirmed, canceled, paid, ...) - vychozi hodnota bude pending a zmeny stavu bude nastavovat majitel eshopu, na veskere zmeny stavu objednavky bude zakaznik notifikovan
• mezi ProductTypes a Products by tedy mela byt spojovaci tabulka vyjadrujici vztah M:N
• kde jsou ostatni diagramy?

[jana19-vse]

Tabulky DB upraveny. Přidán Use case diagram. Přidány procesní diagramy.