Cake-PHP.ru

[Menya]

Условия:
Внутрикорпоративный проект, основная задача: предоставить возможность одним учить других.

В системе четыре роли:
Student (учатся),
Autor (создают курсы),
Expert (модерируют контент),
Admin (следят за проектом: управляют правами доступа, пишут новости и т.д.).

Роли НЕ отличаются по полям данных, которые хранятся в базе данных, но сильно отличаются по функционалу. Причем более старшая модель наследует функциональность более младшей (например, авторы могут учиться и писать свои курсы, а эксперты – учиться, писать и модерировать и т.д.)

Задача:
Определить создаваемые таблицы базы данных, модели и контроллеры.

Варианты решения:
1. создать одну модель User с полем status, и один контроллер
2. создать одну модель User и по контроллеру для каждой роли, использующие эту модель
3. создать четыре модели (student, autor, expert и admin) (и соответственно, четыре контроллера), НО они будут использовать одну и ту же таблицу базы данных (users)
4. четыре модели (student, autor, expert и admin), каждая со своим контроллером и таблицей.
5. пять моделей: четыре модели из пункта в„–.4 + модель User (в которую войдут общие для всех ролей данные) + четыре связи hasOne

Пожалуйста, скажите какой вариант предпочтительнее, а главное почему?

[Hellbot]

---------- не по теме ! -------------
class User extends AppModel
belongsTo('Group')
actsAs('Aro')
class Group extends AppModel
hasMany('User');
actsAs('Aro')

Где права выдаются группам или пользователям (если надо персонально), на дерево действий, например
Сourses / join (Allow Group: Student, Author, Expert, Admin)
Courses / add (Allow: Author, Expert, Admin)
Users / list (Allow: Admin)
Users / edit (Allow: *)

При необходимости дополнить проверку на соответсвие id автора на id текущего пользователя.

Мне кажется это предпочтительнее потому что легко расширяется (проверка прав осуществеляется независимо от количеств групп или модулей системы), проверка может быть вынесена за пределы основной логики контроллеров (например будет поддерживаться компонентом Auth)
-------------

Прощу прощения
Что-то конец рабочего дня дает о себе знать, мне показалось это про разделение системы прав кому чего можно. Прочитав сообщение группе понял что вопрос не про это.

"У кого что болит, тот о том и говорит" (с)

[Hellbot]

Но вообще мне кажется что изначально постановка задачи не правильная.

это не ExpertController -> JoinCourses.
А все таки правильнее.
CoursesContoller->Join($user_id)

А необходимость связей я вижу пожалуй только при выводе информации о пользователе, где можно отталкиваться от его группы или его типа (если нет групп) или не отталкиваться вообще.
Если User не может Courses->add, то и его связь hasMany('Courses') вернет для него 0 записей.