Имплементиране на нова архитектура по отношение управлението на ролите и позволенията в BEST

 

Увод

Статията описва създаването на система за управление на различни потребителски роли, като всяка една може да се назначава.

Ролята като термин може да бъде описана, като списък от позволени и забранени действия на потребителите в рамките на BEST. Посредством системата за прецизно управление на ролите адмнистраторите на BEST ще могат прецизно да назначават роли които се явяват модификация на стандартно съществуващите, а преподавателите ще могат да създават и назначават нови роли в рамките на курсовете които преподават. Важно е да се поясни, че последните ще могат да управляват и назначават роли с позволения по-малки от техните. На потребителя ще може да се назначава една или няколко роли на ниво сайт или на ниво курс. Възможно е един и същ потребител да притежава различни роли на на ниво сайт и на ниво курс.

Позволения- под позволения в рамките на статията ще разбираме набор от специфични дейности които ще бъдат или не позволени на потребителите на сайта на BEST. Позволенията обикновено са добре описани. Позволенията описват ролите. В зависимост от това дали за дадена роля са включени всички типични или не позволения, различаваме пълни и непълни роли. От последното става ясно, че ролите и позволенията са в зависимост. Пример за позволение е: mod/forum:replypost

Стойност на позволението- под стойност за дадено позволение тук ще се разбира например логическата стойност която се присвоява на дадено позволение. Нпример: allow или prevent

Контекст- тъй като BEST е развитие на Moodle от което се подразбира, че също е обекторинтирана платформа, състояща се от модули, блокове, курсове, форуми, формати и т.н. то в тази статия под контекст ще се разбира как дадено позволение се интерпретира в рамките на посочените елементи на архитектурата.

 

1. Разлика в архитектурите между BEST и Moodle по отношение на ролите и позволенията

На този етап Moodle предлага фоксиран набор статични роли. Те се свеждат само до главен администратор, администратори, автори на курсове, преподаватели-автори, преподаватели-без авторство, студенти и посетители. За всяка една от изброените роли позволенита са статични и с фиксиран брой. Пример за това е оценяването на групово задание между студенти от един курс от студенти от друг курс. В Moodle не е възможно това да бъде направено без да бъдат дадени позволения на преподаватели поне на едната група студенти. Последното ясно аргументира мотивацията за тази разработка която се описва в статията.

1.1. Новата архитектура на BEST от гледна точка управлението на ролите и позволенията

В прототипа BEST на този етап се работи над система с динамични роли. В този смисъл роли в BEST "не съществуват". Потребителите на които това е позволено могат да дефинират множество роли и да ги назначават на други потребители съгласно контекста на курса, уч. дейност, модула, блока или формата за който се отнасят.

Контекстите могат да бъдат два типа общи и специфичи. Например:

Ролите който могат да се назначават са динамични. Оторизираните могат да назначават прецизно произволен брой роли на произволен брой потребители, в произволен брой контексти. Например едно позволение може да има следните логически стойност (нека не забравяме, че ролите се съставят от позволения):

Всичко посочено по-горе показва, че сисстемата е гъвкъва по отношение управлението на множество потребители в реален модел напълно отразяващ субординацията и йерархията в едно реално учебно заведение

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. Изисквания

Добавени таблици

2.1. 'role'

Поле Описание Тип
id уникален идентификато int
name кратко име на ролята varchar
fullname цялото име на ролята text
description Описание на ролятата text
timemodified времева щампа int
sortorder   int
courseid id от таблицата course int
userid id от  таблицата user- последно променяне на ролята int

Бележки:

<lang lang="en">en</lang><lang lang="de">de</lang><lang lang="ma">ma</lang>

 

2.2. role_capabilities

Поле Описание Тип
id запис с идентификатора на потребителя int
module име на модула varchar
capability име на позволението varchar

Бележки:

Добавените функции 'role_capabilities' и 'role_allocations' ще променят таблиците

 

2.3. role_allocations

Поле Описание Тип
id идентификатор на записа int
roleid id от таблицата role int
capabilitiesid id от таблицата role_capabilities int

Бележка:

 

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

Бележки:

 

Оптимизации и корекции в таблиците на базата данни направени във връзка с имплементацията

Наличието на потребители които сами се записват наложи въвеждането на ново поле 'default_role'.

Премахнати таблици след оптимизацията

Нови функции в BEST въведени след имплементацията

function require_capability ( $module, $capability, $courseid) {
    global $USER;
    return ( isset ($USER->capabilities["{$module}_{$capability}"][$courseid]) or isadmin () );
}

Функция на ядрото на новата система

Ако бъдат поискани позволения които не съществуват се връща логическа стойност  false. Този сценарии е предотвратен тъй като кода поддържа и двете: таблицата  'role_capabilities' както и извикванията на require_capability.

връща логическа стойност true само когато потребителя притежава всички позволения типични за дадената роля, а също така се връща логическа стойност  false във всички останали случаи

 

В процеса на работа се наложиха корекции във функциите

 

Възражения имам към функциите

 

Други промени

Позволенията заложени в глобалната за BEST променлива $USER следва да бъдат свързани с логическия оператор 'AND' с реалния потребител и с псевдо-потребителя. Това беше направено с цел да се избегне придобиването на допълнителни позволения от реалния потребител при ограничаване на позволенията на псевдо потребители.

3. Структура

3.1. Промени на архитектурата и обратна съвместимост с базовата разработка

Глобална променлива свързана с потребителите

Инсталирането на позволенита беше постигнато посредством включването н BEST на една нова глобална променлива $USER. Формата на тази променлива е както следва:

$USER->capabilities[ best_capability ][ course_id ]

където 'best_capability' е конкатениране на полетата в таблицата 'role_capabilities'.

 

Запазени служебни имена на роли

Ролята на "преподавател - автор" е запазена в 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
 
Създаване на курсове и проекти
Редактиране на други профили
Редактиране на собств. профил
Редактиране на курсове и проекти
Роли
 
Редактиране на роли
Назначаване на роли
Тест
 
Създаване на тестове
Редактиране на тестове
Преглеждане на резултатите от тестове
Полагане на тестове
Форум
 
Създаване на форуми
Редактиране на форуми
Четене във форумите
Последни публикации във форумите
Отговаряне на публикации
Стартиране на нови теми
...

При създаване на роля и назначаване на позволения за нея, потребителя може да зададе позволения не по-големи от тези които самия той притежава. Позволенията които даден потребител не притежава в своята роля ще се показват на него и на останалите потребители, но все пак ще си остават недостъпни.

Модулът за управление на позволенията се показва само при редактиране на ролите на ниво сайт.

 

По роли
По потребители
 
Назн. потребител към роря
курс:                                 роля:
Назначена на ...
Не се притеж. от ...

 

По роли
По потребители
 
Назнач. потребител къмроля
курс:                             потребител:
Назначена на ...
Възможни роли.

Потребителите на BEST с позволения да назначават роли 'assign roles' могат да назначават роли не-по силни от тези които те самите притежават. Останалите роли не се показват в дясната колонка. Все пак, потребителите с позволения да назначават роли 'assign roles' могат да премахват роли не притежаващи всички позволения характерни за дадената роля (т.н. непълни роли което е характерно за прототипа BEST 0.9). Ролите притежаващи всички характерни за тях позволения по терминологията която започва да навлиза за BEST по този въпрос се наричат "пълни". Не бива да забравяме "стандартните" на които всички останали се явяват наследници.

Това, кой от курсовете да бъде достъпен за избиране в кутийката се определя от това в рамките на кои курсове даденият потребител има право да назначава роли и позволения  'assign roles' .  Могат да се използват само наличните за този курс роли (но при описаното вече ограничение)

 

Заключение и пояснения

 

Приложение: Модули на ядрото и свързани с тях позволения