Интерфейс блока ролей

Oleg Sychev repo owner

changed component to Supervised

2015-09-12T19:31:03+00:00

Oleg Sychev repo owner

changed title to Интерфейс блока ролей
edited description

2015-09-12T19:31:42+00:00

Татьяна Потапова reporter

Появилось несколько вопросов. Пока только сделала общий шаблон интерфейса (см. рис.). Вопрос 1. Какие виды тестов, лекций и уроков существуют? Если есть тесты тренировочные, preg, correct_writing, экзаменационные; задания бывают индивидуальные и групповые, то какие бывают типы уроков? Вопрос 2. Может, в разрабатываемом интерфейсе стоит отображать весь список заданий, уроков и тестов для курса и у каждого элемента списка выбирать, в каких режимах этот элемент доступен? Снимок.PNG

2015-09-19T13:44:01+00:00

Oleg Sychev repo owner

Все немного сложнее, Таня. То, что вы перечислили как виды тестов - это на самом деле названия экземпляров, которые вы видели у нас. Давайте не путать виды модулей и конкретные их экземпляры. Мало ли какие у кого тесты бывают - что, для каждого делать? Задания бывают разные, но эту проблему мы переложим на задание - пусть нам сообщает когда началось и закончилось, остальное не наши проблемы...

Во-первых, я хочу видеть таблицу правил. К любому правилу у нас идет название от юзера, вид события (попытка теста, выполнение задания), роль которую пользователь получит на время действия этого правила, роли из которых возможно переключение (не должен же он админа переключать например), плюс должны быть иконки или менюшка для действий (удалить/редактировать/выключить правило) и индивидуальные параметры (в таблице не показываются, либо в сокращенном виде показываются.

Посмотрите для примера в управлении курсом способы записей пользователя на курс - там тоже по сути таблица правил и возможность их добавлять...

В таблице все это видно, меняется при редактировании или создании - и вот здесь индивидуальные параметры можно настроить - а это могут быть выбор конкретных экземпляров тестов или заданий (из списка заданных в данном курсе - надо из БД получать, какие препод создал такие и выводим) - или списка видов уроков (если они заданы для данного курса - есть в таблицах блока supervised). Так что рисуем отдельно таблицу правил, отдельно формочки редактирования каждого вида правила (тест, урок, задание). Ну и API правила как класса хотелось бы посмотреть...

2015-09-20T01:16:27+00:00

Татьяна Потапова reporter

Олег Александрович, не совсем поняла, в 1 правиле юзер может настроить все 3 вида правил (тест, урок, задание), или для каждого вида правил пользователю надо отдельное правило заводить? Событие можно указать только одно или несколько для одного правила? Нужно ли более детально рассматривать событие - от какого именно теста или задания оно сработало, чтобы переключилась роль по этому правилу?

2015-09-20T07:29:30+00:00

Oleg Sychev repo owner

В одном правиле юзер настраивает один вариант - или тест или урок или задание. Причем в итоге может оказаться несколько правил на разные тесты (уроки, задания) с разными ролями например. Вот одно и то же задание (тест, урок) в двух правилах может присутствовать только если у них не пересекаются наборы исходных ролей, иначе непонятно какую результирующую роль назначать...

Не понял что вы называете событием. Если тест - то событие это начало попытки теста (конец) и оно будет одно, но самих экземпляров тестов может быть много (например в 1-м курсе "Основ программирования" 6 контрольных тестов). Пользователь выделяет вам галочками из списка какие именно тесты переключают. А что значит детально рассматривать опять же не понял - вроде выше понятно. Есть вид правила, он же вид события. И есть конкретные экземпляры (реальные тесты, задания, виды уроков) которые галочками отмечаются - срабатывает на попытку именно этого теста (задания, урок именно этого типа) правило или нет.

2015-09-20T10:51:33+00:00

Татьяна Потапова reporter

ссылка на шаблон интерфейса moqups

2015-09-26T17:22:20+00:00

Oleg Sychev repo owner

Выглядит нормально в целом, надписи надо бы уточнить и добавить (например показать что роль в которую переключить на время события). Еще я бы иконки в таблице размещал рядом с названием правила (можно в той же колонке, либо меню делать как в assignment или редактировании курса), а не максимально далеко от него - можно и промахнуться при большой таблице... Жду а) рисунков вида самого блока для редактора, простого учителя и студента б) предложений каким образом должны работать правила по IP и срокам времени - там не все всегда просто... в) структуру таблиц БД в которых будут хранится правила и активные (сработавшие) экземпляры правил. г) предложений как именно переключать роли пользователя

2015-09-26T17:51:04+00:00

Татьяна Потапова reporter

Пункты а), в) - link. По поводу б) - есть предложение ориетнироваться на события user_loggedin и user_loggedout. Доставать ip адрес и перевести в роль по правилу, пока не произойдет разлогирование. А в случае с временем - при создании правила создавать cron, который бы переводил всех юзеров в соответствующую роль, а по окончанию - обратно. г) переключать роли пользователя - имеется в виду, когда у нас время действия одной роли не закончилось, а сработало правило по переходу в другую роль, тогда какой последовательности переводить пользователя по окончанию действия правил? Тогда объясню свои мысли на примере. Например, роль "студент" сменилась на роль "студент на уроке", а во время урока на "студент делает задание". Если подходит конец урока, то нужно смотреть, у этого пользователя по прежнему роль "студент на уроке". Если да, то можно перевести его в роль "студент". Если нет, то нужно в соответствии с его текущей ролью ("студент делает задание") завершить действие правила, по которому произошел этот переход, после чего завершить время действия правила урока. Узнать, как именно менялись роли пользователя мы сможем по логам, которые записывают сработавшие правила.

2015-10-03T09:20:21+00:00

Oleg Sychev repo owner

По пункту а) не согласен. Там где информации мало, линки не нужны. Например собственную роль студенту однозначно можно показать без всяких там линков (или даже стек его ролей). Учитель по идее находится вне автоизменения ролей, но управлять этим должны capabilities. Могут одному человеку и ту и другую назначить. Но табличку из названий правил и количества срабатываний разве нельзя разместить в самом блоке, обязательно нужна ссылка? Вот у редактора да - должна быть ссылка на таблицу правил внизу, насчет events log не уверен стоит ли его делать - работы и так много, это явно не приоритет.

в) Таблицы - что-то пока страшноватое. Во-первых, по ссылке http://docs.moodle.org/dev/Coding найдите правила работы с БД - там и про наименование таблиц и столбцов, и многое другое. Во-вторых, почему роли хранятся как строки, а не id из таблицы ролей Moodle? Вас же должны были учить нормальным формам и связям таблиц БД... С уроками надо подумать - есть же вариант при определенных типах уроков, а есть при любом уроке (типы могут быть просто не заданы в курсе, в этом случае все уроки считаются однотипными) - что делать если типов уроков нет? Ну то, что не task а poasassignment это должно быть ясно. Там кстати могут быть проблемы по соблюдению терминологии и ограничениям длины наименования таблицы например. IP адрес правило - у вас сети были/есть? Он хранится одной строкой, делить на начало/конец не надо (там по всякому может быть в строке). Как хранится дата и время в Moodle посмотреть несложно - посмотрите хотя бы в том же quiz в таблице как хранятся те поля, что я вам показывал. LogEvent - ну то, что user должен по id хранится я думаю вы уже поняли, насчет timeend не уверен - возможно имеет смысл хранить в этой таблице только активно работающие случаи, после окончания удалять - иначе она очень быстро станет просто огромной...; зачем там ip адрес тоже не понял.

б) Насчет IP там надо подумать над одной нехорошей ситуацией. Дело в том, что ничто в Moodle на текущий момент не запрещает одному юзеру (логину) залогинится с двух разных IP в один промежуток времени. Некоторые неумные первокурсники так пытаются списать экзамен - их товарищ садится дома, заходит под их же логином и подсказывает/присылает решения через личные файлы - что я успешно обнаруживаю по логам. Поэтому надо как-то продумать поведение при повторном user_loggedin без user_loggedout со старого IP с учетом того, что ситуация эта как минимум подозрительная. Причем первым может быть как указанный в правиле IP, так и другой...

г) я пока скорее имел ввиду как вы Moodle заставите пользователю сменить роль, вы разобрались как это сделать? Просто переписать в таблице БД или что еще? В каком контексте будет назначаться эта роль? Самое простое в контексте курса, но тут могут быть проблемы - например если я хочу запретить во время экзамена использование встроенных личных сообщений, студенты ведь могут войти в другой курс и посылать их оттуда. Возможно надо давать настройку уровня контекста (от системы до конкретного курса) при правиле. Там надо учитывать также есть ли у пользователя другая роль в ЭТОМ контексте или нет...

2015-10-03T20:49:50+00:00

Татьяна Потапова reporter

Олег Александрович, у меня проблемы с всплывающим окном для выбора вида правила. Насколько я поняла, базового шаблона нет. В аналогичных случаях, например, при нажатии на "Add an activity or resourse" в курсе за данное окно отвечает course_section_add_cm_control в course/renderer.php. И там также все очень запутанно, как и в случае с question. Нет ли более подходящего примера?

2015-11-22T17:39:35+00:00

Oleg Sychev repo owner

Я конечно обновлял Moodle не вчера, но у меня это называется course_modchooser в course/renderer.php и ничего такого уж сверхсложного там нет. Естественно оно использует course/yui/src/modchooser

Альтернативно можно посмотреть poasquestion/preg по тому как там организована подгрузка всплывающего окна с обычной Moodle Form через AJAX. Прежде всего смотреть textandbutton как родительский класс в poasquestion и его дочерний класс уже в preg, потому что там именно эта кнопочка на форме вызывает загрузку окна.

2015-11-22T20:02:16+00:00

Татьяна Потапова reporter

Олег Александрович, подскажите, пожалуйста. Я пытаюсь сделать одну форму на все правила, но возникают проблемы при попытке ее сохранить - неизвестно, какого она вида, поскольку ее отрисовка происходит как и при первом открытии, так и при сохранении. Если при первом открытии мы знаем ее тип (через параметр адресной строки), то при сохранении этого параметра уже нет. Каким образом можно передать этот параметр при сохранении или как это правильно это сделать?

2015-11-29T13:52:39+00:00

Oleg Sychev repo owner

Если посмотрите справку по Form API увидите, что среди элементов формы есть hidden. Туда можно записать любую необходимую информацию, в т.ч. и тип правила.

2015-11-29T13:59:47+00:00

Татьяна Потапова reporter

Репозиторий

2015-12-27T16:27:20+00:00

Oleg Sychev repo owner

Я получаю сообщения о форках от моих репозиториев :) Что с тестовыми инструкциями?

2015-12-27T23:51:00+00:00

Татьяна Потапова reporter

2015-12-28T16:46:29+00:00

Татьяна Потапова reporter

Тестовые инструкции добавила в шапку к данному issue.

2015-12-28T16:47:42+00:00

Oleg Sychev repo owner

Времени уже мало. Если хотите ускорить тестирование для получения хорошей оценки, подойдите завтра (в среду) к 16 часам на 9-й этаж с ноутом и установленной программой. У вас там много тестировать...

2015-12-29T17:13:04+00:00

Oleg Sychev repo owner

Обратите внимание - вместо вставки стандартного комментария Moodle

This file is part of Moodle - http://moodle.org/

Посмотрите как это сделано в Supervised

This file is part of Student Access Control Kit - https://code.google.com/p/oasychev-moodle-plugins/

Только ссылку на bitbucket уже конечно давайте...

2015-12-29T20:36:50+00:00

Oleg Sychev repo owner

И имейте совесть - сделайте русский вариант строкового файла - в каталоге ru.

2015-12-29T20:40:13+00:00

Oleg Sychev repo owner

Прочитайте https://docs.moodle.org/dev/Blocks#Authorized_Personnel_Only и сделайте так, чтобы ваш блок можно было создать только на основной странице курса, а не где попало.

2015-12-29T20:44:41+00:00

Oleg Sychev repo owner

Прочитайте https://docs.moodle.org/dev/Automatic_class_loading и сделайте классы правил автозагружаемыми, это устранит ваш locallib.php кстати.

Классы форм делать автозагружаемыми не надо, но стоит начать их имена с block_autorole_ чтобы исключить конфликты имен с другими классами Moodle.

2015-12-29T20:54:27+00:00

Татьяна Потапова reporter

Изменения, которые необходимо сделать:

This file is part of Moodle... - изменить на This file is part of Student Access Control Kit + ссылка на bitbucket.
Избавиться от кавычек вида " везде, кроме запросов в БД.
Вызов всех типов правил происходит в current_rules - исправить, чтобы вызов всех типов правил и их названий происходил через базовый класс.
for (..) изменить на foreach где возможно
в version.php прописать зависимости и избавиться от копипаста, взятого из других блоков.
Добавить русский язык lang/ru
Сделать добавление блока доступным только на странице курса
Автозагрузка классов с правилами (переименовать файлы с классами и папку, изменить вызов).
Переименовать классы с формами, чтобы они начинались с block_autorole_
Правила настраиваются для конкретного курса - пробросить в запрос courseid
Оптимизировать запросы в БД, использовать getInOrEqual
Рефакторинг классов правил. Вынести общее в класс-прослойку.

2015-12-30T14:23:27+00:00

Татьяна Потапова reporter

Замечания были исправлены.

2016-01-06T17:11:02+00:00

Oleg Sychev repo owner

https://bitbucket.org/potapova_tatiana/moodle-plugins-supervised-block-autorole/src/4b5367ca456752acba6c250ca1a336a7fe84e066/blocks/autorole/forms/delete.php?at=default&fileviewer=file-view-default#delete.php-53 - двойные кавычки в url
Это делалось каким коммитом? Напишите, не вижу...
IP list есть скорее всего в mod/quiz (в dependeciences это mod_quiz) - он стандартный, и зависимость от него намного лучше чем от supervised
А в social то зачем запретили?
Обратите внимание что операция склейки строк - точка - такая же операция как остальные и должны отделяться пробелами слева и справа, у вас в формах я вижу что не отделяется.
Самое серьезное - у вас в форме напрочь игнорируется возможность валидации. Посмотрите на большинство форм Moodle - они содержат функцию validate которая проверяет корректность данных. Вам для формы правила тоже такую нужно завести и перенаправить в классы правил, которые будут валидизировать свою информацию если надо. Валидация не должна позволять создавать странные данные, которые приведут к глюкам. Например что случится с правилом по времени если время конца поставить раньше времени начала? Вот такие вещи (которые формально ввести в форму можно, а по логике это бред) валидация должна отсекать с выводом сообщений об ошибке (посмотрите пример в любой Moodle-форме имеющей функцию validate - ей достаточно вернуть массив ошибок определенным образом). Посмотрите также другие правила на предмет того, нет ли там чего проверять (например есть типы уроков но пытаются создать правило в котором не выбран не один тип; или не выбран ни один тест, а правило сохраняют - и т.д.)