Александр
http://joxi.ru/DmBxpVJuNebPZA?d=1
Александр
или редирект к роуту можно сделать, но ты не это видимо имел ввиду
invariance
Это может означать только одно
invariance
что я ошибся
Александр
подскажите как лучше оформить доступы.
Есть контроллер с несколькими методами.
Часть из них должны быть только для админа
Часть только для модера
Часть только по API через POST запрос
Как лучше разделить права? Роутами? В каждом методе делать проверку на роль?
Подскажите как правильней такое оформляется
Anonymous
Александр
в контроллере будет правильней?
Anonymous
$this->middleware('admin', ['only' => ['method1', method2']);
Anonymous
И так для всех
Александр
чем загромождать роуты
Anonymous
Ну в контроллере удобно на разные методы ставить миддлваре
Александр
окей, спасибо
Anonymous
окей, спасибо
Вообще проверку на роли лучше делать "Как минимум имеет роль"
Anonymous
Чтобы не было таких проблем как утебя
Александр
а чем это помогло бы мне?
Александр
мне важно чтобы у юзера был либо админ либо модер и никакая другая
Anonymous
Так у тебя модер не наследуется от админа?
Anonymous
Админ не может делать то, что может модер?
Anonymous
Привет у меня возник вопрос такой. Нужно при создании специального юзера должно создаваться конкретно под него набор таблиц , каким образом реализовать чтобы сохранить MVC и каждый юзер должен иметь только к своим табличкам доступ
Александр
у меня админ наследует модера
Александр
админ это расширенный модер
Anonymous
Евгений
Александр
ты имеешь ввиду чтобы роль была >=1 ?
Anonymous
ты имеешь ввиду чтобы роль была >=1 ?
Не совсем. Я не знаю как у тебя роли сделаны. Но желательно иметь какую-то иерархию и проверять имеет ли юзер одну конкретную роль или одну из более крутых
Александр
вообще роли в базе изначально сделаны были не мной как 0, 1, 2
Александр
:)
Anonymous
В твоем случае можешь просто сделать if ($user->isAdmin() || $user->isModerator()) return true
Евгений
Anonymous
Так а зачем таблицы?
Anonymous
отдельные
Евгений
хз, не знаю решения для тебя. Но я бы не стал такое городить
Евгений
таблица концертов и таблица юзеров, юзеры могут быть продюссерами. у концерта есть продюсер_айди
Anonymous
Ну так и привязывай к user_id
Anonymous
Какие плюсы решения создание общих таблиц под всех под всех продюсеров связывая все по user_id?
Anonymous
Не сильно в этом разбираюсь
Евгений
мда
Anonymous
ну ты попробуй оба решения и вопрос отпадет
Евгений
зачем тебе много таблиц если можно одной?
Евгений
ты потом задолбаешься если решишь чтото поменять
Евгений
и ваще бред имхо
Konstantin
У тебя вообще какие сущности будут?
Lyubava
http://cs8.pikabu.ru/post_img/2016/08/28/8/1472390096111766424.jpg
Konstantin
Концертный зал, места, концерт, исполнитель, продюсер?
Konstantin
Ну тебе вообщем нужно тупо сделать связь стоимости места с местом и продюсером
Anonymous
Konstantin
seat_id event_id producer_id price
Anonymous
Anonymous
Хз зачем телефон перевернул
Anonymous
Konstantin
vertabelo.com
Anonymous
https://dev.mysql.com/downloads/workbench/
Anonymous
этой пользовался
Konstantin
Тикеты можешь пока отбросить
Konstantin
Это по сути будет place_id + event_id
Anonymous
Konstantin
У тебя будет просто таблица orders где будет id из таблицы связи
Евгений
а если 2 сеанса в день, то place_id + event_id уже не подойдет наверно
Anonymous
Евгений
тогда добавится еще сеанс айди
Евгений
но не тикет наверно
Евгений
тикет - лишняя сущность
Anonymous
тикет в конце для юзера конечного нужен
Anonymous
чтобы билет генерировать
Евгений
тике - это просто абор конкретной даты места и тд.
Евгений
оттуда и билет генерится
Anonymous
окей в приципе я понял, спасибо за помощь
Anonymous
а у тикетов ID нету?
Anonymous
уникального
Anonymous
Чтобы по БД их чекать
Anonymous
Anonymous
Я имею ввиду что-то вроде JWJW8282839JJ
Anonymous