Создание нескольких пользовательских ролей в приложении Rails с единым входом в систему (Rails Devise, Pundit, STI? ПОМОЩЬ)

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

Администратор будет иметь полный контроль над добавлением/редактированием новых сотрудников и клиентов (что, в свою очередь, создаст для них учетные записи пользователей). Сотрудники смогут просматривать данные своей учетной записи, а клиенты — то же самое.

Как я могу настроить это с помощью Rails devise и pundit? Я скрывался во всем Google и stackoverflow, и наиболее распространенное решение, похоже, вращается вокруг наличия одной модели пользователя и использования STI/pundit для установки ролей для пользователей и ограничения доступа к определенным представлениям. Может ли кто-нибудь помочь сломать это для меня, прежде чем я сойду с ума?


ruby-on-rails pundit
person djskim27    schedule 16.01.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Как правило, если роль является эксклюзивной (это означает, что Сотрудник не может быть Администратором или Клиентом, Клиент не может быть Администратором/Сотрудником и т. д.), вы должны поместить столбец role:integer в свою модель Users, которая является перечислением Rails:

enum role: %i[customer employee admin]

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

Если в вашем варианте использования требуется, чтобы роль имела разные данные, вы можете выполнить наследование одной таблицы с таблицей пользователей, хотя я настоятельно рекомендую избегать STI.

Если вашим пользователям требуется более одной роли И вам нужны разные данные/поведение для каждой роли, вы можете рассмотреть полиморфную ассоциацию. Я написал ответ об этом ранее здесь.

person brainbag    schedule 16.01.2018
comment
Спасибо за быстрый ответ! В моем случае разные роли должны иметь разные данные (например, клиентам нужны платежная информация и адрес). Я уже внедрил STI в свое приложение. Есть ли какая-то конкретная причина, по которой вы настоятельно рекомендуете мне не использовать его? - person djskim27; 17.01.2018
comment
Каждый раз мой опыт с ИППП был очень неприятным. При модели 1:1: таблица структура данных имеет тенденцию быть самой простой из возможных реляционных структур. С STI модели и таблицы быстро раздуваются, и в итоге вы получаете много пустых данных и сложную логику модели, даже если вы делаете правильный ООП. Наконец, кажется, что всегда наступает время, когда две связанные модели STI требуют немного разного поведения для одного и того же столбца, что еще больше усложняет их и снижает предсказуемость. Иногда это лучший выбор, который у нас есть, поэтому, если вам нужно, позаботьтесь о том, чтобы ваше поведение было как можно более раздельным. - person brainbag; 18.01.2018