| 12 | | ||= **Нормален тек** =||''Акции преземени од корисникот:'' \\ **1.1** Кликнува на search алатката (HTML форма) и внесува податоци (кирилични или латинични знаци) за субјект кој го интересира ИЛИ \\ **1.2** оди на landing страницата, каде се прикажани последните 10 мислења од категориите „предмет“ и „професор“, сортирани според времето на објавување \\ \\ ''Акции преземени од системот кон:'' \\ **1.1** После >=4 внесени знаци контролерот пречекува барање од HTML формата, кое ги содржи истите во телото и ги пропагира до сервисите одговорни за ентитетите „професор“ и „мислење“, кои потоа поставуваат прашалници до базата за колоната „име“ од двете табели. На контролерот се враќаат сите колони од погодоците, кој потоа ги предава на логиката за рендерирање поглед, која натаму од добиените ИД и име генерира листа од anchor HTML елементи кои водат до соодветната секција за дискусија (страница мапирана на /ИД). \\ **1.2** На секое прикажување на овој поглед, контролерот пречекува соодветно именувано барање без тело и го спореведува истиот тек, само што сервисите кои ги повикува поставуваат друг вид на прашалник (од типот ''order by time_posted desc limit 10'' за двете табели) || |
| | 12 | ||= **Нормален тек** =||''Акции преземени од корисникот:'' \\ **1.1** Кликнува на search алатката (HTML форма) и внесува податоци (кирилични или латинични знаци) за субјект кој го интересира ''ИЛИ'' \\ **1.2** оди на landing страницата, каде се прикажани последните 10 мислења од категориите „предмет“ и „професор“, сортирани според времето на објавување \\ \\ ''Акции преземени од системот:'' \\ **1.1** После >=4 внесени знаци контролерот пречекува барање од HTML формата, кое ги содржи истите во телото и ги пропагира до сервисите одговорни за ентитетите „професор“ и „мислење“, кои потоа поставуваат прашалници до базата за колоната „име“ од двете табели. На контролерот се враќаат сите колони од погодоците, кој потоа ги предава на логиката за рендерирање поглед, која натаму од добиените ИД и име генерира листа од anchor HTML елементи кои водат до соодветната секција за дискусија (страница мапирана на /ИД). \\ **1.2** На секое прикажување на овој поглед, контролерот пречекува соодветно именувано барање без тело и го спореведува истиот тек, само што сервисите кои ги повикува поставуваат друг вид на прашалник (од типот ''order by time_posted desc limit 10'' за двете табели) || |
| 28 | | ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Клика на опцијата за најавување (HTML anchor елемент)\\ **2.** Доколку веќе има корисничка сметка, ги внесува својот e-mail и лозинка и клика на ''Најави се'', инаку оди на !UseCase со ID 3 (корисничка регистрација) т.е. притиска на елемент кој го води на таа страница \\ \\ ''Акции преземени од системот кон:'' \\ **1.** Се активира погледот мапиран на /login патеката кој содржи две input полиња за внес на податоците. \\ **2.** Се праќа барање до одредена патека на контролерот, кое во телото ги содржи мејлот и лозинката. Аналогно на текот опишан во претходниот use-case, се испитува дали внесени кориснички мејл е претходно зачуван, дали сметката е активирана, се хашира пречеканата лозинка со BCrypt и се споредува со соодветната колона во базата за торката каде е зачуван мејлот. Во случај на успех, се креира инстанца од HttpSession која содржи податоци за што е авторизиран корисникот (пр. преку getSession().getRoles()) и на прелистувачот се враќа id:String полето од истата. Апликацијата на клиентска страна ја зачувува променливава како колаче што дозволува рендерирање на повеќе погледи за корисникот. Во случај на неуспех, се случува истото, само што апликацијата на клиентска страна детектира од телото на response-от низа од знаци (пр. "error") и добиената сесиска променлива без привилегии ја игнорира. || |
| | 28 | ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Клика на опцијата за најавување (HTML anchor елемент)\\ **2.** Доколку веќе има корисничка сметка, ги внесува својот e-mail и лозинка и клика на ''Најави се'', инаку оди на !UseCase со ID 3 (корисничка регистрација) т.е. притиска на елемент кој го води на таа страница \\ \\ ''Акции преземени од системот:'' \\ **1.** Се активира погледот мапиран на /login патеката кој содржи две input полиња за внес на податоците. \\ **2.** Се праќа барање до одредена патека на контролерот, кое во телото ги содржи мејлот и лозинката. Аналогно на текот опишан во претходниот use-case, се испитува дали внесени кориснички мејл е претходно зачуван, дали сметката е активирана, се хашира пречеканата лозинка со некој алгоритам за таа намена и се споредува со соодветната колона во базата за торката каде е зачуван мејлот. Во случај на успех, се креира инстанца од HttpSession која содржи податоци за што е авторизиран корисникот (пр. преку getSession().getRoles()) и на прелистувачот се враќа id:String полето од истата. Апликацијата на клиентска страна ја зачувува променливава како колаче што дозволува рендерирање на повеќе погледи за корисникот. Во случај на неуспех, се случува истото, само што апликацијата на клиентска страна детектира од телото на response-от низа од знаци (пр. "error") и добиената сесиска променлива без привилегии ја игнорира. || |
| 44 | | ||= **Нормален тек** =|| 1. Корисникот е на било која страница во апликацијата\\ 2. Клика на опцијата за регистрација\\ 3. Го пополнува формуларот во кој се бара неговата e-mail адреса, корисничкото име кое сака да го користи, неговото име и презиме (опционално) и лозинката која сака да ја користи за најава\\ 4. Добива електронска порака на наведената адреса со линк за потврда на регистрацијата || |
| 45 | | ||= **Исклучоци:** =|| Некои од полињата во формуларот се невалидни (e-mail адресата, корисничкото име или лозинката се со неправилен облик), при што барањето за регистрација нема да биде успешно и корисникот ќе треба да се обиде повторно || |
| | 44 | ||= **Нормален тек** =|| \\ ''Акции преземени од корисникот:'' \\ **1.** Клика на линк кој го води до страницата за регистрација\\ **2.** Го пополнува формуларот во кој се бара неговата e-mail адреса, корисничкото име кое сака да го користи, неговото име и презиме (опционално) и лозинката која сака да ја користи за најава и притиска "Submit" \\ **3.** Добива електронска порака на наведената адреса со линк за потврда на регистрацијата \\ **4.** Клика на линкот за активација на сметката \\ \\ ''Акции преземени од системот:'' \\ **1.** Апликацијата на клиентска страна го прикажува погледот за регистрација со 4-те полиња и инструкции за нивно правилно пополнување\\ **2.** Формата се валидира на клиентска страна (само проверка дали некое од задолжителните полиња е празно) \\ **3.** Контролерот го пречекува барањето со 4-те полиња, за чијашто проверка (пр. дали лозинката содржи цифри) повикува сервиси со логика за regex препокривање. Ако ова е во ред, накратко: се креира нова сметка означена како неактивирана и се испраќа мејл со линк што содржи токен за активација \\ **4.** Сметката се означува за активирана, а токенот за искористен. || |
| | 45 | ||= **Исклучоци:** =|| За **2.**: Некои од полињата во формуларот се празни - барањето за регистрација нема да воопшто да биде пратено. \\ За **3.**: не поминува регекс проверката - се фрла исклучок кој го хендла контролерот, враќајки порака за грешка ''ИЛИ'' има погодок во базата за внесениот мејл - системот испитува дали таа сметка е активирана. Во слујачот да е, се фрла исклучок некаде во сервисниот слој со кој се справува контролерот така што враќа порака од типот „веќе постои корисник со ова кор. име“. Во случај да таквата сметка не е активирана (пр. истекле 15-те минути додека е валиден активацискиот токен, а корисникот не ја видел пораката), преку одговорниот сервис се генерира и зачувува нов токен и се испраќа нов мејл со линк за активација. || |
