TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Как отпарсить вьюшки ...
  • Собственно это и есть вопрос?! Хотя может я и не прав в самой задумке, а задумка такая: есть модуль раздачи прав - он более менее стандартный одним можно загружать вьюшки, другим нет. Но на самом деле этого мало! Необходимо не только разрешать\запрещать загружать вьюшки, но еще и динамически менять вьюшки в зависимости от прав т.е. для определенных прав инфа в виде input`ов, для других прав - text. Само по себе это не проблема, проблема раздать права соответствующим группам в модуле прав. Мне это видится так: заходим в модуль прав и запускается сканирование всех вьюшех модулей (части вьюшек по маске?), из вьюшек извлекаются данные по формам и таблицам и на выходе получаем матрицу соотношений: form - formelement; - formelement1; - formelement3; etc. table - tableelement, - formelement1; - formelement2; etc. Дальше каждому элементу даем - права RWX. Profit. Как потом проверять права и формировать вьюшку - следующий вопрос ... пока что, вопрос как вот такую штуку организовать? Вопросы производительности пока что опустим ;) Спасибо за ответы.

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

  • Как решить массово такую задачу? Есть вьюха\форма - на этой форме n input`ов, и 4 кнопки (не утверждено, утверждено, отклонено, оплачено) и есть бизнес-процесс: Подотчетное лицо создает документ и заполняет инпуты - доступа к кнопкам не имеет. Т.е. документ по-умолчанию - не утвержден. Руководитель просматривает документ, может внести некоторые изменения в инпуты и утвердить\отклонить документ. Бухгалтер просматривает документ, не имея доступа к инпутам, он может только жмакнуть кнопку - оплачено! И вот такая канитель присутствовать будет на нескольких десятках форм, для нескольких десятков вариантов: подотчетник\руководитель\бухгалтер!!! Т.е. не всякий бухгалтер может оплатить, не каждый руководитель утвердить и не каждый подотчетник создать\просмотреть\отредактировать документ ... Как это компактно описать - ума не приложу, а уж руками писать в код - ваще вешалка!

  • создать роли подотчетник\руководитель\бухгалтер , во вьхе соответственно проверять роль и в зависимости от нее выводить\блокировать элементы управления + в контроллерах, обрабатывающих действия делать проверку на роль пользователя запрашивающего действие. после того как будет пару контроллеров готово можно попробовать "сгруппировать" их и написать базовый контроллер для подобных разделов.

  • Слишком много ролей, но дело даже не в этом - нужна матрица доступа к десяткам форм, для десятков юзеров или ролей - но руками это описывать не хочется, очень не хочется ...

  • У меня конечно не так сложно, но есть похожее приложение. Отталкиваюсь именно от действий (action), на каждое действие есть роль, роли присваиваются в админке, и потом очень удобно проверять перед выполнением действия есть ли такая роль у пользователя, т.е. есть ли у него права. Роли иерархические, чтобы не получилось маразмов, что у пользователя есть права на создание, но нет прав на просмотр например. Т.е. без наличия какой-то роли невозможно наличие другой. С шаблонами сложно все, да. Никак не могу придумать как же мне определить выводить или нет ту или иную кнопку, кроме как тупо проверять роль.

  • @Botv0091 роли это группы пользователей, если их у тебя десятки, то ты неверно спроектировал систему. Я честно говоря не понимаю для каких таких целей вся эта головная боль, не портал же федерального уровня ты пишешь. по сути на каждую модель 4 основный правила - т.е. CRUD +1 про запас. например для экспорта данных. В большинстве случаев вообще достаточно права на просмотр\изменение данных. Соответственно управляющие кнопки группируются по блокам и достаточно проверить права на доступ к блоку. но если ты на проектировал не по принципу от общего к частному, то и придется тебе заняться секисом с этим решением. @fungi это уже не совсем верно т.к. ты используешь RBAC как ACL

  • @WinterSilence Ты конечно будешь смеяться, но да - проект около федерального уровня, точнее может им стать =) поэтому и такая сложная система прав. Сегодня определились со структурой прав: модуль->контролер->action->Dom element но описать это все руками трындец!

  • @WinterSilence, ну да, наверное неправильно, но работает как-то. Просто опыта мало. А есть что-нибудь почитать на эту тему, только не с обилием терминологии, а с примерами из жизни так сказать?

  • @Botv0091 мышь пытается родить слона, в том смысле, что в одиночку такие вещи не пишутся

    @fungi не особо, мои знания почерпнуты из вики

  • @WinterSilence я не один и мы сегодня угробили весь день на то что бы обсудить как должна выглядеть система доступа ... мне нужен раздельный доступ к каждому элементу, лид орал что ему плевать на всех заказчиков и нужно делать CRUD на модуль и быстрее быстрее, другой программер кричал что он умрет но не позволит написать ни строчки повторяющегося кода, БДешник вопит что мы заддосим базы проверками прав ... Т.о. нужно как-то динамически собирать и информацию о данных и информацию об уровнях доступа к этим данным ...

  • Как нормально коммент написать? а то тут хтмл весь рендерится

  • Значит отписался тут, а то не разобрался с форумом. https://gist.github.com/misterx/d5e4afe125740c8d1087/raw/c44cf102e88e6f404a9545b536425f68a195919b/Comment

  • @misterx Спасибо за метод!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion