Добрый день, Павел. Отвечаю на Ваши вопросы. Извините за задержку - был в отпуске, потом разгребал дела
Проблема № 1 Отображение функционала
a) Подобный функционал в Мудл мы можем реализовать только в виде блока. Но, показывать каждой роли свой блок нет возможности, потому что настроить отображение блока можно только для глобальных ролей а для локальных нет.
Вы имеете в виду программирование блока на PHP? Можно просто реализовать право доступа "видеть блок" и включить его в нужные роли через интерфейс настройки ролей.
b) Блок это все-таки блок, а нам надо интерфейс на всю странницу.
Положите внутрь блока php-файлы, реализующие интерфейс, а в блоке просто поместите ссылку. Как сделано в Электронном Деканате.
Проблема № 2 Роли...
a) Каждый юзер может иметь одновременно роль, как препода ,так и студента, в связи с этим сложно понять кто он на самом деле.
Заведите запрещенное для редактирования пользователем поле в профайле или используйте поле "Отдел" для указания общей роли. Либо используйте главную страницу или какой-нибудь курс для назначения глобальной роли (отключив из неё все лишние права). Либо создайте свою таблицу пользователей во внешней SQL-базе, можно заодно настроить Moodle для авторизации по этой таблице.
Либо воспользуйтесь "Электронным деканатом".
Возможные способы решения проблем:
1) прежде чем записать студента на курс, проверять записан ли он где-нибудь уже, и с какой ролью записан, если да и роль отличается, то выводить ошибку типа "пользователь Иванов не может быть преподавателем данного курса ибо он уже записан с ролью студент в курс такой-то".
Решение плохое, потому что нам надо будет изменять код ядра.
2) делать запрос к базе - определять в скольких курсах он студент, а в скольких курсах он препод ,и что за курсы (мета или дочерние), исходя из этого принимать решение, какой интерфейс ему показывать.
Решение плохое, потому что нам надо будет изменять код ядра.
Зачем всё это? В чем основная задача, о каких интерфейсах идёт речь? Есть подозрение, что сложности вызваны тем, что вы пытаетесь перенести на Moodle модель работы другого ПО, вместо того, чтобы понять, какие способы достижения этих же целей заложены в Moodle (разный интерфейс - не цель, а средство, возможно излишнее).
3) сделать блок с правами "авторизованный пользователь" - чтобы был виден всем, а уже в самом блоке прибегать к шаманствам описанным выше и определять "доминирующую" роль пользователя и исходя из этого выводить необходимый роли функционал.
Решение плохое, потому что нам надо будет изменять код ядра.
Это не так. Добавление блоков не требует изменения кода ядра.
4) описанном выше блоке доступном для всех пользователей сделать страничку на которой с помощью описанных выше шаманств определения доминирующей роли юзера, показывать необходимый нам функционал, а в curse/view.php?id=1 прописать редирект на страничку нашего блока.
Решение плохое, потому что нам надо будет изменять код ядра.
Можно сделать и без правки ядра, или с минимальной правкой. В конце-концов, можно на главной через блок вывести ссылку на функциона.