Имплементација на случаи на употреба

Регистриран корисник (User)

ИД 13 - Апликација за вработување како доставувач

За корисник да аплицира за работна позиција како доставувач, корисникот треба првично да ги пополни своите информации и да го притисне копчето "Submit Application".

При клик на копчето, се испраќа POST барање до backend апликацијата во кој се сместени поднесените информации кои се побарани во апликацијата како што се телефонскиот број, мејл адресата, CV-фајлот како и мотивационото писмо.

Во header делот не е потребно да специфицираме дека Content-Type ќе е multipart/form-data поради тоа што самиот IDE може да препознае дека се испраќа таков тип на контент.

За секоја потребна информација чуваме посебен Hook, и ги менуваме на секоја промена посебно.

Во backend апликацијата, request-от е примен од страна на контролерот ApplicationController којшто содржи соодвете API endpoint. којшто ги препраќа потребните информации кон сервисот.

Во контролерот ја составуваме апликацијата според пратените информации и тие информации ги препраќаме до сервисниот дел.

Сервисниот дел директно ги препраќа информациите до последниот слој (Data Access Object)

Во последниот слој користиме java database connection за да ги пратиме дадените информации како нов ред во табелата „application“.

Ние одбравме директно да ги чуваме cv-ата во база место како url поради тоа што не е очекувано да се добива многу апликации и при review на истите администраторот е задолжен да ги избрише.

Администратор (Admin)

ИД 17 - Преглед на активни апликации за вработување

Да ја поминеме процедурата за превземање на cv-ња на апликанти од страна на администраторот, постапката на изглед е едноставна. Администраторот селектира еден апликант и има можност да го превземе cv-to, да го прифати или одбие апликантот

Во зависнот од Hook-от "active" се прикажуваат потребните картички, во овој случај по default е сетирана на "application" за да ни се прикажат картичките од апликациите

Во истиот filе се праќа get барање во завистост од кој api endpoint се бара (во овој случај /application)

Дополнително се испраќа page и size поради тоа што апликациите како и сите други картички се враќаат во форма на pagination.

Во секој ApplicationCard праќаме дополнително барање до друг endpoint за прибирање на деталите за секој user.

Дополнително во header делот праќаме jwt Token за да се осигуриме дека Администраторот е тој што ги праќа барањата до backed делот.

Исто така и специфицираме дека Content-Type-от е во application/json формат.

Справувањето на accept копчето се активира додека администраторот сака да го прифати апликантот како доставувач.

Се праќа POST барање со посебен header кои што состои автентикација дека администраторот е тој што го прифаќа доставувачот и го сетираме Content-Type на application/json.

Во backend делот од апликацијата се пречекува барањето од соодветниот API endpoint, се добива идентификацискиот број на userot и се препраќа кон сервисниот слој

Сервисниот слој само го препраќа ид-то кон Data Access Object слојот.

Data Access Објеct слојот користејќи jdbc (java database connection) го менува односно update-ира улогата на корисникот во доставувач.