Статията описва създаването на система за управление на различни потребителски роли, като всяка една може да се назначава.
Ролята като термин може да бъде описана, като списък от позволени и забранени действия на потребителите в рамките на BEST. Посредством системата за прецизно управление на ролите адмнистраторите на BEST ще могат прецизно да назначават роли които се явяват модификация на стандартно съществуващите, а преподавателите ще могат да създават и назначават нови роли в рамките на курсовете които преподават. Важно е да се поясни, че последните ще могат да управляват и назначават роли с позволения по-малки от техните. На потребителя ще може да се назначава една или няколко роли на ниво сайт или на ниво курс. Възможно е един и същ потребител да притежава различни роли на на ниво сайт и на ниво курс.
Позволения- под позволения в рамките на статията ще разбираме набор от специфични дейности които ще бъдат или не позволени на потребителите на сайта на BEST. Позволенията обикновено са добре описани. Позволенията описват ролите. В зависимост от това дали за дадена роля са включени всички типични или не позволения, различаваме пълни и непълни роли. От последното става ясно, че ролите и позволенията са в зависимост. Пример за позволение е: mod/forum:replypostСтойност на позволението- под стойност за дадено позволение тук ще се разбира например логическата стойност която се присвоява на дадено позволение. Нпример: allow или prevent
Контекст- тъй като BEST е развитие на Moodle от което се подразбира, че също е обекторинтирана платформа, състояща се от модули, блокове, курсове, форуми, формати и т.н. то в тази статия под контекст ще се разбира как дадено позволение се интерпретира в рамките на посочените елементи на архитектурата.
1. Разлика в архитектурите между BEST и Moodle по отношение на ролите и позволенията
На този етап Moodle предлага фоксиран набор статични роли. Те се свеждат само до главен администратор, администратори, автори на курсове, преподаватели-автори, преподаватели-без авторство, студенти и посетители. За всяка една от изброените роли позволенита са статични и с фиксиран брой. Пример за това е оценяването на групово задание между студенти от един курс от студенти от друг курс. В Moodle не е възможно това да бъде направено без да бъдат дадени позволения на преподаватели поне на едната група студенти. Последното ясно аргументира мотивацията за тази разработка която се описва в статията.
1.1. Новата архитектура на BEST от гледна точка управлението на ролите и позволенията
В прототипа BEST на този етап се работи над система с динамични роли. В този смисъл роли в BEST "не съществуват". Потребителите на които това е позволено могат да дефинират множество роли и да ги назначават на други потребители съгласно контекста на курса, уч. дейност, модула, блока или формата за който се отнасят.
Контекстите могат да бъдат два типа общи и специфичи. Например:
- CONTEXT_SYSTEM
- CONTEXT_PERSONAL
- CONTEXT_USERID
- CONTEXT_COURSECAT
- CONTEXT_COURSE
- CONTEXT_GROUP <<-- специфичен тип
- CONTEXT_MODULE
- CONTEXT_BLOCK <<-- специфичен тип
- .. ... ... ... ... ... ... ... ...
Ролите който могат да се назначават са динамични. Оторизираните могат да назначават прецизно произволен брой роли на произволен брой потребители, в произволен брой контексти. Например едно позволение може да има следните логически стойност (нека не забравяме, че ролите се съставят от позволения):
- CAP_INHERIT
- CAP_ALLOW
- CAP_PREVENT
- CAP_PROHIBIT
- .. ... ... ... ... ... ... ... ...
Всичко посочено по-горе показва, че сисстемата е гъвкъва по отношение управлението на множество потребители в реален модел напълно отразяващ субординацията и йерархията в едно реално учебно заведение
1.2. Типове и нива позволения в BEST
Присъщи (стандартни) позволения --> дефинирани са във lib/db/access.php
Пример: best/legacy:guest; best/legacy:student ; best/legacy:teacher ... ... ...
Позволения на ниво потребител --> best/user:readuserposts - може да чете публикуваното от потребителите на страниците на личните им профили; best/user:readuserblogs - може да чете блоговете на потребителите ; best/user:viewuseractivitiesreport- може да чете отчетите за активността на потребителите намираща се на страницата на личните им профили
Позволения на ниво модул --> добавянето на този контекст на позволенията наложи в базата данни на Moodle да бъдат направени промени описани по-долу. Сега инсталирането, деинсталирането и обновяването на модул. Сега при всяка промяна на позволенията в рамките на модул води до промяна и в неговата версия. Всеки път когато се извършва промяна в позволенията за даден модул, то това води и до промяна на неговата версия. За разлика от Moodle стремежът ни е бил към въвеждане на единна конвенция за имената на позволенията глобално при цялата система и на всички нива. При Moodle имената на позволенията са специфични за всеки един модул. Позволенията на ниво модул са дефинирани във файла mod/mod_name/db/access.php и носят обикновенно имена от типа: 'mod/mod_name:capability' Например: За модула задание - mod/assignment:view - позволено е четенето на описанието на заданието; За модула Изпит е mod/exercise:assess ; за модула Тест е mod/quiz:manage - позволено е добавянето и изтриването на тестови задаче и т.н.
В директорията db на всеки един модул е добавен файла access.php в който бяха дефинирани всички позволения. В приложения архив например се намира mod/forum/db/access.php
В този файл се намира масив съдържащ записи от типа:
'mod/forum:viewforum' => array(
'captype' => 'read',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'guest' => CAP_PREVENT,
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'coursecreator' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),
Посредством функцията get_context_instance() на всяка една страница, лесно се открива в какъв контекст работи потребителя. Например за споменатия файл това е:
$context = get_context_instance(CONTEXT_MODULE, $cm->id);
С други думи навсякъде където искаме да проверим дали потребителя има правата да извършва дадената дейност извикваме по следния начин has_capability() :
if (!has_capability('mod/forum:viewforum', $context))
{
print_error('nopermissiontoviewforum');
}Ако искате да се генерира съобщение като посоченото в кода по-горе при заявяване на позволение , т.е. да проведете тест, то тогава използвате require_capability() по следния начин:
require_capability('mod/forum:viewforum', $context);
Разбира се могат да се използват и още допълнителни параметри за генериране на широк диапазон съобщения.
Добавени таблици
2.1. 'role'
Поле Описание Тип id уникален идентификато int name кратко име на ролята varchar fullname цялото име на ролята text description Описание на ролятата text timemodified времева щампа int sortorder int courseid id от таблицата course int userid id от таблицата user- последно променяне на ролята int Бележки:
- Ролите се създават на база курс. Всички роли с идентификатор courseid=1 (курс) ще са достъпни за всички курсове
- Езиковите стрингове, ще останат само за 6 -те назначавани роли. За езиковата поддръжка другите роли могат да използват само синтаксиса на HTML тагът
<lang> в полето
'fullname'
<lang lang="en">en</lang><lang lang="de">de</lang><lang lang="ma">ma</lang>
- Списъка с участниците в курса ще бъде подреден от sortorder. Важно е да се отбележи, че ролите на ниво сайт ще бъдат изредени в списъка преди ролите на ниво курс.
За ролите на ниво сайт е препоръчително да се използват стойности в интервала 1 - 1000, докато за ролите на ниво курс: 1000+
2.2. role_capabilities
Поле Описание Тип id запис с идентификатора на потребителя int module име на модула varchar capability име на позволението varchar Бележки:
- Тази таблица взаимодейства с кода на модулите на уч. дейности
- За използването на модулите са добавени следните API функции.
add_capability ( $module, $capability )
remove_capability ( $module, $capability )Добавените функции 'role_capabilities' и 'role_allocations' ще променят таблиците
- Във файловете за езикова поддръжка са внесени имената на различните видове позволения. След тестване на BEST беше достигнато до извода, че най-подходящият формат е: prefix capability name в language string с 'апострофи'
2.3. role_allocations
Поле Описание Тип id идентификатор на записа int roleid id от таблицата role int capabilitiesid id от таблицата role_capabilities int Бележка:
- Това не е flag таблица. Записите тук са само за позволенията които са налични за дадена роля.
2.4. role_users
Поле Описание Тип id идентификатор на записа int userid id от таблицата user int courseid id от таблицана courses int roleid id от таблицата role int timestart времева щампа int timeend времева щампа int timemodified времева щампа int assignerid id от таблицата user - в смисъл кой притежава ролята int Бележки:
- Както вече беше споменато един потребител може да е притежател на различни роли на ниво сайт и на ниво курс.
- Тази таблица се попълва от софтуерните добавки за автоматично пакетно записване от импортиран файл или при ръчно записване от потребители които имат позволение да назначават роли 'assign roles'.
Оптимизации и корекции в таблиците на базата данни направени във връзка с имплементацията
- course
Наличието на потребители които сами се записват наложи въвеждането на ново поле 'default_role'.
Премахнати таблици след оптимизацията
- user_coursecreators
- user_students
- user_teachers
Нови функции в BEST въведени след имплементацията
- require_capability ( $module, $capability, $courseid )
function require_capability ( $module, $capability, $courseid) { global $USER; return ( isset ($USER->capabilities["{$module}_{$capability}"][$courseid]) or isadmin () ); }Функция на ядрото на новата система
Ако бъдат поискани позволения които не съществуват се връща логическа стойност false. Този сценарии е предотвратен тъй като кода поддържа и двете: таблицата 'role_capabilities' както и извикванията на require_capability.
- user_possesses_role_capabilities ( $role, $courseid )
връща логическа стойност true само когато потребителя притежава всички позволения типични за дадената роля, а също така се връща логическа стойност false във всички останали случаи
В процеса на работа се наложиха корекции във функциите
- isteacher ( $courseid, $userid, $includeadmin )
- isstudent ( $courseid, $userid )
- isguest ( $userid )
Възражения имам към функциите
- isteacheredit ( $courseid, $userid )
- iscreator ($userid )
Други промени
- course/loginas.php
Позволенията заложени в глобалната за BEST променлива $USER следва да бъдат свързани с логическия оператор 'AND' с реалния потребител и с псевдо-потребителя. Това беше направено с цел да се избегне придобиването на допълнителни позволения от реалния потребител при ограничаване на позволенията на псевдо потребители.
3.1. Промени на архитектурата и обратна съвместимост с базовата разработка
Глобална променлива свързана с потребителите
Инсталирането на позволенита беше постигнато посредством включването н BEST на една нова глобална променлива $USER. Формата на тази променлива е както следва:
$USER->capabilities[ best_capability ][ course_id ]
където 'best_capability' е конкатениране на полетата в таблицата 'role_capabilities'.
Запазени служебни имена на роли
- user - потребител
- admin - администратор
- teacher - преподавател- без авторски позволения
- teacheredit преподавател - автор
- student - студент
- creator - автор
- guest - гост - посетител
Ролята на "преподавател - автор" е запазена в BEST само от съображения за обратна съвместимост с базовата разработка Moodle v.1.5.4.
Таблицата user_admin също ще бъде запазена, а ролята admin ще бъде тествана само в рамките на тази таблица. Това е направено поради факта, че при тестване на позволение, ролята admin винаги ще върне логическа стойност true.
Всички позволения за посетителите, на ниво сайт ще бъдат като за ролята 'user' . Това дава възможност на администратора на BEST да назначава позволения които да прилага към всеки потребител на BEST. Например, позволението 'edit own profile' в рамките на даден модул от учебните дайности. В този случай в таблицата 'role' полето courseid ще бъде установено в състояние 0. Полетата 'timestart' и 'timeend' би могло да се използват за ограничаване на достъпа до сайта на BEST.
3.2. Изгледът на страницата за управление на ролите и позволенията
Премахнати са:
- Назначаване на преподавател
- Назначаване на автор
Добавено е:
- Редактиране на роля и позволения
При създаване на роля и назначаване на позволения за нея, потребителя може да зададе позволения не по-големи от тези които самия той притежава. Позволенията които даден потребител не притежава в своята роля ще се показват на него и на останалите потребители, но все пак ще си остават недостъпни.
Модулът за управление на позволенията се показва само при редактиране на ролите на ниво сайт.
- Назначаване на роля
По роли По потребители
По роли По потребителиПотребителите на BEST с позволения да назначават роли 'assign roles' могат да назначават роли не-по силни от тези които те самите притежават. Останалите роли не се показват в дясната колонка. Все пак, потребителите с позволения да назначават роли 'assign roles' могат да премахват роли не притежаващи всички позволения характерни за дадената роля (т.н. непълни роли което е характерно за прототипа BEST 0.9). Ролите притежаващи всички характерни за тях позволения по терминологията която започва да навлиза за BEST по този въпрос се наричат "пълни". Не бива да забравяме "стандартните" на които всички останали се явяват наследници.
Това, кой от курсовете да бъде достъпен за избиране в кутийката се определя от това в рамките на кои курсове даденият потребител има право да назначава роли и позволения 'assign roles' . Могат да се използват само наличните за този курс роли (но при описаното вече ограничение)