How to properly organize business logic in Yii2?

Question

Yii

Hello. There is a list of goods (for example, a service) that are stored in the database, which can be bought and used for certain purposes. Until recently, all products could be customized. At the moment, a distinction is being introduced - you can customize all products, except for the cheapest. This limitation applies to both appearance (when viewing a product, some interface elements that allow editing and saving are not available), and actions (the action to save model fields does not work with the cheapest product).
It is easy to assume that in the future this restriction may be removed, or new ones added (which may be imposed on a certain group of goods, or with additional related conditions.)
What is the best architectural (with the possibility of optimal complexity and quality of support) to implement such properties on products?
At the moment, everything is resolved by checking the current product by name (there are no more than 10 products, the names do not change and are unique) with the subsequent transfer of the value of the result of the check to the view.
For me, at the moment, this is the simplest solution, since there is no information about future changes in actions with goods, the code is clear, it will be possible to fix it quickly, the check is carried out in the corresponding entity model.
I am considering two possible solutions.
1) Enter an additional flag field in the product model and encode the editing option, in the future there is space to create additional features for the remaining bits of the field. Perhaps there is not enough flexibility to implement confusing conditions, but additional validation logic can be implemented, for example, in a model.
2) Implement using RBAC in the form of permissions. This solution was suggested to me, but I do not quite understand how to apply it optimally, and it seems to me that this solution will be too cumbersome, although perhaps more flexible. Does it seem like a solution to apply RBAC for such a task at all?
What do you think about the first and second methods?
Please advise a good solution from your practice for implementing such options on entities.
Thanks in advance.

Answer 1

On the one hand, it is really easy to implement similar functionality on RBAC using its rules. But you need to understand that RBAC (Role Based Access Control) is a system for delimiting ACCESS rights based on ROLES. Your task is not to relate to the DIFFERENTIATION of RIGHTS, but to the logic of displaying the product - therefore, in my opinion, such functionality has no place in RBAC, it is logically wrong.
The introduction of an additional bit field is the best idea, but again, in my opinion, placing it in the product model is not a completely correct solution (but, in principle, acceptable if the project is not large), because. the model should have business logic, and your functionality is the logic of displaying the product on the site. In my opinion, it would be more correct to separate such logic into a separate ProductDisplayRule entity - which will contain data on the rules for displaying goods on the site and be used in other parts of the system

Answer 2

Definitely RBAC.
And there are already many options. For example,
Permissions of the 1st level: "view", "create", "edit", "customize cheap" (in bizRule check the "cheapest" feature), "customize expensive", "delete".
2nd level rights: "unauthorized visitor", "authorized buyer", "manager", "admin".
The attribute "cheapest" should be stored in the database for the product. When changing any price, recalculate all these signs.
In the controller: call hasAccess with the product ID parameter.

Answer 3

Implement using RBAC in the form of permissions - flexible and convenient