WEB СИСТЕМ ЗА УПРАВУВАЊЕ НА ONLINE СПИСАНИЈА
Содржина
1 ВОВЕД (INTRODUCTION)
2 КОРИСТЕНИ ТЕХНОЛОГИИ
3 ФУНКЦИОНАЛНОСТИ НА WEB СИСТЕМОТ
3.1 VOLUME (СПИСАНИЕ)
3.2 ISSUE (ИЗДАНИЕ)
3.3 SECTION (СЕКЦИЈА / КАТЕГОРИЈА)
3.4 ARTICLE (СТАТИЈА)
3.5 USERS (КОРИСНИЦИ)
3.5.1 ADMINISTRATOR (АДМИНИСТРАТОР)
3.5.2 EDITOR (ЕДИТОР)
3.5.3 REVIEWER (РЕВИЗОР)
3.5.4 AUTHOR (АВТОР)
3.6 ПРОЦЕС НА ОБЈАВУВАЊЕ (ПУБЛИКАЦИЈА) НА СТАТИЈА
3.7 КЛУЧНИ ЗБОРОВИ (KEYWORDS)
3.8 КОРИСНИЧКИ ДЕЛ НА СИСТЕМОТ
3.8.1 ПРЕБАРУВАЊЕ И ФИЛТРИРАЊЕ ПО ЕНТИТЕТИ
3.8.2 СТРАНИ ЗА ПРЕГЛЕД НА ЕНТИТЕТИТЕ
3.8.3 ОСТАНАТИ СТРАНИ
4 ЗАКЛУЧОК (CONCLUDING REMARKS)
1 Вовед (Introduction)
Целта на проектот е да се развие прототип на web систем за управување на online списанија (за академски цели), кој обезбедува автоматизација на дел од секциите на веќе постоечките системи од ваков тип. Со самото тоа е определена и таргет групата на корисници, а тоа е претежно академската фела на граѓани. При развојот на овој систем како главна технологија се користи PHP Framework-от Yii2, кој своевремено беше сосема нова технологија при започнувањето на развојот на системот (само еден месец по неговото пуштање во официјалана употреба). Во овој опис накратко ќе бидат опишани користените технологии за развој и како тие се интегрирани меѓусебно, за како крајна цел да се добие еден прототип на web системот кој што во иднина може да продолжи да се развива со цел да се добие комерцијален продукт.
2 Користени технологии
Во согласност со самото име на предметот, целокупната имплементација на системот се стреми кон објектно-ориентираните концепти од областа на програмирањето. Web системот е развиен во PHP Framework-от Yii2, којшто всушност е MVC базиран (М – model, V – view, C – controller). Повеќе детали за оваа технологија може да се најдат на следиот линк: http://www.yiiframework.com/doc-2.0/guide-README.html. MVC концептот всушност претставува архитектура која што е поделена на три основни принципи. Главните фукнционалности на принципите и начинот на кој што се имплементирани, може незначајно да се разликуваат од технологија до технологија (од еден Framework до друг). Во продолжение концептите се образложени конкретно за технологијата која што е користена во рамките на проектов: • Model (модел) – моделите претставуваат ентитети кои се независни од останатите два принципи. Тие се во строга врска со базата на податоци и преку нив се опишани структурите на табелите во базата, типовите на податоци (колоните во табелата) и релациите помеѓу табелите (претставени како релации помеѓу моделите). Самите модели се основните ентитети преку кои се пристапува до податоците во базата и има неколку начини на кои може да се изврши пристапот (преку регуларните SQL упити – за кои е потребно соодветното познавање на SQL јазикот или преку користење на вградените Yii2 команди, кои значително ја олеснуваат читливоста и го намалуваат количеството на линии на код кои се потребни за извршување на одредена акција). При развојот на системот, за пристапот до податоците од базата е искористен вториот начин на пристап т.е. вградените Yii2 команди. • View (поглед) – ентитети кои го обезбедуваат корисничкиот интерфејс и кои се одговорни за визуелните впечатоци на крајниот корисник. Доколку програмерските професии се поделат на front-end и back-end улоги, што всушност е најчеста и најпродуктивна практика на софтверските компании во Македонија (а и во странство), овој ентитет е местото каде што најголемиот дел од работата го извршуваат front-end програмерите и каде што се имплементираат и комбинираат технологиите: HTML, CSS, JavaScript и се што е поврзано со client-side делот од системот. • Controller (контролер) – спротивно од претходниот ентитет, најголемата работа во контролерите ја извршуваат back-end програмерите. Тоа е делот кој што ги спојува моделите со погледите и местото каде што се одвива најголемиот дел од логиката. Се започнува од URL рутите, од каде што се врши мапирање за тоа кој контролер (и која акција) ќе се извршува во зависност од внесената URL адреса во прелистувачот. Самиот контролер се состои од акции, при што секоја акција всушност претставува метод. Во рамките на секоја акција е сместена целокупната логика за тоа што треба да се изврши, се дефинираат потребните модели по што се повикуваат нивните соодветни методи (во зависност од тоа што треба да се изврши во тековната акција) и со тоа податоците од базата (најчесто) се сместуваат во самите моделите. На крајот, акциите во контролерите како резултат ја враќаат патеката до соодветните погледи (со проследување на добиените резултати во моделите) со што потоа податоците од моделите се прикажуваат во погледите. При развојот се искористени прилагодени Yii2 логери, кој што во случај на серверска грешка, логираат соодвента порака која што е од огромна помош при програмирањето (се наоѓаат во фолдерите “backend/runtime/logs” и “frontend/runtime/logs”). За подобро следење на напредокот на проектот и за подобра транспарентност и флексибилно менување на компјутерот за работа, целиот проект е прикачен на репозиториум на https://www.github.com. На слениов линк: https://github.com/ivan0071/web-journal-demo е прикажан пристап до проектот од каде што преку секцијата “commits” може да се следи целокупниот развој на апликацијата од самото нејзино прикачување во репозиториумот па се до нејзината крајна верзија (слика 2.1). При почетокот на развојот на проектот како основна алатка за користење на Git технологијата, беше користењето на командниот прозорец “GitBash”, каде што рачно беа внесувани командите за “push” и “pull” на кодот од серверот. Поради замената на хардверот во меѓувреме, не сум во можност да ставам екрански снимки за демонстрација на командите. Во продолжение накратко е прикажан концептот на користење на командите, но бидејќи тоа веќе излегува од главната тема на семинарската, командите нема да бидат детално објаснети: $ git status проверка за извршена промени на датотеки во тековниот репозиториум (директориумот каде што е проектот); $ git add * вклучување на сите тековни промени на датотеки во фаза, спремна за нивно додавање во тековниот репозиториум; $ git commit -m "add test commit" извршување на “pull” команда на локално ниво т.е. вклучување на промените во репозиториумот, проследени со краток опис; По извршувањето на претходните три команди (за локално ниво), се извршува синхронизирање на истите со соодветениот репозиториум, поставен на серверите на GitHub, преку командата: $ git push https://github.com/ivan0071/web-journal-demo.git master enter username: ******** enter password: ******** По споменатата замена на хардверот, процесот за работа со GitHub е автоматизиран со користење на соодветен софтвер SourceTree (https://www.sourcetreeapp.com/). Останати користени технологии при развојот на овој систем се претежно оние стандардните без кои web програмирањето не би било на тоа ниво на кое што е денес: HTML, CSS, Bootstrap, JavaScript, jQuery, Ajax, MySQL. Во продолжение следува терминологија која што е тесно поврзана со алатките на самата Yii2 технологија. Со оглед на тоа дека целокупниот кориснички и администраторски дел се направени да бидат со “responsive” дизајн, користењето на класите од Bootstrap е неизбежен дел од развојот. Yii2 Framework-от нуди автоматска поддршка на оваа технологија, па не е потребно дополнително вклучување на датотеки од надворешни локации. Се што е потребно е да се изврши регистрирање во множеството од алатки (“backend/assets” и “frontend/assets”) на идентичен начин како што е неопходно да се регистрира секоја нова css или js скрипта. Постојат два вида на пакети на Yii2 Framework-от со кои може да се започне една апликација: “basic” (основен) пакет и “advanced” (напреден) пакет. Разликата е во тоа што основниот пакет содржи архитектура под претпоставка дека станува збор за web страна или едноставна web апликација со само кориснички дел (или и администраторски дел чија што структура не е многу сложена) т.е. сите контролери, модели и погледи се сместени на едно исто ниво. Од друга страна пак, напредниот пакет е наменет за апликациите кои што содржат посложен администраторски дел и нуди дополнително ниво на заштита и безбедност со тоа што целокупната архитектура на проектот е поделена на два нивоа: администраторско ниво (backend) и корисничко ниво (frontend). Двете нивоа може да се однесуваат како две различни апликации со оглед на тоа дека иницијалата структура им е поделена во посебни директориуми. Во поглед на имплементацијата на некои функционалности, постои разлика во начинот на кој таа е извршена со тоа што основниот пакет е полесен за работа – бидејќи поголемиот дел од дискусиите кои можат да се најдат на интернет се наменети за овој тип на пакет. Дополнително, во напредниот пакет постои едно “меѓу” ниво (common), кое е заедничко и во него се сместуваат ентитите кои се заеднички за двете нивоа. Во конкретнава апликација, во заедничкото ниво се сместени сите модели (поради тоа што е потребно да се пристапува до сите модели и од корисничкиот и од администраторскиот панел), сите е-маил шаблони (за е-маил известувањата се користени шаблони за поголема транспарентност при евентуални промени) и директориумот каде што се сместуваат прикачените слики (од страна на корисниците) поврзани со корицата на изданијата. Токму поради причината што се користи напредниот пакет, погоре објаснетите логери и регистрација на датотеки се наоѓаат на две локации (по една за секое ниво). За било какви промени на структурата во базата (креирање, ажурирање или бришење на табели) се користат Yii2 миграции – со цел да биде овозможена поголема транспарентност при евентуална тимска работа и при воведување на нови програмери во проектов. Со ваквиот тип на миграции, не е потребно соодветно експортирање / импортирање на базата на податоци или пак нејзино рачно менување, бидејќи целата нејзина структура е дефинирана во рамките на самиот код (во миграциите). Истите се повикуваат и извршуваат преку командниот прозорец во неколку чекори: креирање на скрипта преку соодветната команда, внесување на кодот за миграција во скриптата и извршување на скриптата. Повеќе детали за овие чекори може да се најдат на официјалниот линк: http://www.yiiframework.com/doc-2.0/guide-db-migrations.html, а миграциите за конкретниов систем се наоѓаат во “console/migrations”. По креирање на нова табела во базата на податоци (со користење на миграции), следено се креира модел за истата таа табела. Моделите, а најчесто и контролерите и погледите, се креираат преку алатката на Yii2 Framework-от наречена Gii. До истата се пристапува преку релативните линкови “/backend/web/gii” и “/frontend/web/gii”, но само во случај кога системот е хостиран на локален хост.
Дополнително, користени се Yii2 екстензии за кои деталите и начинот на употреба може да се најдат на следниов линк: http://demos.krajee.com/. Информации за екстензијата за вгнездените форми, може да се најдат на следнив линк: http://wbraganca.com/yii2extensions/yii2-dynamicform. За вклучување на сите нив во проектов (инсталирање), користен е “composer” (https://getcomposer.org/doc/00-intro.md).
3 Функционалности на web системот
Web системот се состои од два дела: кориснички дел и администраторски дел. Корсничкиот дел е сето она кое што е достапно и презентирано на целокупната јавност. Тој е достапен за секого без притоа корисникот да треба да се регистрира и да се логира. Спротивно на тоа, администраторскиот дел е достапен само за оние корисници кои веќе имаат регистрирани профили и истиот содржи поголем број на податоци за сите ентитети кои се поврзани во системот. Секој од корисниците може самиот да се регистрира со својата е-маил адреса, но тоа не значи дека истиот добива пристап до сите податоци. Корисниците може да имаат повеќе улоги и во зависност од улогите кои што ги поседуваат, секој од нив има различни привилегии и пристапност до соодвентни податоци кои се поврзани со корисничкиот профил. Со оглед на тоа дека основната цел на системот е процесот на управување на online списанија, во адимнистраторскиот дел се достапни сите ентитети потребни за процесот на креирање и објавување. Во истиот може да се управуваат самите статии (article/s), секциите (section/s) во кои чии што склоп е секоја статија, изданијата (issue/s) кои се составени од по неколку секции и крајните списанија (volume/s) кои што може да имаат повеќе изданија. За подобро разбирање на функционалностите на администраторскиот дел од системот, најпрво ќе бидат разгледани ентитетите поврзани со статиите, а потоа ќе бидат разгледани и самите корисници (заедно со привилегиите кои тие ги поседуваат) во зависност од улогите кои ги имаат. Доколку читателот би сакал и практично да го следи процесот на работа, како што ќе биде опишано ви продолжение, пожелно е истиот да биде најавен со профил кој ги има сите администраторски привилегии (username: ojsadmin, password: admin@ojs.com).
3.1 Volume (Списание)
Списанието претставува збирка / колекција на повеќе изданија во текот на една година. Соодветното мени за списанијата е достапно само за корисниците кои ја имаат улогата на администратори. Само администараторите во системот ја имаат можноста да креират нови и да ажурираат постоечки информации за списанијата. Секое едно списание ги содржи само основните податоци: неговото име и годината во која што истото ќе биде издадено. Во продолжение се дадени екрански снимки од администраторскиот дел на страниците од каде што се управуваат податоците за списанијата. Во самата основна форма за креирање / ажурирање на податоците, вгнездена е дополнителна форма со полиња за основните податоци на изданијата (име на изданието и корица за истото). Целта е да при креирање на одредено списание, да може директно веднаш да се внесат информации за барем едно издание од списанието, со што иницијално се поставува релацијата помеѓу едно списание и едно издание. Подоцна, оваа релација може да се промени преку формата за ажурирање на изданијата, каде што истото може да се префрли во друго списание. Една од главните причини за внезденоста е тоа што во случај на повеќе изданија, визуелно се има поголема прегледност на нивниот редослед во рамките на едно списание (одозголе па надолу) и редоследот може многу лесно да се промени во секој момент, само со drag-and-drop на глувчето. По креирањето / ажурирањето на одредено списание, се врши пренасочување на страната за преглед на информациите за истото. Обично страните за преглед на одреден ентитет, ги содржат поголемиот дел од детали за истиот тој ентитет (во случајов списанието). Вгнездено под информациите за списанието, се излистани и основните информации за неговите изданија (проследени со линкови за преглед и ажурирање). До двете страни од Слика 3.1.1 и Слика 3.1.2 може да се дојде и преку прегледот на листата од списанија (Слика 3.1.3) каде што истовремено е овозможено и филтрирање на листата по наслов и по година, што може да биде од голема корист во случај кога има голем број на записи ви листата.
3.2 Issue (Издание)
Издание претставува единечен број на едно списание и како такво тоа содржи дополнителни податоци кои се поврзани со истото (дефинирани во спецификацијата на проектот). Листата од изданија во системот се прикажува на истиот начин како што е случај и за списанијата. И во оваа листа постои можност за филтрирање по одреден број на параметри специфични за едно издание. Поради тоа што вгнездено беа креирани две изданија (со креирањето на списанието во примерот погоре) тие се веќе дел од системот и се дел од листата со изданија. Со оглед на тоа што секое издание се состои од неколку секции (категории), со самото креирање на едно издание автоматски се креира и една default секција (“Original/research articles”). Во продолжение е прикажано ажурирањето на едно од двете претходно креирани изданија. И кај изданијата, на ист начин како кај списанијата, под соодветните параметри во формата постои дополнителна вгнездена форма за управување со секциите. И овде редоследот е многу важен (одозгоре па надолу), бидејќи со него е одреден редоследеот по кој секциите ќе се прикажуваат во рамките на изданието. Како што е споменато погоре, во оваа форма има опција за промена на списанието во кое е ова издание и при вршење на самата промена, преку drop-down листа може да се избере било кое од списанијата во системот, така што ќе се креира нова релација и изданието автоматки ќе се постави како последно во листата на новото списание за кое што ќе биде изберено. Исто како списанијата и изданијата се управувани само од страна на администраторот, но за ослободување од одговорнаста да не мора да ги управува сите изданија на сите списанија, тој во формата од Слика 3.2.2 преку избор на еден корисник од листа на корисници може да се додаде Special (Guest) Editor (во листата се достапни само корисниците кои ја имаат улогата на едитори) при што понатамошно управување на изданијата (освен администарторот) ќе може да врши и избраниот едитор – привилегиите на корисниците ќе бидат подетално разгледани подолу. Само едно од изданијата во целиот систем може во даден момент да биде означено како тековно издание (current issue) и во моментот кога едно издание се постави како такво, сите други се проверуваат и во случај да е пронајдено некое издание, истото се ресетира да не е означено како рековно. Подоцна, тековното издание заедно со деталите за истото, се прикажува во корисничкиот дел од системот. Откако одредено издание е поставено како тековно, во листата на администраторскиот дел тоа се разликува од другите, при што редот каде што се наоѓа, е обоен со зелена боја, како на Слика 3.2.4.
3.3 Section (Секција / Категорија)
Секциите во рамките на едно издание на списанието групираат повеќе сродни статии. Во рамките на едно издание мора да има барем една секција и токму тоа е причината зошто системот автоматки ги креира како што беше во примерот погоре, кога изданијата беа вгнездено креирани во списанието. Истото може да се забележи и од Слика 3.3.1 каде што во рамките на списанието кое го креиравме (“Volume No.2”) се гледа дека има две секкци – по една за секое издание, иако никогаш не беа рачно креирани. Во продолжение е прикажано како се креира нова секција, при што важат истите принципи како и за претходно разгледаните ентитети. Вгнездено во рамките на секцијата може да се креираат статии и да им се менува редоследот (чии што редослед е многу важен). Исто така постои опцијата за промена на секцијата од едно издание во друго, при што во новото издание автоматски ја има последната позиција во редоследот, па за промена на позицијата во истата, треба да се посети формата од Слика 3.2.2 погоре. И прегледот на секциите е базиран на истот принцип како и претходните слични страни. Корисникот истовремено има преглед во сите статии кои се поврзани за статијата, во изданието во чиј рамки се наоѓа секцијата и во списанието во чиј што рамки се наоѓа изданието кое ја содржи секцијата. Ваквиот начин на презентација на податоците дозволува многу лесна навигација помеѓу сите поврзани ентитети за конкретната секција. Истиот принцип се следи при сите страни од овој тип.
3.4 Article (Статија)
Статијата е основниот и главен ентитет. Секоја статија е објавена во некое издание од одредено списание, во рамките на некоја секција. Корисниците во главно го посетуваат системот со цел да ги читаат статиите. Формата за внесување на нова / ажурирање на постоечка статија е прикажана на Слика 3.4.1 подолу. Основни вредности во рамките на една статија се апстрактот и содржината и вредностите за истите се внесуваат преку текст едитори со тоа што е овозможено и форматирање и стилизирање на текстовите (rich text editor). Оваа форма не е иста за сите корисници и зависи од статусот кој ја има статијата и од привилегиите кои ги има корисникот (разликите ќе бидат спомнати при објаснувањето на улогите кои ги имаат корисниците). Во продолжение е разгледано сценариото кога корисникот ги има сите администраторски привилегии. Овозможено е избор / промена на секцијата во која се наоѓа статијата (важат истите правила за редоследот како и кај претходно опишаните ентитети), додавање на ревизори (од листа во која се излистани само корисниците од систмот кои ја имаат улогата на ревизор) – корисниците кои треба да вршат ревизија на статијата и да дадат своја оценка и коментари, додавање на едитори (од листа во која се излистани само корисниците од системот кои ја имаат улогата на едитор), додавање на автори (од листа во која се излистани само корисниците од системот кои ја имаат улогата на автор), избор на еден од тие автори како автор за комуникација кои ќе добива известувања поврзани со статијата преку е-маилови, и додавање на клучни зборови (од листа во која се излистани сите клучни зборови кои постојат во web системот). дали да се праќаат е-маилови при промена на статусот на статијата (првиот параметар во формата) – по default е поставена да е активна, претпоставувајќи дека статијата ќе го минува нормалниот тек на објавување (публикација). Во случај кога администраторот ги завршува сите чекори, без притоа да се чека на друите корисници, оваа вредност треба да се деактивира за да не праќаат известувања на е-маил при процесот на објавување. Процесот за промена на статусот на статијата и чекорите за објавување, ќе бидат објаснети подолу. Во продолжение се прикажани страните за преглед и за листање на сите статии, на идентичен начин како што беа дадени и за претходно опишаните ентитети. Еден од достапните филтри при листањето на статиите е и филтерот за статус на статиите, кој би бил од голема корист во случаи кога бројот на статии е поголем. Како што може да се забележи и од сликите за статиите, во самото мени за разлика од претходните ентитети, за статиите има уште еден дополнителен избор “My Articles” каде што на ист начин е прикажана листа од статии, но во тој случај се излистани само оние статии каде што тековниот корисник се наоѓа во улога на автор. Изборoт за преглед на сите статии го има само администраторот. Сите други останати типови на корисници имаат пристап само до листата од статии во кои тие се автори.
3.5 Users (Корисници)
Постојат неколку типови на корисници во системот: администратор, едитор, ревизор и автор. Секој корисник може да има повеќе улоги истовремено. Регистрацијата на кориснички профили во системот се прави на два начини: корисникот може сам да се регистрира преку корисничкиот дел или пак администраторот може да регистрира корисници преку администраторскиот панел. Дополнително, секој еден корисник (без разлика на привилегиите кои ги поседува) може да регистрира корисници во системот, но без притоа да се регистрираат кориснички профили (овој начин ќе биде објаснет подолу). По регистрацијата, корисникот добива порака на наведената е-маил адреса при регистрацијата и истиот не може да се најави на профилот се додека не го потврди својот идентитет преку линкот добиен во пораката. Доколку станува збор за злоупотреба на идентитетот т.е. е-маил адресата, добиената порака покрај линкот за потврда, содржи и линк за откажување на регистрацијата, со што корисникот веднаш се деактивира. По потврдувањето, преку формата за логирање од Слика 3.5.2 корисникот се најавува во својот профил. Истата форма за најава се користи за сите типови на корисница, а во самиот процес на најава се врши детекција на привилегиите кои што корисникот ги има и во зависнот од тоа се одредува кои мениа и кои секции ќе бидат прикажани. Во конкретниов прикажан пример, регистрираниот корисник ги има само основните привилегии (на автор) и како таков ги има само основните можности потребни за додавање на нова статија и за прегледување и управување на статиите во кои што истиот се појавува како автор (достапните функционалности ќе бидат разгледани подолу). Другиот начин за регистрација е кога регистрацијата ја извршува администраторот. Во основа, тоа е истата форма како и од корисничкиот дел, со таа разлика што корисниците креирани од страна на администраторот немаат потреба од потврдување на профилите. Тие не добиваат пораки со линкови за потврда за да може да влезат во нивните профили. Формата од администраторскиот дел е прикажана на Слика 3.5.5, а креираниот корисник (од примерот) ги има улогите на автор, ревизор и едитор. На Слика 3.5.6 е прикажана листа од корисниците во системот каде што администраторот е пренасочен веднаш по креирање на нов корисник. Истата таа листа која што е достапна само на администарторот е многу важен дел од системот поради причината што: при регистрација на корисниците од корисничкиот дел (Слика 3.5.1), корисниците може да си изберат да ги имаат привилегиите само на автори и ревизори. Доколку е потребно некој од нив да му се додели улогата на едитор или на администартор, потребно е да се контактира администарторот и да се извести за тоа. Преку листата на корисници тој го отвара соодветниот корисник при што истиот се отвара преку форма идентична како онаа за креирање (Слика 3.5.5), каде што е овозможено доделување на улогите и на едитор и на администратор (што не е случај на формата во корисничкиот дел од системот). На идентичен начин како што е прикажана листата од сите корисници, преку администраторското мени може да се видат и листите спред типот на корисник, на пример листа составена само од администраторите, само од авторите, само од едиторите или пак само од ревизорите. Како што е веќе споменато, секој еден корисник (без разлика на привилегиите кои ги поседува) може да регистрира корисници во системот, но без притоа да се регистрираат кориснички профили. Целта е корисниците кои немаат кориснички профили во системот, да може да се додават како автори при процесот на креирање / ажурирање на статиите (Слика 3.4.1). Со оглед на тоа дека овој тип на корисници (сеуште) немаат профили, тие не се известени на е-маил и нема поле за внесување на лозинка. Бидејќи секој има пристап до функционалноста за креирање на ваков вид на корисници (што всушност е и неопходно да се направи во процесот на креирање на нови статии – во делот за внесување на автори кои што не се дел од системот) овој тип на корисници се тип на “не-регистрирани корисици” со цел да се спречат злоупотреби. При нивното креирање, истите се веднаш достапни во листата за избор на автори на статиите. Надоградбата на не-регистриран корисник во регистриран корисник со кориснички профил може да се прави од страна на самиот корисник (кој што го поседува е-маилот) или од страна на администраторот. Не-регистринатите корисници се видиви во администраторскиот дел за сите типови на корисници (исто и корисниците со улога на автор се видливи за сите типови на корисници) и кога нивните детали ги прегледува администраторот, тој всушност овие податоци ги гледа во формата за регистрација (Слика 3.5.5) и во секој момент може да го надополни полето за лозинка и со тоа да креира кориснички профил за е-маил адресата (на идентичен начин како што тоа беше опишано претходно). Доколку ги гледа корисникот кој што всушност ги креирал, тој ја гледа истата форма од Слика 3.5.9 и како нивен креатор, може да врши промени на внесените податоци. Иако овие корисници не се регистрирани, со цел да се спречи злоупотреба, сите останати типови на корисници (освен креаторот и администарторот) имаат можност само да ги гледаат податоците и истите немаат можност да вршат никакви ажурирања врз нив. При обид за регистрација на нов корисник, со цел да се отстранат сценаријата за дупликати и злоупотреба, се проверува дали корисничкото име или лозинката веќе постојат во системот. Истата проверка е искористена и за вршење на надоградба на не-регистриран корисник од страна на оној кој што ја поседува е-маил адресата. Во продолжение е прикажан процесот на ваквиот тип на надоградба: откако е прикажана пораката за дупликат (Слика 3.5.11), на корисникот му е понудена можност да добие порака на е-маил адресата со понатамошни инструкции (Слика 3.5.12) при што му се дава и информацијата за тоа кое корисничко име е искористено за постоечката е-маил адреса. По кликот од линкот добиен на е-маил (валиден само 24 часа – во случај да станува збор за злоупотреба, валидноста на линкот истекува) се појавува форма за креирање на лозинка (Слика 3.5.13) со што всушност се креира профил во системот и веднаш корисникот се пренасочува на формата за логирање (Слика 3.5.14) каде што може да ви внесе потребните информации за по прв пат да влезе во системот. Понатаму, доделени му се информациите кои ги поседувал како не-регистриран корисник и истите може да ги ажурира во секое време, како и секој друг корисник. Дополнително, секој корисник без разлика на привилегиите кои ги поседува, во горниот десен агол од администарторскиот панел (линкот “My Profile”) може да пристапи до форма за ажурирање на личните податоци, која во основа е идентична на формата од Слика 3.5.5. Во случај на заборавена лозинка / или корисничко име, секој корисник може да поднесе барање за промена на истата (преку линкот од Слика 3.5.14), при што преку потполнување на формата од Слика 3.5.15 добива понатамошни инструкии на е-маил адресата (Слика 3.5.16). Во добиената порака може да го види корисничкото име (при што не мора да продолжува понатаму – во случај да го заборавил само корисничкото име), а по кликот на линкот во пораката, се пренасочува кон форма за внесување на нова лозинка (Слика 3.5.17). Процесот за ресетирање на лозинката е прикажан на сликите во продолжение.
По објаснувањето на начинот на регистрација, прегледот на корисниците и нивно управување, следува подетално запознавање со типовите на корисници и привилигиите кои тие ги поседуваат.
3.5..1 Administrator (Администратор)
Администраторските привилегии се привилегии од највисоко ниво. Најголемиот дел од претходните екрански снимки се извршени преку профил со администраторски привилегии. Само еден е главен администратор (тоа е корисникот кој што прв рачно е внесен во системот) и истиот ги добива пораките (на својата е-маил адреса) кои крајните корисници ги праќаат преку контакт-формата во корисничкиот дел (Слика 3.5.1.1). Е-маил адресата за администарторот е внесена во самиот код и при евентуална надоградба на системот, многу лесно може да се генерализира за пораките да ги добиваат сите корисници кои што ја имаат улогата на администратор. Како што веќе беше споменато погоре, администраторите се единствените кои што имаат пристап до листата од сите статии во секој момент, до листата од сите корисници, до листата од корисниците според типот (администратори, едитори и резизори). При прегледот на одредени форми (за изданијата, за секциите и за статиите) администраторите (а воедно и едиторите кои се зададени) имаат пристап до дополнителни полиња во формите, кои што не се видливи за авторите и ревизорите. На пример: во формата за статии (Слика 3.4.1) само администраторите и едиторите можат да ги гледаат полињата за внесување на едитори, за внесување на ревизори, за избор на соодветна секција и за избор на тоа дали да се праќаат е-маилови при промени на статусот на статите. Целта е да се ограничат привилегиите според одредена хиерархија со цел да се избегне злоупотреба од страна на секој кој што би се регистрирал во системот. Администраторите се единствените кои можат да ја контролираат секцијата со додавање блогови. За таа цел во администарторскиот панел се наоѓа соодветното мени “Announcements”, од каде што има опција за додавање на нов / ажурирање на постоечки блог пост (Слика 3.5.1.3), опција за детален преглед на блог пост (Слика 3.5.1.4) и опција за преглед и управување на листата од постоечките блог постови (Слика 3.5.1.5). При прегледот на листата од блог постови, постои можност за менување на видливоста на секој од постовите (во случај да треба да остане во системот, но да не биде видлив за јавноста) и можност за промена на редоследет по кои тие ќе бидат прикажани (со опцијата за drag-and-drop). По управувањето со блог постовите од администарторскиот дел, истите се достапни на јавноста преку корисничкиот дел од системот. Во продолжение на Слика 3.5.1.6 е прикажана истата листа на корисничкиот дел, а на Слика 3.5.1.7 е прикажан деталниот преглед за еден од постовите. Друга функционалност која што е достапна само за корисниците со администраторски привилегии е управувањето на содржината на главната (насловна) страна на корисничкиот дел. Оваа функционалност е достапна во менито “Manage Home Page”, каде што во листа се прикажани две опции за “тековно издание” и “содржина на страната” (Слика 3.5.1.8). Администраторот може да го менува редоследот за тоа како ќе бидат прикажани на главната страна и може да ја менува видливоста за тоа дали да се прикажуваат на главната страна или не. Со клик на опцијата за “тековно издание” се оди кон преглед на тоа како ќе изгледа соодветната секција во главната страна на корисничкиот дел (Слика 3.5.1.9), додека пак со клик на опцијата за “содржина на страната” се оди кон едитор каде што може да се креира / ажирира текст кој ќе биде прикажана во соодветна секција (Слика 3.5.1.10). Според избраните опции од овие две екрански снимки, крајниот изглед на главната страна на корисничкиот дел е прикажан на Слика 3.5.1.11.
Една од најважните улоги кои ги има админстарторот е процесот на објавување (публикација) на статиите, преку соодветни промени на статусот на истите. Процесот се состои од неколку чекори, а истиот е прикажан подолу.
3.5..2 Editor (Едитор)
Корисниците кои ги имаат улогите на едитори, по најавата во администраторскиот дел имаат дополнително мени, карактеристично само за овој тип на корисници (“Editor Menu”). Преку ова мени, едиторите имаат пристап до листата од изданија каде што се поставени како “специјални едитори” (Слика 3.5.2.2) и до листата од статии каде што се поставени како “регуларни едитори” (Слика 3.5.2.3). И двете листи се идентични како што се и за сите други ентитети. Во истите постои можност за филтрирање по одредени параметри, како што беше случај и во претходните поглавја. Со клик на излистаните ентити, се отвараат соодветните страни за преглед и за ажурирање, на идентичен начин како што беа прикажани во претходните поглавја за администраторот. Овде се доаѓа до тоа дека администраторот ги распределува улогите за едиторите, за истиот да не мора да биде сам одговорен за сите енититети во системот. Во рамките на ентитетите каде што едиторите се доделени, може да се констатира дека тие самите ги имаат речиси сите администраторски привилегии.
3.5..3 Reviewer (Ревизор)
Привилегиите на ревизорите и нивната главна улога ќе бидат објаснети во поглавјето за опис на процесот на публикација подолу. Тие се надлежни за тоа да вршат ревизија на статиите и да ги пишуваат своите коментари, според кои на крај едиторот / администраторот одлучува дали да ја прифати / да ја одбие статијата. Засега ќе споменеме само дека исто како едиторите, и ревизорите имаат соодветно мени (“Reviewer Menu”) кое е достапно само за корисниците кои ја имаат оваа улога. Во менито е достапна оцијата за “ревизии кои чекаат на ред” и опцијата за “веќе внесени ревизии”. Овие опции всушност преставуваат листи од статии, така што: во ревизии кои чекаат на ред се излистани сите статии каде што тековниот корисник е зададен како ревизор, а сеуште не внел своја оценка и коментар, а во листата на веќе внесени ревизии се наоѓаат статиите за кои тековникот корисник е зададен како ревизор и истиот ги внел својата оценка и коментар. За статиите кои веќе е внесен коментарот, се делат на уште два типа: ревизии кои сеуште може да се ажурираат и ревизии кои повеќе не може да се ажурираат. Повеќе детали за ова следуваат во едно од следните поглавја.
3.5..4 Author (Автор)
Авторите се најосновниот тип на корисник во системот. При регистрацијата од корисничкиот дел на системот, корисниците по автоматизам ја добиваат улогата на автор (освен ако самиот корисник го промени тој избор при регистрацијата). Авторите имаат пристап до мениата кои истовремено се достапни за сите други типови на корисници и за нив нема посебно мени кое е специфично само за тој тип на корисници. Скоро сите корисници во системот ја имаат улогата на автори, но доколку некој корисник ја нема оваа улога, тогаш тој нема да има пристап до опциите “My Articles” и “Create New” од “Articles” менито. Менито за клучни зборови ќе биде објаснето подолу.
3.6 Процес на објавување (публикација) на статија
Од моментот кога една статија е внесена во системот, па се до моментот кога таа станува дел од издание на списание т.е. додека да се објави, потребно е да се помине низ неколку чекори и да се извршат ревизии. Како што е споменато во претходните поглавја, доколку администарторот ги исклучи е-маил известувањата за одредена статија, тогаш процесот кој ќе биде објаснет во продолжение нема да се извршува со оглед на тоа дека корисиците нема да добиваат известувања на е-маил и тој ќе може сам да ги заврши сите чекори. Нека за пример ја разгледаме статијата која е внесена по претходните поглавја (дадена на Слика 3.6.1). Иницијално, статијата е означена со статусот “Submitted”. Тоа е состојбата кога статијата е објавена од страна на авторот, но сеуште не е извршена промена на нејзинот статус (од страна на администраторите или од старана на едиторите). Додека е означена со овој статус, овозможено е едитирање и ажурирање на податоците во истата. Администраторите и едиторите може да ги менуваат листите за ревизори и едитори, параметри до кој авторот нема пристап. Со промената на статусот (со клик на копчето “Move for Review”) статусот на статијата се менува во “Under Review” и со тоа истата е пуштена на ревизија до корисниците кои претходно биле поставени како ревизори за истата таа статија. Со самата промена на статусот, се праќаат соодветни известувања на е-маил до авторите (поточно до само еден автор – оној кој што е внесен како “автор за комуникација” од страна на самиот креатор на статијата) за истиот да има увид во тековниот статус на неговата статија и се праќа соодветно известување до секој од ревизорите. Со тоа се менува копчето за промена на статусот со можност за премин во следниот чекор т.е. следниот статус од низата статијата (“Move to Review Required stage”) – како што е прикажано на Слика 3.6.4. Со промената на статусот, повеќе не е овозможено менување на податоците поврзани со статијата поради тоа што таа е во фаза кога ревизорите треба да ја прегледаат и да ги дадат своите оценки и коментари. Па за спречување на злоупотреба, функционалноста за ажурирање е оневозможена. Во оваа фаза настапуваат привилегиите кои ги поседуваат корисниците со улога на ревизори. Откако се пратени известувања по е-маил, статијата автоматски се додава и во менито на ревизорите во делот на “ревизии кои чекаат на ред” (Слика 3.6.5) и со клик на истата се отвара страна каде што ревизорот може да го остави својот коментар за содржината на статијата.
Се додека статијата е во овој статус, ревизорот сеуште има можност да го ажурира својот коментар и својата оценка. По оставените ревизии, следен на потег е повторно администарторот / едиторот, кој што во оваа фаза сеуште нема пристап до оставените ревизии и коментари. Тој го менува статусот на статијата во следната фаза, а тоа е “Review Required”. Во оваа фаза, повеќе не е овозможено на ревизорите да ги едитираат своите постечки ревизии. На Слика 3.6.8 е прикажан прегледот на статијата од страна на ревизорите / авторите, додека пак на Слика 3.6.9 е прикажан прегледот на страна на администарторите / едиторите. Дополнително, овоможено е оставање на коментари под секоја од ревизиите по што може да се развие комуникација помеѓу релевантните корисници. Предност е тоа што комуникацијата е во самиот систем (а не преку е-маил) и до пораките имаат пристап сите засегнати страни (со тоа сите тие се во тек за моменталната состојба на статијата). Врз основа на коментарите од дискусијата, едиторите / администраторите е потребно да донесат одлука за тоа како да продолжат со публикувањето на статијата и притоа треба да остават свој генерален коментар за донесената одлука (Слика 3.6.9). Опциите помеѓу кои корисникот може да избира се: прифаќање на статијата за публикација, одбивање на статијата и враќање на статијата во состојба за подобрување. При избор на секоја од опциите, засегнатите страни (авторот за комуникацуја и ревизорите) добиваат известување на е-маил, вклучувајќи го и генераниот коментар од едиторот / администраторот. Доколку има потреба од вршење на дополнителни промени на било кој од атрибутите на статијата, се извршува враќање на истата во состојба за подобрување т.е. во состојба на “Improvement” (известување по е-маил добива само лицето кое е поставено како автор за комуникација во рамките на статијата (Слика 3.6.11). Оваа фаза на некој начин претставува комбинација од двете фази “Submitted” и “Review Required”, поради тоа што е овозможено ажурирање на соодветни атрибути на статијата (во зависност од привилегиите кои ги поседува корисникот), а истовремено сеуште е овозможено оставањето на коментари од сите засегнати страни, како што е прикажано на Слика 3.6.10 погоре. Еден пример за користење на оваа фаза, е да може да се искористи за додавање на дополнителни ревизори од страна на администраторот. Единствена опција која е овозможена за едиторите и администраторите, е повторно поставување на статусот за ревизија од каде што повторно се доаѓа во регуларниот тек на публикација. Фазата за подобрување на состојбата всушност претставува состоба која овозможува разгранување на текот на процесот и овозможување на враќање во претходно поминатите фази, со цел на повторно ажурирање и повторна ревизија и тоа неколку пати по ред. При повторното добивање на известувања по е-маил, ревизорите се известени дека не е прв пат истата статија да им биде доделна за ревизија со цел истите да бидат запознаети дека станува збор за статија која што веќе била во фазата на подобрување (Слика 3.6.12). Истовремено и авторот назначен за комуникација добива известување дека неговата статија била повторно ставена за ревизија, откако веќе ја поминала фазата на подобрување (Слика 3.6.13). Во случај на статусот “Review Required”, другата од трите достапни опциии е да се изврши одбивање на статијата со промена на статусот во “Rejected”. Со тоа статијата автоматски добива дополнителени статус на “архивирана” статија во системот и за истата понатаму не е овозможено ажурирање или опција за повторно враќање во “активна” состојба. И покрај тоа што статијата е одбиена, ревизиите се и понатаму достапни, како и можноста за понатамошна дискусија помеѓу членовите преку коментари на веќе поставените ревизии. Архивирани статии се оние статии во системот кои го имаат статусот на одбиени статии и оние кои го имаат статусот на објавени (публикувани) статии. Сите останати статии се активни, со самото тоа што истите се сеуште под управување од страна на корисниците во систмот. При одбивањето како и при другите промени, авторот кој што е поставен како автор за комуникација добива соодветно известување на неговата е-маил адреса (Слика 3.6.14). Страната за тоа како изгледа прегледот на веќе одбиените статии, е прикажана на Слика 3.6.15 и истиот приказ е достапен за сите типови на корисници, без разлика на привилегиите кои ги поседуваат.
Третата опција која што е достапна од статусот на “Review Required”, е да се изврши прифаќање на статијата за понатамошно објавување (публикација) со промена на статусот во “Accepted for publication”. Статиите со овој статус сеуште не се објавени и ова е фазата во која што тие веќе се прифатени (можеби е извршено и подобрување на нив во фазата на “Improvement”). Како такви, следни на потег се едиторите / администарторот кој што е потребно да ги комплетираат сите информации за статијата, за тоа во која секција (од кое издание на некое списание) ќе се постави. Доколку иницијално статијата била креирана од регуларен автор, истиот немал пристап до ваквиот вид на податоци, додека пак ако статијата иницијално била креирана од администарторот истиот имал можност да го додели овој параметар уште при самото креирање. Прегледот на статиите со овој статус е идентичен за сите типови на корисници (Слика 3.6.16) и опцијата за комуникација преку коментари на ревизиите е и овде достапна. Авторот кој што е поставен како лице за комуникација, добива соодветно известување за промената на статусот на е-маил адресата (Слика 3.6.17). Откако статијата го добива статусот на прифатена статија за објавување и откако едиторите / администарторот ги завршуваат и последните подготовки за истата, се преминува кон објавување на статијата преку копчето Publish од Слика 3.6.16. Авторот за комуникација добива соодветно известување на е-маил (Слика 3.6.18), а статијата дополнително го добива статусот на “архивирана” статија, како што беше случај и при одбивањето. Прегледот на тоа како изгледа статијата е прикажан на Слика 3.6.19 и истиот важи за сите типови на корисници. Разликата од претходо опишаните состојби е тоа што, откако статијата е објавена, оставањето на секаков вид на коментари и ревизии е оневозможено, но сите претходно оставени се достапни (ова важи само за корисниците кои на било кој начин се поврзани со статијата, а не јавно за сите корисници). Со тоа што статијата е објавена, таа станува достапна во корисничкиот дел од системот, каде што не е потребен кориснички профил за да се дојде до истата. Овој процес е објаснет во едно од следните поглавја. Со оглед на тоа дека има повеќе типови на корисници и повеќе статуси на една статија, во случај да не се покриени сите сценарија во рамките на ова поглавје, истите може да се практично да се тестираат внимателно, бидејќи при развојот на системот се запазени сите сценарија за тоа која статија и во кој статус треба да биде видлива на одреден тип на корисник (на пример: за ревизорите запазена е можноста за тоа кога можат да ги ажурират своите коментари, а кога не).
3.7 Клучни зборови (Keywords)
Клучните зборови претставуваат уште еден ентитет од низата на поврзани ентитети. Како што секое списание се состои од повеќе изданија, секое издание се состои од повеќе секции и секоја секција се состои од повеќе статии, така во рамките на секоја статија постои листа од клучни зборови кои се поврзани за истата. Како и во претходните ентитети, така и овде, редоследот на клучните зборови е битен и е одреден според редоследот по кои истите се внесени. Менито за управувување на клучните зборови е достапно за сите типови на корисници. Целта е да при креирање на нова статија, да се избегнат дупликати и самиот корисник да може да провери дали потребните клучни зборови веќе ги има во системот. Доколку ги нема, овозможено е додавање на истите преку формата за додавање / ажурирање (Слика 3.7.1), а при додавањето на нов клучен збор, главниот администартор добива соодветно известување на е-маил адресата (Слика 3.7.2). При листањето на клучните зборови (Слика 3.7.3), како и кај претходните ентитети овозможено е филтрирање по одредени атрибути. Понатаму, само администарторот е оној кој што ја има можноста за ажурирање на клучниот збор, додека пак другите корисници имаат можност само за негово прегледување. На страната за прегледување на деталите за клучниот збор, излистани се сите статии каде што зборот се појавува како клучен збор. На овоj начин се има прегледност кон тоа кои статии се поврзани за одредена тема (за одреден клучен збор). Притоа, запазено е тоа, дали тековниот корисник ги има привилегиите за прегледување на статиите кои се прикажуваат во листата т.е. само администраторот, авторите и соодветните едитори и ревизори можат да ги видат статиите за кои што се поврзани.
3.8 Корисиснички дел на системот
Корисничкиот дел на системот е она кое што е достапно на сите корисници, без разлика на тоа дали имаат корисчнички профили во системот или не. Дел од корисничките страни веќе беа прикажани во претходните поглавја (насловната страна, страната за регистрација, страната за најава, страната за логирање на корисници, страната за преглед на блог постовите). Во продолжение се претставени дел од останатите страни кои не беа споменати претходно.
3.8..1 Пребарување и филтрирање по ентитети
Пребарувањето е една од поглавните функционалности во системот и истото е од најголема корист за крајните корисници кои преку оваа функционалност имаат можност за преглед кон сите поважни ентити во системот. Пребарувањето се одвива по неколку параметри и тоа: пребарување по списанија, пребарување по изданија, пребарување по секции, пребарување по статии, пребарување по клучни зборови и пребарување по автори. Пребарувањето се извршува само со клик на копчето за пребарување и за истото се достапни неколку филтри: текст поле кое пребарува според тоа дали внесениот текст се совпаѓа со било кои дел од насловот на ентитетот кој се пребарува (со користење на LIKE командата) и според буквите од англиската азбука. Филтерот со букви функционира така што филерот со текст полето се извршува само на оние ентитети кои започнуваат на избраната буква од азбуката (со исклучок на авторите, каде што избраната буква претставува прва буква од презимето на авторот). Дополнително, постои можност за тоа дали пребарувањето да ги листа само основните информации (само името на ентитетот кои се пребарува) или пак вгнездено да се прикажуваат деталите за сите поврзани ентитети. Во продолжение се прикажани само неколку комбинации од филтрите (за повеќе комбинации, може практично да се тестира пребарувањето). Во резултатите од пребарувањето се прикажани само статиите кои го имаат статусот дека се објавени (published). Доколку постои ентитет кој во своите рамки не содржи ниеден ентитет од пониско ниво, тој нема да биде прикажан во резултатите, на пример: доколку постојат списанија без ниту едно издание, изданија без ниту една секција или секција без ниту една статија, тие нема да бидат прикажани во крајниот резултат (со исклучок на при пребарување на авторите – тие секогаш сите ќе бидат излистани, без разлика дали се појавуваат како автори во некоја од статиите).
3.8..2 Страни за преглед на ентитетите
При пребарувањето и листањето на ентитетите како резултати, секој од нив е достапен како линк кои понатаму води кон страна со детали за истот тој ентитет. Во продолжение се прикажани страните за преглед на секои од постоечките ентитети. Во случај на детално пребарување и вгнездените детали водат кон соодветни страници за преглед. Делот за PDF приказ (Слика 3.8.2.4) е отворен за било какви подобрувања – со оглед на тоа дека на истот не му е посветено премногу внимание за унифицирање на стилот и користениот шаблон. За генерирање на овој документ е користена надворешната библиотека “mpfd” и со оглед на тоа дека истата има многу широк спектар на документација и можности, за истата се искористени само основните комадни за комбинирање на податоците од базата (детали: https://mpdf.github.io/reference/mpdf-functions/output.html).
3.8..3 Останати страни
Од корист на корисниците може да биде “архивата”. Тоа е страната која што ги листа сите архивирани статии кои што биле успешно објавени. И покрај тоа што и одбиените статии се архивирни во самиот систем, во корисничкиот дел се прикажани само успешно објавените. Во листата на архивата единствено не се вклучени статиите кои припаѓаат на изданието кое што во тој момент е означено како тековно издание. Како што беше прикажано претходно (во делот за администарторите), деталите за тековното издание може да бидат прикажани на главната насловна страна (доколку администарторот ја постави таа опција). Доколку тој не ја постави опцијата за прикажувањето на главната страна, корнисниците од јавноста сепак сеуште во секое време ќе имаат пристап до тековното издание. За таа цел постои страната за тековно издание која што е прикажана на Слика 3.8.3.2 подолу. Во продолжение се претставени и останатите страни кои постојат во корисничкиот дел од системот и на кои не е посветено големо внимание со оглед на тоа дека не содржат информации поврзани со главните ентитети во системот.
4 Заклучок (Concluding remarks)
Интернетот како дел од современото општество, е длабоко навлезен во секојдневието на човекот. Секојдневно се работи на web апликации кои се од голема корист во различни сфери од животот на човекот, кои всушност олеснуваат одредени сегменти од сферите на нивното делување. За таа цел постои воспоставена практика на развој на системи кои таргетираат одредена група на луѓе и нудат автоматизација на одредени процеси кои се од интерест за таа специфична група. Истовремено, технологиите постојано се надоградуваат со цел да излезат во пресрет за поефикасен развој. Yii2 Framework-от е само еден пример за тоа како веќе познатите технологии може да се прилагодат и да се комбинираат и да се приближат кон развој на нешто сосема ново, со користење на нешто што е веќе видено и познато.