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

На следната табела се прикажани сработените дополнителни кориснички сценарија:

ID	Use Case
1	Се најавува со Google профил
2	Пребарува и филтрира форум
3	Преглед на објави кои чекаат одобрување од модератор
4	Добива email известувања

Use Case ID: 1 – Се најавува со Google профил

Корисникот притиска на копчето за најва со Google и се испраќа get барање до backend.
Функцијата на клиентска страна

Помошна функција во registerLoginService

Барањето е обработено од серверот со тоа што корисникот најпрво е пренасочен кон Google страницата за најава, каде корисникот го избира својот профил. Потоа Google испраќа get барање до наведениот url (​http://localhost:5001/api/auth/google/callback) со специјален код во url-от. Преку овој код функцијата passport.authenticate(...) прави барање до Google, со што го добива профилот на корисникот.

Потоа се извршува callback функцијата дефинирана со passport Google strategy, каде најпрво се проверува дали постои профил со конкретната email адреса, а доколку не постои се креира нов профил.

На крај, се генерира supabase magic link, со кој се комплетира најавата, настанува SIGNED_IN event и се воспоставува сесија, а корисникот е пренасочен кон контролната табла.

Use Case ID: 2 – Пребарува и филтрира форум

Корисникот има можност да пребарува објави на форумот според наслов, содржина и за кој дневен предизвик се однесува објавата. Исто така има можност и да го филтрира форумот според тема, односно дали објавата е за општа програмерска тема или за дневен предизвик, потоа според објави објавени изминатата недела, месец или година, според број на коментари и според специфичен датум на објава. Изборот на тема го прави корисникот кога ја креира објавата со тоа што има можност да бира помеѓу општа програмерска тема или конкретен дневен предизвик.
Промена на филтер

Функцијата applyFilters на клиентска страна

Функцијата fetchPosts на клиентска страна

При промена на некој од филтрите се ажурира соодветното поле во објектот filters. Потоа корисникот притиска Apply Filters и се извршува функцијата applyFilters каде се ажурираат forumSearchParams, а тоа предизвикува повикување на fetchPosts функцијата преку која се испраќа get барање до backend.
Помошна функција во forum service

Барањето најпрво е обработено од forum service, каде се составува соодветен url и барањето се проследува до backend.
Функцијата getforumposts во контролерот



Потоа барањето се обработува од функцијата getForumPosts во контролерот, каде според соодветните query параметри се испраќа барање до базата. Доколку корисникот внесол соодветни филтри, објавите најпрво се рангираат според функција која ги приоритизира поновите објави, но во предвид се зема и бројот на коментари, па дококлу некоја објава била „попопуларна“ ќе биде повисоко рангирана. Со тоа се воведува мала динамика на форумот.
Функцијата scorePosts во контролерот

Use Case ID: 3 – Преглед на објави кои чекаат одобрување од модератор

Корисникот пристапува до Pending панелот каде има преглед на објавите кои чекаат одобрување од модератор. Кога корисникот ќе пристапи до панелот најпрво се повикува функцијата fetchPendingPosts која испраќа get барање до backend. Барањето најпрво се обработува од review service, од каде се проследува до backend и е обработено од функцијата getPendingPosts во контролерот.
Функцијата на клиентска страна

Помошна функција во review service

Функцијата во контролерот

Исто така корисникот има можност и да го избрише барањето за одобрување на објавата со тоа што притиска на Remove Post. Потоа доколку се согласи, се повикува функцијата confirmRemoval преку која се испраќа get барање до backend. Барањето најпрво се обработува од review service, од каде се проследува до backend и е обработено од функцијата deleteReviewPost во контролерот. Функцијата на клиентска страна

Помошна функција во review service

Функцијата во контролерот