milantru / servis Goto Github PK

Napríklad keď sa užívateľ chce zaregistrovať, tak vypĺňa UserFrorm.
Ak vyplní všetky povinné políčka a klikne na "Registrovať", všetko je v poriadku.
Ak vyplní všetky povinné políčka a vyplní aj nejaké z nepovinných, tak takisto je všetko v poriadku.
Ale ak vyplní všetky povinné políčka spolu s nejakým nepovinným, a potom zmaže text v nepovinnom, tak po kliknutí na "Registrovať" sa zobrazí chybová hláška (napr. v prípade telefónneho čísla to je hláška, že formát čísla nie je validný). A aj napriek tomu, že políčko je nepovinné, tak užívateľ je nútený do neho zadať dáta alebo obnoviť stránku.

(Zdá sa, že problém vytvárajú atribúty Phone a EmailAddress. Na začiatku je v políčku null, a ten atribúty ignorujú. V momente keď do políčka užívateľ niečo napíše a zmaže, už tam nie je null, ale prázdny string. A to nie je validná hodnota.)

Keď sa chce užívateľ prihlásiť, je jedno či zadá prihlasovacie meno napr. "User" alebo "user". Vezme obe varianty (systém nevidí rozdiel). Zdá sa, že MySQL si vyberá defaultne case insensitive collation. Myslím, že to by bolo dobré zmeniť (ak nie globálne, tak aspoň v queries pri registrácii a prihlasovaní).

Alternatívne, ak by sme nemenili collation, myslím, že by stačilo pri registrácii keď sa kontroluje, či existuje užívateľ s rovnakým menom, skontrolovať pom. C# (nie SQL) dodatočne veľké malé písmená. Z hľadiska performance sa môže zdať že nejde o veľmi dobré riešenie, ale treba si uvedomiť, že prihl. meno má obmedzenú veľkosť, takže to je OK. Len potom by to chcelo tiež podobne dokódiť pri prihlasovaní, lebo síce bude platiť, že sa neregistrujú 2 užívatelia pod rovnakým menom, ale stále by sa mohol prihlásiť napr. "User" aj pod menom "user" (a to je čudné).

To znamená:

• pripraviť miesto pre text podmienok používania
• pridať checkboxy do DemandForm, AuctionBidForm a k registrácií ("zaškrnutím súhlasím s podmienkami používania")
• pridať možnosť exportu dát užívateľa
• pridať možnosť pre užívateľa, aby sa vedel odstrániť z webu (možnosť vymazať svoje dáta)

Majme nejakú rozbehnutú aukčnú ponuku. Pod pojmom rozbehnutú myslím, že už zopár ľudí ponúklo nejakú sumu. Počiatočná suma bola x, aktuálna suma je y (teda y > x). Ak chce užívateľ do tejto aukcie ponúknuť novú sumu, musí byť aspoň o 100 € vyššia od aktuálnej sumy (preto o 100, lebo v čase písania tohto issue bol rozdiel medzi ponukami fixne nastavený na 100). A to je (v rozbehnutej aukcii) správne.

Lenže... Ak vytvoríme novú aukčnú ponuku s počiatočnou cenou x, tak by asi bolo dobré, aby užívateľ vedel ponúknuť sumu x a nie minimálne x + 100. Problémom teda je, že kontrola rozdielu medzi ponuknutými sumami sa vzťahuje aj na počiatočnú sumu. (Toto správanie pravdepodobne nie je žiadúce.)

Tags used in AutogeneratedMessage (in ServISData project) are from AutogeneratedMessageForm.Tags (in ServISWebApp project). I don't want the data project to be dependent on the webapp project...

Momentálne fungujú správy dosť pomaly. Načítanie, odosielanie, mazanie... Chcelo by to zrýchliť.

A aby sa podľa neho dalo nejako filtrovať/sortiť (proste aby admin vedel rýchlo/pohodlne pozrieť aké stroje sú len pre akciu a ktoré nie).

No tie sa tam zobrazovať nemajú...

Momentálne je v kóde fixne nastavené, že ak chce účastník aukcie ponúknuť nejakú sumu, tak musí byť o 100 € vyššia ako aktuálna cena. Bolo by asi dobré to spraviť tak, aby to nebolo fixne v kóde nastavené na 100, ale aby si to vedel admin nastaviť v aplikácií. Alebo aspoň do appsettings.json to dať.
(V AuctionBidForm je minDiff field. V ňom je fixne nastavená 100.)

Pri odpisovaní na správy sa dá double-clickom poslať správa (min.) 2x.

Niektoré polia vo formulároch, napr. pri dopyte na nejaký stroj, sú povinné (napr. email), ale niektoré povinné nie sú (napr. bydlisko). Bolo by dobré ich nejako označiť, napr. k povinným dodať *.

Keď dáme upraviť nejaký bager, vymažeme všetky jeho fotky a odídeme zo stránky (napr. cez navigáciu), tak daný stroj nemá žiadne fotky. Tým pádom sa nedá dostať na jeho detail, a ani sa nemôžu bagre vylistovať.

Bolo by dobré obmedziť rozmery kartičiek (napr. ExcavatorCard), pretože keď sú okolo seba vylistované kartičky s rôzne veľkými fotkami, tak ich rozmery sú takisto rôzne a nevyzerá to dobre.

Komponent Virtualize robí problémy ak chcem použiť vlastné css. Viac tu.

V skratke... buď css nefunguje tak ako by som chcel a vyzerá to zle alebo to vyzerá dobre, ale Virtualize nefunguje.
Nemôžem na itemy, ktoré sú vo Virtualize, použiť flex (s flex dir row). A ani žiadné iné triky sa mi kvôli tomu, že Virtualize si na začiatok a koniec pridáva vlastné elementy, nepodarilo použiť...

Po rozmyslení som došiel k záveru, že toto je aplikácia pre malé firmy, preto predpokladám, že v ponuke nebudú mať stovky (alebo viac) strojov (aspoň nie rovnakého typu, teda nevylistujú sa naraz 100+ strojov). Preto tu Virtualize nepotrebujem. Teda najjednoduchšie riešenie je ho odstrániť, a potom použiť vlastné css s flex.

Neviem presne odkiaľ sa tam berú. Pravdepodobne sú to anonymní užívatelia, ktorí sa zapojili do aukcie. Po skončení aukcie sa vymazali ich bidy, ale oni ostali uložení medzi Usermi.

Bolo by dobré pridať aspoň nejaký text/obrázky na statické stránky (O nás, Služby).

Bolo by dobre pridať nejaký spôsob, akým by vedel admin nakonfigurovať tvar automaticky generovaných správ (napr. správa ktorá príde výhercovi aukcie...).

Keď užívateľ pošle správu/dopyt na nejaký stroj, tak v správe je injectnutá URL stroja. Táto URL sa v iframe vykreslí pri prvej správe adminovi, keď si ju v správach na profile prezerá. Problém nastáva, keď stroj bol medzitým vymazaný z DB...
Napr. chceme vykresliť URL s /stroj/2 (teda stroj s ID 2). Kedže tento stroj už v DB nie je, vyhodí sa exception a admin v iframe vidí exception.

Možné riešenia:

1. Kontrolovať pri extractovaní injectnutej URL (resp. pri renderovaní iframe), či stroj existuje. Ak nie, tak vykresliť predpripravené HTML s textom, že daný stroj už neexistuje.
2. Stránku (resp. komponentu), ktorá sa v iframe na danej URL vykresľuje upraviť tak, aby nevyhodila exception ak stroj s daným ID neexistuje, ale aby zobrazila text typu "Tento stroj už neexistuje" (alebo niečo podobné).

Myslím, že 2. možnosť je lepšia, pretože ak by sa užívateľ snažil manuálne dostať na stránku /stroj/X (kde X je ID stroja, ktorý nie je v DB alebo nejaký iný nezmysel), tak mi príde prirodzenejšie, že sa zobrazí info o tom, že stroj neexistuje ako keby mala stránka vybuchnúť (teda vyhodiť exception).

Momentálne to v aplikácii funguje tak, že sa stiahnu všetký správy a zobrazia sa (viď správy v profile). Bolo by asi dobre tam spraviť nejaký paging/virtualizáciu.

Ak nastala editácia alebo zmazanie aukčnej ponuky, tak upozorni každého užívateľa (pošli mail), ktorý sa jej účastnil.

Práve som sa pozrel na kód a zdá sa, že je možné zaregistrovať viacero užívateľov s rovnakým prihlasovacím menom.
V UserForm v metóde SaveUserAsync() asi bude treba pridať nejakú kontrolu, či sa už nový/registrujúci sa užívateľ nachádza v databáze (kontrola na prihlasovacie meno, príp. email). Ak už taký existuje, vybehne oznámenie. Ináč sa normálne uloží/registruje.

Keď sa užívateľ registruje, má pred sebou UserForm. Ešte nič nevyplnil a klikne na Registrovať. Pri každom povinnom políčku sa vypíše, že je povinné. Pri každom, až na políčko Znovu heslo. Pre konzistenciu by asi bolo lepšie, ak by sa aj tam ukázala hláška.
(Momentálne to funguje tak, že keď sa form vyplní a len Znova heslo ostane prázdne, tak vyskočí alert s hláškou že Heslo a Znova heslo nie sú rovnaké.)

Keď užívateľ pošle dopyt na nejaký stroj alebo prídavné zariadenie, do tela správy emailu (pre admina) sa "injectne" url dopytovanej veci. Podobne je tomu aj pri aukčných ponukách. Táto url sa parsuje z tela správy, adminovi sa v appke nezobrazí (tají sa mu, že to tam je). Extrahovaná url sa použije v iframe na zobrazenie stránky. Takto sa k dopytovanej veci vie admin jednoducho dostať.

Okrem toho tiež automaticky generované správy určené pre účastníkov aukcie obsahujú subject, ktorý začína s "Vyhrali ste" alebo "Aukcia s predmetom" (ak užívateľ vyhral alebo prehral). Z nejakého dôvodu sa tieto emaily pošlú ako užívateľom, tak aj adminovi. Kedže nie je žiadané, aby sa tieto správy (určené užívateľom!) zobrazovali v schránke admina, tak existuje v kóde if, ktorý ak takúto správu (je poslaná z appky a subject sa začína "Vyhrali ste " alebo "Aukcia s predmetom ") odignoruje, ba čo viac, rovno ju i zmaže (aby nezaberala miesto v schránke).

Takéto fungovanie sa mi nepáči. V prípade vložených url mi vadí, že sa url nachádza v texte správy, teda ak si otvoríme gmail, je to tam vidno, tiež musíme parsovať. A hlavne mi vadia veci spomenuté v druhom odseku, pretože sme viazaný na konkrétne stringy, čo je z hľadiska udržateľnosti nie veľmi dobré riešenie... Navyše nám to ani nedovoľuje nejakú konfiguráciu subjectov pre admina.

Možným riešením je potrebné info uložiť do hlavičiek emailu. Neskôr si dáta z hlavičiek vybrať a použiť ich podľa potreby.

Po prihlásení vie užívateľ pristúpiť cez url /prihlasovanie a skúsiť sa (pre)prihlásiť znovu.

Keď užívateľ odošle email z aplikácie, napr. dopyt na bager, stránka detailu bagra je vložená do správy, takže vidíme, odkiaľ sa email poslal a aký bager je dopytovaný. Problém je, že chýbajú informácie o užívateľovi, napr. odkiaľ je...

Takže aj napriek tomu, že by užívateľ zadal svoje bydlisko, tak by sa ho administrátor musel pýtať v emailoch odkiaľ je (to neznie ako príjemná UX).

Ak napr. zákazník vyhrá/prehrá dražbu v aukcii, odošle sa mu email. Z nejakého dôvodu dôjde aj zamestnancovi do schránky, preto existuje v triede EmailManager metóda ShouldSkipAsync, ktorá tento email zmaže. No ak dôjde k takémuto zmazaniu, nezobrazí sa požadovaný počet správ (resp. threadov) v sekcii Správy. Napr. povedzme, že na jednu stranu chceme vypísať 10 threadov, ale keď sme kvôli ShouldSkipAsync 1 vymazali, zobrazí sa len 9 threadov.

Ak sa užívateľ prihlási, otvorí nový tab a v novom tabe sa odhlási, tak potom ako sa vráti do prvého tabu vidí, že je stále prihlásený. Myslel som, že použitím triedy RevalidatingServerAuthenticationStateProvider by sa problém vyriešil. Po uplynutí času stanovenom v RevalidationInterval by sa mala volať validácia definovaná v ValidateAuthenticationStateAsync(AuthenticationState, CancellationToken). Ak sa auth state vyhodnotí ako neplaný (teda validácia vrátila false), tak je uživateľ odhlásený. Lenže z nejakého dôvodu sa spomínaná validačná metóda nevolá.

Metóda Migrate() v Program.cs nefunguje- neaplikujú sa pending migrácie.