| 7 | | || Login || Корисникот ја пристапува home страницата на сајтот. Има опции да се регистрира или да внесе корисничко име и лозинка. По внесување на неговите податоци, избира каков корисник е од User, Company и Team (во овој случај User). На фронтенд се се праќаат податоци до бекендот преку форма. При примање на податоците, бекендот го проверува корисникот во датабазата преку AccountService класата која на пониско ниво комуницира со AccountRepository при што се разграничува според изборот на тоа каков корисник се логира. По успешно наоѓање на корисникот во базата, соодветно се испраќаат корисничките информации до фронтендот преку Data Transfer Object, при добивање на успешни податоци на фронтендот корисникот се редиректира до страницата за поглед на профилот. Доколку не постои таков корисник соодветно е испратена порака за непостоечки корисник. Со ова завршува најавата на корисникот што е имплементирана на ист начин за било кој тип на корисник. По успешната најава корисникот се наоѓа на страницата за поглед на сопствените податоци. || |
| | 7 | || **Пристап** ||При впишување на URL-то корисникот ја пристапува login страницата на сајтот. Во навигацискиот бар има опции да се регистрира како одреден тип на корисник (компанија, студент или пак тим) или да внесе корисничко име и лозинка. || |
| | 8 | || **Login** ||**1.** Внесување на податоците за најава и избор на тоа за каков корисник станува збор, од User, Company и Team. \\ **2.** На фронтенд се сетира состојбата со моментално внесените податоци, а при клик на копчето Login моменталните податоци од состојбата се праќаат преку axios POST повик на Login контролер патернот во бекендот. \\ **3.** При примање на податоците во Login контролерот, бекендот прави повик на функцијата findUser од Account сервисот. \\ **4.** Account сервисот на пониско ниво комуницира со User, Company и Team репозиториумите врз основа на тоа каков тип на account е пратен во реквестот при што ги пребарува нивните табели и соодветно на тоа дали ќе најде некој корисник со внесените account и password резултатот го враќа во објект од типот Account. \\ **5.** Доколку успешно е пронајден корисникот во базата, Login контролерот проверува од кој тип е тој акаунт, односно од кој класен тип е тој објект врз основа на тоа од кој репозиториум е вратен. Соодветно на тоа се испраќаат корисничките информации до фронтендот преку Data Transfer Object. \\ **6.** Доколку не е пронајден таков корисник, на фронтенд се испраќа иницијализиран Login Response DTO (Ова е родител класа на сите login response dto-а) кој иницијално содржи Error кој фронтендот може да го препознае. \\ **7.** При добивање на податоците на фронтендот, доколку успеало најавувањето корисникот е редиректиран до страницата за поглед на профилот. Доколку не постои таков корисник соодветно е испратена порака за непостоечки корисник и е редиректиран до Login страницата повторно. \\ **8.** Со ова завршува најавата на корисникот што е имплементирана на ист начин за било кој тип на корисник. По успешната најава корисникот се наоѓа на страницата за поглед на сопствените податоци. || |
| | 9 | || **Register** ||**1.** Избор на типот на account кој сака корисникот да го регистрира на иницијалниоут route во сајтот. \\ **2.** Редирекција на фронтенд до компонентите кој одговараат на тој избор (register_company_form.js, register_team_form.js или register_user_form.js). \\ **3.** Доколку се избрани компанија или тим, формата е хендлана на сличен начин како во логин само постира на различни endpoints во бекендот (/api/register/company за компанија и /api/register/team за тим). \\ **4.** По внесување на податоците и клик на Register копчето на фронтенд, на соодветата патека се праќа POST реквест преку axios повик до бекенд. \\ **5.** По примање на податоците на бекенд преку Account Register контролерот, се креира објект од тип Account кој е резултат на функцијата registerCompany или registerTeam. \\ **6.** Во овие функции најпрво се проверува дали сите параметри се внесени. Доколку има некој параметар кој е празен, а е потребен за регистрација, се фрла Invalid Arguments Exception. Доколку се е во ред второ се проерува дали постои таков е-mail во базата преку репозиториумите. Доколку постои корисник со тој e-mail се фрла User Exists Exception. Доколку се е во ред, Се креира нов објект од типот на корисникојт кој се регистрира, во овој случај (компанија или тим) и резултатот од методот save() во репозиториумот се враќа назад во објектот Account во контролерот. \\ **7.** Доколку се регистрира корисник (User) тогаш постапката е малце различна. На фронтенд корисникот треба да избере и листа на вештини кој ги поседува и кој сака да ги научи. \\ **8.** За да се овозможи овој избор, при клик на Register User копчето на фронтенд, се праќа повик до бекендот до Skill контролерот кој за возврат ги дава сите вештини кој ги имаме во базата на вештини. \\ **9.** По примање на вештините на фронтенд се сетира состојбата така што во листите за избор на вештини се листаат сите вештини кој се вратени од бекендот, а како вредност се сетираат ID-ата на истите. \\ **10.** Се креираат две листи од вештини. Првата е за retained skills а втората е за skills to learn. \\ **11.** По избор на вештините од страна на корисникот, на фронтенд се додаваат ID-ата на селектираните вештини во соодветните листи (retained и toLearn) и останатите податоци кој се потребни за регистрација. \\ **11.** Со клик на копчето Register на бекенд се праќаат сите овие податоци преку DTO. \\ **12.** Најпрво се креираат две листи од вештини на бекенд според ID-ата кој се проследени од фронтендот со повик на функцијата returnSkillsBasedOnId што прима листа од тип Long како аргумент. \\ **13.** Оваа функција итерира во базата и ги враќа сите вештини според нивните ID-а. \\ **14.** По ова се повторува постапката како кај компании и тимови, само додатно после зачувување во базата се повикува функцијата setUpUser кој го прима зачуваниот корисник како аргумент. \\ **15.** Оваа фунција го повикува Matchmaker сервисот кој најпрво ги брише сите податоци за постоечки корисник доколку истиот го има. \\ **16.** Потоа креира листи од сите Jobs, Internships и Projects. \\ **17.** Итерира низ сите листи по ред и повикува соодветни функции за setUpUserMatches кој примаат работа и корисник како аргументи. \\ **18.** Оваа функција прави листи од вештините на работата и корисникот, а потоа го пресметува коефициентот на усогласеност преку статичната функција match од Мatchmaker класата. \\ **19.** match функцијата го зема како иницијален коефициент бројот на вештини на работата, а потоа итерира низ сите вештини на работата и на корисникот, доколку тие одговараат има променлива која што се зголемува за 1. \\ **20.** Кога ќе завршат сите итерации се враќа коефициентот како резултат на делење помеѓу променливата која се зголемува и иницијалниот коефициент, односно бројот на вештини во работата. Резултатот на ова е секогаш float помеѓу 0 и 1. \\ **21.** Кога ќе го добиеме коефициентот се креира нов запис во табелата за усогласување со ID на корисникот, ID на работата и коефициент на усогласеност. Ова се повторува и за Internships и за Projects. \\ **22.** Доколку се ова е завршено успешно и Account променливата во контролерот има вредност различна од null се враќа Map<String, String> со success и порака за успех. Доколку има проблем се праќа истата мапа со порака за error. \\ **23.** По примање на пораката на фронтенд, доколку е успешно се редиректира на login рутата, доколку има некаков проблем се редиректира на register рутата со соодветната порака за проблем.|| |
