Закончился курс. Некоторое время он должен быть доступен со всем содержимым, но без возможности изменения преподавателем.
Есть ли готовое решение для moodle-3.1 ?
В гугле ссылки на треды 2008 года с moodle 1.8/1.9
Ну так измените права преподавателя. Например, дайте ему роль Преподаватель без права редактирования или вообще Гость. Если нужно временно "заморозить" не один курс, а целый сайт, то интересно было бы попробовать поменять права доступа к его файлам и базе данных на "только чтение".
Смена прав ролям в курсах - это метод, но IMHO крайне неудобный.
Права только на чтение БД ? Ох moodle не обрадуется, когда в логи не сможет записать...
Есть следующая идея:
Если в контекст добавить новый флаг RO, то можно было бы сделать следующее: в has_capability() если контекст с флагом RO, то использовать не текущую роль, а роль гостя. Для блокировки будет достаточно получить все контексты курса ( это же дерево ?) и на них поставить флаг RO.
Для [раз]блокировки устроит cli скрипт.
IMHO такой метод будет иметь минимальное изменение кода moodle.
Понятно, что не обрадуется. Но работать будет или нет? Интересно было бы проверить.
Но вы же тоже предлагаете роль менять, только не вручную, а автоматически - с использованием флага. Неплохо бы это изменение кода в виде плагина реализовать.
А еще можно быстро менять роли с помощью CSV файла. Мне приходилось давать роли преподавателям в нужных курсах одновременно с созданием их учетных записей. Так же и роль гостя можно дать, только, наверное, сначала с помощью другого CSV файла преподавателя нужно вообще из курса отчислить, чтобы он не получил две роли: преподавателя и гостя.
> А еще можно быстро менять роли с помощью CSV файла.
Смена роли ? Это сложное действие с возможными побочными эффектами.
Вся проблема в том, что accesslib.php не имеет никакой модульной структуры, так что править код придется - хотя бы добавить 1 строку для вызова проверки контекста на RO и код для отображения статуса курса RO.
Если делать интерфейс к этой фиче, то изменений кода станет значительно больше
А что плохого может случиться, если вы отчислите преподавателя из курса, а потом снова зачислите, но на роль гостя? Или выполните обратную операцию через какое-то время? В использовании CSV файлов ничего сложного нет. Для некоторых администраторов - это основной способ записи пользователей на курсы.
А вот изменение кода - это действительно сложное действие, с весьма возможными побочными эффектами, причем не разовое, а требующее повторения при каждом обновлении. Но если оно вам под силу, то Бог в помощь!
> А что плохого может случиться, если вы отчислите преподавателя из курса
С преподавателем - наверно ничего
т.е. вариант без правки кода может быть таким: всех преподавателей курса нужно понизить в какую-нибудь роль без права изменений, и использовать дату окончания курса для запрета учебной деятельности студентов (это требует проверки) ?С процедурой обновления все просто - гит наше все. Мелкие, тривиальные правки обычно не дают конфликтов.
И с курсом тоже ничего не случится . По-моему, это проверки не требует. А запрет записи было бы интересно проверить.
В has_capability() есть несколько интересных проверок в начале. Например на смену роли при просмотре курса.
Как оказалось, у каждого права есть несколько флагов, один из которых говорит, что это разрешение на запись, т.ч. запретить любые изменения оказывается очень просто.
Тогда будем ждать от вас инструмента для реализации этой полезной функции.
И еще, наверное, о студентах тоже надо подумать, чтобы и они не вносили в курс никаких изменений.
В идеале в параметрах курса, рядом с опциями скрыть/показать, хотелось бы увидеть еще и: заблокировать/разблокировать.
> И еще, наверное, о студентах тоже надо подумать, чтобы и они не вносили в курс никаких изменений.
RO ставится не только на сам курс, но и на все элементы в нем (на все дерево контекстов в курсе).