| 53 | | ||= **Случај на употреба:** =|| Ажурира состојба на лекови во продажба, работно време и локација || |
| | 53 | ||= **Случај на употреба:** =|| Ажурира состојба на лекови во продажба, и ажурира аптеки || |
| | 54 | 1. Агентот ажурира состојба на лекови во продажба |
| | 55 | - Со клик на копчето „Додај нов лек“ се повикува функцијата addMedicine() со што се отвара дијалог со форма за внес на сите потребни информации за додавање на нов лек. По успешно затворање на овој дијалог, се додава лекот на листата. |
| | 56 | - Со клик на копчето „Додај постоечки лекови“ постои можноста да се додаваат лековите кои веќе се наоѓаат во базата, се повикува функцијата addMedicinesFromList() која отвара нова дијалог компонента со опции за штиклирање и додавање нови лекови во сопствената листа на продажба. |
| | 57 | - Со вклучување на слајдер копчето "Edit mode", се повикува функцијата switchEditMedicineMode() при што на сите полиња од табелата со лекови се дозволува менување на вредностите. Исто така се додава копче за бришење на секој лек поединечно, во последната колона од табелата. При клик на ова копче се повикува функцијата deleteMedicine() при што листата се филтрира и лекот се брише од листата. |
| | 58 | - Сите овие промени се прават во рамки на самиот прелистувач, па се до моментот на кликање на копчето „Зачувај ги промените“, промените врз лековите нема да бидат извршени во самата база. Со клик се повикува сервисната метода updatePharmacyHead() од дата сервисот, при што се праќаат сите ажурирани податоци до backend-от и соодветно се зачувуваат во база. |
| | 59 | |
| | 60 | 2. Агентот ажурира аптека |
| | 61 | - Агентот ги гледа сите свои аптеки во табелата од табот „Мои аптеки“, па со клик на копчето "Edit" до секоја аптека посебно во рамки на табелата се повикува функцијата openEditPharmacyDialog() која отвара дијалог со форма за ажурирање на податоците за соодветната аптека. По кликање на копчето "Save", ажурираните резултати се предаваат на сервисната метода updatePharmacyHead() од дата сервисот и се праќаат до backend-от. |
| | 62 | |
| | 66 | 1. Агентот навигира до патеката за најава |
| | 67 | - Копче за најава води до рутата со форма за најава - "/login", на која е мапирана Login компонентата, при нејзина иницијализација се врши проверка за тоа дали некој корисник веќе е логиран и дали постојат токени во localStorage објектот. Во случаи кога веќе постои, го враќа на претходната патека, во спротивно корисникот останува на патеката за најава. |
| | 68 | |
| | 69 | 2. Агентот ја пополнува формата и го испраќа барањето за најава |
| | 70 | - По пополнување на формата, со клик на копчето „Најави се“ се повикува функцијата loginPharmacyHead() која ја повикува сервисната метода login од автентикацискиот сервис, со внесената е-пошта и лозинка како влезни параметри. Потоа се праќа HTTP POST повик до backend-от за валидација на корисникот. По успешната валидација, се рутира агентот до соодветната патека, инаку се прикажува порака за грешка веднаш под формата. |
| | 71 | - Податоците за корисникот, како и неговите токени за авторизиран пристап се чуваат локално во localStorage објектот, и мора да бидат достапни во текот на неговата интеракција со деловите на апликацијата кои побаруваат автентициран корисник за пристап. |
| | 72 | - Секое испратено барање мора да го содржи "Authorization" делот во заглавјето на барањето, па за таа цел имплементацијата на JWT interceptor го зема токенот за пристап од localStorage и го „лепи“ за секое заглавие на барање. |
| | 73 | - Секоe барање исто така се пресретнува од Unauthorized interceptor-от, каде се врши проверка доколку кодот на одговорот од серверот е 401 (Unauthorized), што може да значи невалиден токен за пристап, истечен токен или пак настанала некоја грешка, за во тој случај да ги пребрише податоците запишани локално во localStorage објектот и да го врати корисникот на Login компонентата. |
| | 74 | |
| | 75 | |
| | 79 | 1. Администраторот менаџира и креира корисници |
| | 80 | - Во табот "Manage accounts" од администрирачкиот панел се излистани сите кориснички профили, заедно со опциите за бришење и уредување. При клик на "Delete" се повикува функцијата deletePharmacyHead() која ја повикува сервисната метода од дата сервисот за бришење на корисник. Додека пак при клик на "Edit" се повикува функцијата openEditPharmacyHeadDialog() при што се отвара дијалог компонента со полиња за уредување на податоци за корисникот. По затворање се повикува сервисната метода updatePharmacyHead() од дата сервисот и се праќа уредениот корисник на backend па соодветно се уредува во базата. |
| | 81 | - Табот "Create new account" содржи форма за креација на нов корисник - Агент. По пополнување, со клик на копчето "Create" се повикува функцијата createHead() која ја повикува сервисната метода insertPharmacyHead() од дата сервисот, со што се испраќа HTTP POST барање до backend-от и новиот корисник се креира во база. |
| | 82 | |
| | 83 | 2. Агентот испраќа барање за аптека |
| | 84 | - Во табот „Сите аптеки“ се достапни сите аптеки во табела, и до нив се наоѓа "Claim" функционалноста што служи за испраќање на барање за добивање на привилегии за уредување на аптеката. При клик се повикува функцијата claimPharmacy(), со што сервисната метода од дата сервисот испраќа HTTP POST барање до backend-от, со објект кој ги содржи аптеката и корисникот. |
| | 85 | |
| | 86 | 3. Администраторот прифаќа или отфрла барања |
| | 87 | - Во табот "Claiming requests" во администрирачкиот панел во табела се излистани сите барања испратени од корисниците и аптеките, со контроли за прифаќање и одбивање на барањата. "Approve" ја повикува функцијата approveRequest(), а "Reject" ја повикува rejectRequest(), кои потоа се проследуваат до соодветните сервисни методи од дата сервисот кои испраќаат барања до backend-от. |
