Логи Moodle: як зафіксувати докази порушення

Проблема з логами часто виникає не в момент інциденту, а значно раніше — коли ніхто не визначив, скільки їх зберігати, хто має право переглядати дані й що саме потрібно вивантажити при підозрі на порушення.

Moodle фіксує багато дій користувачів через систему подій: входи й виходи, доступ до курсу, перегляд активностей, подання робіт та інші взаємодії. Але лог — це технічний запис про подію, а не готовий висновок про академічне порушення. Він може допомогти відновити послідовність дій, підтвердити час операції або показати зміну оцінки, проте сам по собі не встановлює намір людини.

Це важливо і в контексті Закону України «Про академічну доброчесність» № 4742-IX: процедура розгляду повідомлень передбачає ухвалення рішення закладом, а технічні дані можуть бути лише частиною матеріалів такого розгляду. МОН окремо наголошує на прозорому порядку розгляду повідомлень. Тому завдання адміністратора Moodle — не «довести провину», а забезпечити збереженість і відтворюваність технічної інформації.

Що Moodle фіксує за замовчуванням

У Moodle журналювання побудоване на системі Events. Ядро платформи фіксує типові взаємодії, а більшість активностей додають власні детальні події. За MoodleDocs — Logging, серед стандартних прикладів є:

вхід і вихід користувача;
доступ до курсу;
оновлення курсу;
перегляд активності;
створення або перегляд допису;
завершення активності.

У звіті Logs викладач або адміністратор може фільтрувати дані за групою, користувачем, датою, активністю, дією та рівнем події. У записах відображаються, зокрема, дата й час, дія та IP-адреса, з якої було виконано запит. Документація Moodle також дозволяє завантажувати такий звіт у текстовому, ODS або Excel-форматі.

Для типового інциденту це дає змогу відповісти на технічні питання: чи заходив користувач у курс у конкретний час, чи переглядав певну активність, коли відкривав тест, чи виконував дію, яку Moodle журналює.

Що лог не фіксує

Стандартний журнал не записує «що студент думав» і не бачить усе, що відбувається поза Moodle. Він не може самостійно встановити, хто фізично сидів перед пристроєм, чи була поруч інша людина, чи використовувався другий телефон, чи була домовленість між студентами поза LMS.

Так само відсутність запису не завжди означає, що дії не було: конкретна подія має бути передбачена ядром Moodle або відповідним плагіном. Додаткові модулі можуть мати власне журналювання, і його повнота залежить від реалізації плагіна.

Тому до інциденту варто знати не лише «логи увімкнені», а й які саме події генерує критична для оцінювання активність.

Скільки зберігаються логи

У Moodle немає одного строку зберігання журналів, який автоматично підходить усім закладам.

Адміністратор керує log stores через:

Site administration → Plugins → Logging → Manage log stores

Стандартний Standard log store є детальним журналом, який Moodle вважає достатнім для більшості сценаріїв. Окремо Moodle підтримує External database log store — журнали можна надсилати в окрему базу даних і запитувати їх через інтерфейс Moodle.

Параметр Keep logs for розміщений у налаштуваннях log store. Саме він визначає, як довго Standard log store зберігає старі записи перед очищенням. Документація Moodle не встановлює універсального рекомендованого строку для академічних розслідувань.

Як вибрати строк

Практично строк потрібно погодити щонайменше з чотирма величинами:

Тривалість навчального циклу. Лог не повинен зникнути раніше, ніж завершиться семестр або інший період, у межах якого можуть оскаржуватися результати.
Строки внутрішньої процедури. Якщо повідомлення може надійти після завершення курсу, журнал має залишатися доступним і після фактичного оцінювання.
Політика зберігання даних. Логи містять інформацію про користувачів та їхню активність, тому «зберігати все назавжди про всяк випадок» — теж не нейтральне рішення.
Обсяг бази даних. На великому Moodle журнал може бути однією з найбільш швидкозростаючих таблиць, тому довший строк має інфраструктурну ціну.

Оптимальний строк — це не число з чужого чекліста, а параметр, який одночасно покриває процедуру розгляду і відповідає політиці зберігання.

Історія оцінок — окреме налаштування

Не плутайте логи з Grade history. Moodle окремо зберігає історію змін у таблицях оцінок, а адміністратор може задавати її строк у:

Site administration → Server → Cleanup

За MoodleDocs цей строк може налаштовуватися від 30 днів до «never». Якщо для розгляду важливо бачити, хто й коли змінював оцінку, перевіряти потрібно і log retention, і grade history lifetime.

Звіти, які знадобляться комісії

Набір даних залежить від типу інциденту. Універсального «експорту доказів» у Moodle немає, тому краще формувати пакет із кількох звітів.

1. Logs

Шлях на рівні курсу:

Course administration → Reports → Logs

Тут можна відібрати конкретного користувача, дату, активність і дію. За потреби звіт завантажується у текстовому, ODS або Excel-форматі.

Для первинної фіксації краще застосувати вузький фільтр, який безпосередньо стосується інциденту, а не вивантажувати всю історію курсу з даними десятків інших студентів.

2. Activity report і Complete report

Activity report показує активність у курсі, зокрема кількість переглядів активностей і ресурсів. Complete report дає детальніший огляд внесків та останньої активності окремого студента в курсі.

Ці звіти корисні як контекст, але не замінюють Logs: агрегована кількість переглядів не показує послідовність конкретних подій так само детально, як журнал.

3. Звіти Quiz

Для тестів відкривайте:

Quiz → Results

Moodle має окремі звіти Grades, Responses, Statistics і Manual grading. Grades report показує всі спроби, загальний результат та оцінки за питання; для кожної спроби доступні час початку, завершення і тривалість. Responses report дозволяє переглянути фактичні відповіді.

Це важливо, коли сам журнал підтверджує факт запуску тесту, але для аналізу потрібні деталі конкретної спроби.

4. Grade history

Шлях:

Course administration → Grade administration → Grade history

Звіт дозволяє фільтрувати зміни за студентами, елементами оцінювання, тим, хто виставляв оцінку, та датами. Дані можна завантажити, зокрема, у CSV або формат електронної таблиці.

Для ситуації зі спірною зміною оцінки Grade history часто інформативніший за загальний журнал.

Як не зіпсувати доказ

У цій статті слово «доказ» використовується в практичному, а не процесуально-правовому сенсі: йдеться про технічний матеріал, який можна передати уповноваженому органу закладу.

Надійний порядок роботи такий:

Спочатку зафіксуйте стан, потім змінюйте. До видалення спроб тесту, скидання курсу, ручного очищення даних або інших адміністративних дій зробіть потрібні експорти.
Зафіксуйте параметри вибірки. Запишіть курс, активність, користувача, часовий діапазон і фільтри, з якими сформовано звіт.
Збережіть первинний експорт. Не редагуйте файл, який передається як вихідний матеріал. Якщо потрібна робоча таблиця з сортуванням або коментарями — створіть копію.
Зафіксуйте, хто і коли виконав експорт. Це не технічна функція Moodle, а елемент внутрішнього регламенту, який допомагає відтворити походження файлу.
Не збирайте зайві дані. Якщо інцидент стосується одного студента й однієї активності, не потрібно автоматично передавати повний журнал усього курсу.
Зберігайте пакет централізовано. Файли не повинні залишатися лише на особистому ноутбуці викладача або в приватній пошті.

Важлива корекція популярної поради: саме редагування курсу не «перезаписує» заднім числом стандартний журнал Moodle. Проте окремі адміністративні дії можуть змінити або видалити первинні об’єкти, наприклад спроби тесту. Тому правило «спочатку експорт — потім зміни» потрібне для збереження контексту, а не через те, що будь-яке редагування автоматично стирає історію.

Межі того, що показує лог

Лог фіксує подію, а не її інтерпретацію.

Наприклад, однакова IP-адреса у двох студентів не доводить спільне виконання: вони можуть бути в гуртожитку, аудиторії або мережі з NAT. Незвично коротка тривалість тесту може бути сигналом для перевірки, але не встановлює причину. Вхід з іншої IP-адреси також не означає підміну особи.

Технічні дані варто читати разом із:

параметрами самого тесту або завдання;
відповідями і спробами;
історією оцінок;
повідомленнями про технічні збої;
поясненнями сторін;
іншими матеріалами, передбаченими процедурою закладу.

Це особливо важливо для академічної доброчесності: автоматичний висновок із одного цифрового сигналу перетворює інструмент журналювання на систему припущень.

Для профілактики інцидентів дивіться також матеріал «Як налаштувати тести в Moodle, щоб зменшити списування». Якщо питання стосується текстових робіт — «Перевірка на плагіат у Moodle».

Що налаштувати заздалегідь

До першого спірного випадку адміністратор і відповідальні підрозділи мають узгодити щонайменше такі речі.

1. Log store і строк зберігання

Перевірте, який log store активний, який строк задано для Standard log і чи покриває він повний цикл можливого розгляду.

Для великого навантаження Moodle підтримує External database log store. Це може бути корисно, коли журнали потрібно відокремити від основної бази, але така архітектура потребує власної політики резервного копіювання й доступу.

2. Grade history lifetime

Якщо процедура може спиратися на історію оцінювання, не залишайте цей параметр поза політикою зберігання. Логи й Grade history — різні набори даних і мають різні налаштування життєвого циклу.

3. Резервне копіювання

Не покладайтеся на звичайний backup окремого курсу як на спеціалізований архів журналів. Для Standard log store критичним є резервне копіювання бази даних відповідно до загальної політики відновлення Moodle. Якщо використовується external log store — його база теж має входити до плану резервного копіювання.

4. Права доступу

Moodle керує доступом до журналів через capabilities. За замовчуванням перегляд course logs доступний ролям, які мають відповідний дозвіл, зокрема викладачам і менеджерам. Але для матеріалів інциденту заклад може встановити вужчий внутрішній порядок: хто має право робити експорт, кому його передають і де він зберігається.

5. Регламент експорту

Корисно мати коротку внутрішню інструкцію:

інцидент → відповідальна особа → вузька вибірка → первинний експорт → фіксація дати й параметрів → контрольоване зберігання → передання уповноваженому органу.

Такий процес значно надійніший, ніж спроба відновити все заднім числом після завершення семестру.

Якщо потрібен аудит журналювання, строків зберігання або ролей доступу, це можна включити в аудит і впровадження Moodle.

FAQ

Чи можна відновити видалені логи?

У штатному інтерфейсі Moodle немає кнопки «відновити очищені записи Standard log». Якщо записи вже видалено відповідно до політики retention, можливість відновлення залежатиме від наявності придатної резервної копії бази або окремого log store. Тому перевіряти строк зберігання потрібно до інциденту.

Чи бачить викладач логи свого курсу?

За типовими правами Moodle курсова звітність Logs доступна користувачам із capability перегляду журналу; стандартні ролі teacher і manager мають такий доступ. У конкретному закладі ролі можуть бути змінені адміністратором, тому фактичні права треба перевіряти на власному сайті.

Скільки зберігати логи?

Moodle не встановлює універсального строку. Заклад має узгодити його з навчальним циклом, строками внутрішнього розгляду, політикою персональних даних, вимогами до резервного копіювання й допустимим розміром бази. Важливо, щоб журнал не очищався раніше, ніж завершиться період, у який ці дані можуть знадобитися.

Чи є IP-адреса доказом списування?

Ні. IP-адреса — лише технічна ознака мережевого запиту. Спільна адреса може бути наслідком NAT, корпоративної чи гуртожитської мережі. Її можна використовувати як один із сигналів для аналізу, але не як автоматичний висновок про порушення.

Чи достатньо одного Logs report?

Не завжди. Для тесту можуть бути потрібні Quiz Grades або Responses, для зміни оцінки — Grade history, для загального контексту — Activity/Complete report. Пакет потрібно формувати під конкретний інцидент і не збирати зайві персональні дані.