updateOwnNews добавь в дочерние админу

Он дочерний к менеджеру, а менеджер к админу.

https://gist.github.com/vanilevsky/afe2c0e8113e3f6365af012c55de3107 значит тут добавь условие или

https://gist.github.com/vanilevsky/afe2c0e8113e3f6365af012c55de3107 значит тут добавь условие или

Это ли не костыль?

updateOwnNews добавь в дочерние админу

Получается, при наследовании к админу тоже условие на авторство проверяется

не костыль

не костыль

Смысл правила в проверке на авторство, а мы туда ещё условие на админа положим. Похоже на костыль 🤔

Проверка на право редактировать

Коллеги, привет! Подскажите пожалуйста кое что по рбаку. Как расширить разрешение updateOwnNews, чтобы срабатывало и при роли admin? RbacController: https://gist.github.com/vanilevsky/270dd72a3a642b4c96bdc92e418a9d96 AuthorRule: https://gist.github.com/vanilevsky/afe2c0e8113e3f6365af012c55de3107 То есть чтобы при проверке Yii::$app->user->can('updateOwnNews', ['article' => $model]) было true когда юзер admin.

Все дочки должны наследоваться от админа

Не надо ничего лишнего в коде писать, просто правильно иерархию разрешений/ролей построить

Не надо ничего лишнего в коде писать, просто правильно иерархию разрешений/ролей построить

Вот именно, но тогда при наследовании от админа сохраняется условие проверки на авторство

Если админ есть, то у него в потомках на любом из уровней есть право редактировать новость

Если нет, то он не админ и права такого у него нет

Тач тупит, ссори

Админ есть, но он наследует редактирование с проверкой

Он должен наследовать разрешение

Т.е. у роли админ есть потомок автор у которого есть в разрешениях редактировать новость

https://gist.github.com/vanilevsky/afe2c0e8113e3f6365af012c55de3107 значит тут добавь условие или

это другое

тут костыль)

это не решает его проблему

Т.е. у роли админ есть потомок автор у которого есть в разрешениях редактировать новость

Так и есть, но у автора редактирование только с авторством

это оригинальный код?

Но у админа должно быть без проверки авторства

запилите два пермишна, полный и ограниченный

либо везде писать Yii::$app->user->can('updateOwnNews', ['article' => $model]) || Yii::$app->user->can('admin') либо в самом разрешении на редактирование прописать либо автор либо админ

и проверяйте

пермишн canUpdateNews

а в updateOwnNews все верно написано

либо на уровне выше

сути не меняет

updateOwnNews ограниченный доступ

должен быть доступ выше, который и надо проверять

пермишн canUpdateNews

Тоже так придумал, но значит updateOwnNews конечное правило, и его не расширить без проверки?

Тоже так придумал, но значит updateOwnNews конечное правило, и его не расширить без проверки?

это обычныый checkAccess, к примеру нет доступа - проверяем есть ли ограниченный доступ и авторство

в любом случае есть canUpdateNews - пропустить, нет - проверять есть ли updateOwnNews. Просто по логике

хз, создавать на каждый чих для админа отдельные правила, если это все будет большой проект и управление правами будет через админку, будет список запросов в базу на проверку прав на каждое разрешение. Если он админ то у него права на все и создавать отдельные правила для него canUpdateNews canUpdateComment canUpdatePost canUpdateMessage нет ни какого смысла

хз, создавать на каждый чих для админа отдельные правила, если это все будет большой проект и управление правами будет через админку, будет список запросов в базу на проверку прав на каждое разрешение. Если он админ то у него права на все и создавать отдельные правила для него canUpdateNews canUpdateComment canUpdatePost canUpdateMessage нет ни какого смысла

Должно быть право редактировать, его и должен наследовать админ

А у редактировать уже должно быть право редактировать только свое

Дело не в пчихе, если есть ограниченный доступ он должен наследоваться от того кто может больше

В будущем могут быть модераторы не админы, которые могут редактировать все новости и т.д.

Когда у тебя система ролей, да, так будет лучше. Когда у тебя 1-2 роли, смысла в этом нет. Создаешь роль манагер и даешь ему права на редактирование всего, и его добавляешь к правам админа. Разрешение это лишнее усложнение для нескольких ролей

Когда у тебя система ролей, да, так будет лучше. Когда у тебя 1-2 роли, смысла в этом нет. Создаешь роль манагер и даешь ему права на редактирование всего, и его добавляешь к правам админа. Разрешение это лишнее усложнение для нескольких ролей

Сути это не меняет, тут исключительная роль которую надо отдельно проверять

само собой

Дело не в пчихе, если есть ограниченный доступ он должен наследоваться от того кто может больше

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

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

там перед точкой не хватает "и страдай..."

да никто страдать не будет. Наследование это тоже проблемы

из разряда - "сам долбоеб"

в любом случае это иерархия, даже если у тебя обособенный набор разрешений не связных между собой

нет, эта иерархия тока у тебя в голове, и возможно для некоторых удобств.

твои проблемы, живи с этим)

к примеру. тебе срочно нада сделать кастомную роль со своими наборами правил. Ок. взял накликал разрешения. А потом начинаешься мучица придумывая кто от кого наследуется

хотя для предопределенных нескольких ролей наследование вполне себе отлично смотрится. Типа: читатель, автор, модер, админ. Если за рамки этого набора не выходить.

смспилот топчик https://smspilot.ru/?r=9999

Пасиба

@HunterKaan @rus72ru спасибо! Дали пищи для размышлений)

Объясните мне, безграмотному, пожалуйста. Вот я беру и в конструктор контроллера вставляю некий blogService. Благодаря di он автоматически подтянется и создаст обьект с этим классом. Это понятно. Собственно, вопрос. А если уже внутри этого blogService также имеется конструктор в который подтягивается некий blogRepository и он описан в секции use класса blogService, то он также автоматически его создаст, благодаря di? То есть отдельно настраивать в bootstrap его не нужно? Если я правильно понимаю, то настройка di требуется лишь в случае, когда неоднозначно понятно какой класс фреймворку подтягивать? ( Ну например дня случая, когда в качестве типа указан интерфейс). Поправьте меня, пожалуйста, если заблуждаюсь.

Это называется autowiring

Настройка нужна если сервис должен быть, например, синглтоном. Или инстанс сервиса требует доп конфигурации.

+

Настройка нужна если сервис должен быть, например, синглтоном. Или инстанс сервиса требует доп конфигурации.

А какая, например, может потребоваться конфигурация? Приведите пример. Передача дополнительных переменных/значений/ классов? Вы это имеете в виду?

А какая, например, может потребоваться конфигурация? Приведите пример. Передача дополнительных переменных/значений/ классов? Вы это имеете в виду?

Например может потребоваться какойнить вызов вроде setCache()

И еще небольшой вопрос по di. Я хочу разобраться правильно ли тут будет его применение. Допустим, я хочу настроить и использовать несколько сервисов рассылки смс сообщений. Причем, какой-то сервис я беру за основной, а остальные как резервные. Где-то в недрах идет вызов этого главного сервиса смс путем запроса из БД какой из них использовать. (Подразумевается, что все мои сервисы имеют общий интерфейс). И уже, получая из БД имя класса я создаю этот объект через createObject, например. Вот такое решение, что я описал это и есть один из распространенных случаев использования di? Правда, в данном конкретном случае может использование di не совсем оправдано? Достаточно просто создать класс с его именем, полученным из БД? Значит, возможно этот запрос можно сделать из bootstrap каким-то образом? Тот же синглтон, наверно нужен будет. Ведь сервис один на протяжении всего цикла приложения. В общем, запутался немного.

di тут не очень применим

мы просто в очередь сообщений писали, через какой шлюз сообщение должно быть отправлено https://github.com/yii-dream-team/yii2-sms-center/tree/master/src

вот пример типичного использования DI

Кто то делал api в таком формате? https://github.com/DmitryKorobko/BigBiz/tree/c0c7a6f2b2cfcf25c72f3764db23fe557a116c0a/rest/modules/api/v1 1. Все сгруппировано по модулям (suport, shop, product,content) 2. Для каждого action создается отдельный класc со своими параметрами, поведением и логикой

Кто то делал api в таком формате? https://github.com/DmitryKorobko/BigBiz/tree/c0c7a6f2b2cfcf25c72f3764db23fe557a116c0a/rest/modules/api/v1 1. Все сгруппировано по модулям (suport, shop, product,content) 2. Для каждого action создается отдельный класc со своими параметрами, поведением и логикой

ActiveController в рест?

ActiveController в рест?

вопрос о структуре

Как пример реализации

Так, модуль пилишь, контроллер и действия для контроллеров если хочется отдельными классами. В этом есть смысл если использовать одинаковые действия в разных контроллерах

Кто то делал api в таком формате? https://github.com/DmitryKorobko/BigBiz/tree/c0c7a6f2b2cfcf25c72f3764db23fe557a116c0a/rest/modules/api/v1 1. Все сгруппировано по модулям (suport, shop, product,content) 2. Для каждого action создается отдельный класc со своими параметрами, поведением и логикой

Це ужас 🤔

Кто то делал api в таком формате? https://github.com/DmitryKorobko/BigBiz/tree/c0c7a6f2b2cfcf25c72f3764db23fe557a116c0a/rest/modules/api/v1 1. Все сгруппировано по модулям (suport, shop, product,content) 2. Для каждого action создается отдельный класc со своими параметрами, поведением и логикой

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

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

Для этого есть fields и extra

ребята, как отсортировать массив после array_merge? пытаюсь использоваться что то типа usort($model, function($arr1, $arr2) { if ($arr1['news_date'] == $arr2['cdate_int']) return 0; return $arr1['news_date'] > $arr2['cdate_int'] ? 1 : -1; }); и постоянно получаю ошибку Getting unknown property: ***\***\news\***\News::news_date тут суть в том, что блин он свойство одного массива пытается найти в другом и крашится, как правильно делать?

Чет, код какая то херня

+

вообще не понятно что это и зачем

ребята, как отсортировать массив после array_merge? пытаюсь использоваться что то типа usort($model, function($arr1, $arr2) { if ($arr1['news_date'] == $arr2['cdate_int']) return 0; return $arr1['news_date'] > $arr2['cdate_int'] ? 1 : -1; }); и постоянно получаю ошибку Getting unknown property: ***\***\news\***\News::news_date тут суть в том, что блин он свойство одного массива пытается найти в другом и крашится, как правильно делать?

либо проверяй на наличие свойства, либо на тип перед сравнением. от этого и сравнивай атрибуты

у тебя что $arr1, что $arr2 могут быть экземплярами различных классов

у тебя что $arr1, что $arr2 могут быть экземплярами различных классов

да

это был не вопрос :D естественно он будет ругаться, когда свойство(атрибут) не находит