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

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

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

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

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

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

Помошна функција во „services/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.

Помошна функција во „services/forumService“

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



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

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

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

Помошна функција во „services/reviewService“

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

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

Помошна функција во „services/reviewService“

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

Use Case ID: 4 – Корисник добива email известувања

Модераторот одобрува објава за форумот и се повикува функцијата handleApprovePost, преку која се испраќа get барање до backend. Барањето најпрво се обработува од reviewService, од каде се проследува до backend и е обработено од функцијата approveReviewPost во контролерот. Притоа објавата се отстранува од табелата за објави кои чекаат одобрување и се додава во табелата на објави за форумот. Најпосле се повикува функцијата sendApprovalEmail преку која се испраќа email до авторот на објавата.

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

Помошна функција во „services/reviewService“

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

Функцијата sendApprovalEmail во „services/emailService“

Најпосле корисникот добива email дека неговата објава била одобрена.

Текот на настани е многу сличен и кога се одбива објава од страна на модераторот

Use Case ID: 5 – Модератор добива email известувања

Со помош на PM2 и node-schedule, процесот за проверка и испраќање email доколку има објави на тема дневен предизвик, кои чекаат одобрување, се извршува на секој час. Доколку постојат вакви објави преку функцијата sendHourlyReviewNotification во emailService, се испраќа известување до сите модератори. Слично на тоа, секој ден во 7 часот наутро се проверува дали има објави (од двете теми) кои чекаат одобрување повеќе од 24 часа. Доколку постојат вакви објави преку функцијата sendModeratorEmail во emailService, се испраќа известување до сите модератори.
Функцијата со која се проверува дали има објави за дневен предизвик


Функцијата sendHourlyReviewNotification во „services/emailService“

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


Функцијата sendModeratorEmail во „services/emailService“