Здравствуйте. Есть список товаров(например, услуга), которые хранятся в БД , которые можно купить и использовать в определенных целях. До недавнего времени все товары можно было кастомизировать. В текущий момент вводится разграничение-можно кастомизировать все товары, кроме самого дешевого. Это ограничение касается как внешнего вида(при просмотре товара недоступны некоторые елементы интерфейса, позволяющие редактировать и сохранять), так и действий(екшн по сохранению полей модели не срабатывает с самым дешовым товаром).
Легко предположить, что в будущем это ограничение может быть снято, или добавлены новые(которые могут накладываться на определенную группу товаров, или с дополнительными связанными условиями.)
Как лучше архитектурно (с возможностью оптимальных сложности и качества поддержки) реализовать подобные свойства на товарах?
В данный момент всё разруливается проверкой текущего товара по имени(товаров не больше 10, имена не меняются и являются уникальными) с последующей передачей значения результата проверки на view.
Для меня в данный момент это есть самое простое решение, поскольку нет никакой информации о будущих изменениях в действиях с товарами, код понятен, исправить можно будет быстро, проверка осуществляется в соответственной модели сущности.
Рассматриваю два возможных решения.
1)Ввести в модели товара дополнительное флаговое поле и закодировать опцию по редактированию, в дальнейшем остается пространство для создания дополнительных признаков по оставшимся битам поля. Возможно, не хватит гибкости для реализации замороченных условий, но дополнительную логику по проверке можно реализовать, например в модели.
2) Реализовать с помощью RBAC в виде пермишенов. Мне это решение подсказали, но я не совсем понимаю, как его оптимально применить, и мне кажется, что данное решение будет слишком громоздким, хотя, возможно, более гибким. Представляется ли решение применить RBAC для такой задаче в принципе?
Что скажете по поводу первого и второго методов?
Посоветуйте, пожалуйста, хорошее решение из своей практики, для реализации подобных опций на сущностях.
Заранее спасибо.
С одной стороны - действительно можно легко реализовать подобный функционал на RBAC с помощью его правил. Но нужно понимать что RBAC (Role Based Access Control) - это система разграничения прав ДОСТУПА на основе РОЛЕЙ. Ваша задача не относиться к РАЗГРАНИЧЕНИЮ ПРАВ, а относиться к логике отображения товара - поэтому, на мой взгляд, подобному функционалу не место в RBAC, это логически не правильно.
Введение дополнительного битового поля лучшая идея, но опять таки, на мой взгляд, его размещение в модели товаров это не совсем корректное решение (но в принципе, допустимое, если проект не большой), т.к. в модели должна быть бизнес-логика, а Ваш функционал - это логика отображения товара на сайте. На мой взгляд, будет более корректно выделение подобной логики в отдельную сущность ProductDisplayRule - которая, будет содержать данные по правилам отображения товара на сайте, и использоваться в остальных частях системы
Однозначно RBAC.
А уже вариантов есть много. Например,
Права 1го уровня: "смотреть", "создавать", "редактировать", "кастомизировать дешевый" (в bizRule проверять признак "самый дешевый"), "кастомизировать недешевый", "удалять".
Права 2го уровня: "неавторизованный посетитель", "авторизованный покупатель", "менеджер", "админ".
Признак "самый дешевый" хранить в БД у товара. При изменении любой цены пересчитывать все эти признаки.
В контроллере: вызвать hasAccess с параметром ID товара.
я просто не совсем разобрался, у меня rbac привязана к юзерам(юзер привязан к группе), а речь идет о товарах. Получается, нужно создать пермишн , например, able_to_customize, и всем юзерам, которые покупают товар, добавлять этот пермишн в auth_assignment? А при покупке более дорогого товара с auth_assignment нужно убирать запись связи конкретного юзера и пермишна?
Средний
