Оповещение о технических проблемах

[mikanoz]

В наших проектах, иногда возникают разные проблемы, о которых необходимо срочно извещать разных сотрудников, которые работают в компании. На сайте fintech-fab.ru хочется иметь удобный интерфейс для рассылки подобных сообщений (email + sms). Сейчас уже есть регистрация и авторизация, а также "раздача" прав через административный интерфейс.

Кейсы задачи: а) Сотрудник регистрируется на сайте б) Администратор сайта назначает ему роль "Получатель уведомлений" или "Отправитель уведомлений", или обе вместе в) Для роли "Отправитель уведомлений" доступен интерфейс отправки уведомлений г) Отправитель заходит, выбирает тему для уведомлений, выбирает получателей (из списка тех, кому назначена роль "Получатель"), и нажимает "отправить" д) Всем выбранным получателям уходят соответствующие сообщения.

1. Тщательно разобраться, как работает регистрация и управление ролями. Есть Роли и Пользователи. У каждого Пользователя может быть несколько Ролей.

• В системе, когда решается, можно ли Пользователю выполнить какое то действие, проверяется его Роль.
• В данный момент реализованы три роли (чтобы заполнить таблицу ролей, запустите команду php artisan db:seed).
• Чтобы зарегистрироваться, перейдите по ссылке /registration и заполните форму.
• Чтобы зарегистрироваться через социальную сеть (необязательно), зарегистрируйте приложение в соц. сети (фейсбуке или вконтакте) и настройте конфигурационный файл app/config/local/social.php (в директории app/config/examples есть примеры конфигурационных файлов).
• После регистрации, в базе данных через таблицу user_role назначьте своему пользователю роль 'admin'.
• В итоге вам будет доступна ссылка /admin.
  1. Добавить в систему новые роли (через миграции)
  2. Создать новый раздел для Отправителей, где я, например, как отправитель, могу:

а) выбрать тему из списка (или написав текст в текстовое поле, тем самым завести новую тему) б) если хочу, написать комментарий в) выбрать получателей г) нажать кнопку "отправить" д) получателям уйдет подробный email (тема, отправитель, другие получатели) и sms-сообщение (только тема).

[k17-sergey]

Регистрация и управление ролями работает со сбоями. Проблематично разбираться, когда что-то не работает. Думаю, это должна быть отдельная задача— исправления, что там не так.

«1. Добавить в систему новые роли (через миграции)» Роль «отправитель сообщений». Она обязательно должна быть. А вот, например, роль получателя сообщений… А что собственно этот пользователь делает в системе? — совершенно ничего. Он получает сообщения, не входя в систему (по почте или sms). Его роль лишь в том, что в его данных есть адреса для рассылки.

А, например, роль «подписчик на сообщения», когда он имеет право выбирать, какие сообщения он хочет получать, это уже вполне нормальная роль. Но тогда возникает дополнительная задача по части группировки пользователей по группам и подписка их на определенные темы сообщений. Здесь нужно использовать базу данных.

[mikanoz]

Регистрация и управление ролями работает со сбоями.

Необходимо в первую очередь разобраться с ошибками. Все должно работать. Если не работает, значит что-то у тебя локально в проекте недонастроено.

А что собственно этот пользователь делает в системе? — совершенно ничего.

Верно, он ничего в системе не делает. Пользователь с ролью "получатель" выводится в списке, когда отправитель хочет отправить сообщения.

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

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

[k17-sergey]

Как-то странно без группировок пользователей. Если 5 получателей сообщений — это нормально, а если 50… если одному оно надо, а другому нет… Значит, отправлять всем без разбора; или же отправлять участникам той группы, которой это сообщение и предназначено (т.е. использовать разделение на группы).

Роль «получатель» здесь совершенно не нужна. Данные о пользователе, получатель ли он сообщений или нет должна быть в другом месте. Это однозначно.

[k17-sergey]

Роли. Пользователям назначаются разные роли. При входе на какую-нибудь страницу или при попытке выполнить какие-то действия, система сначала проверяет, имеет ли право пользователь с этой ролью на доступ к этой странице либо что ему на этой странице должно быть показано или не показано, и т.п. Понятно, что для этих целей есть таблица БД ролей. И было бы странно, например, если бы в таблице ролей, подразумевающей права доступа на сайте, были бы перечислены роли, которые пользователь играет в самодеятельном театре. То есть для этих ролей следовало бы где-нибудь создать категорию хобби, а не экономить на количестве объектов.

Роль получателя сообщений. Допустим, пользователю позволили решать, хочет он получать письма и sms или нет. Да вот беда, кто-то из административных соображений взял, да и закрыл доступ к таблице ролей для простых пользователей. И это правильное решение. Только вот он «почему-то» не подумал, что в этой таблице записаны не только роли, имеющие административное значение, но и «просто роли» на все случаи жизни. То есть там записано получает пользователь сообщения или не получает. А в итоге простейшая задача по изменению состояния получает пользователь сообщения или нет, становится неимоверно сложной задачей. Коллапс получается, надо одновременно и запретить доступ к таблице, и разрешить…

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

[k17-sergey]

1. Роли добавлены через миграцию
   А еще добавлена таблица БД, содержащая названия тем для писем (+ комментарии), и имена шаблонов писем.
   + добавлены отношения таблиц пользователей и ролей (через миграцию).

[k17-sergey]

1.Сделан постраничный вывод для страницы администратора. К таблице ролей пользователей добавлены скрытые кнопки с номерами страниц. В зависимости от того, какой номер страницы загружен, и сколько всего страниц, кнопки выборочно будут отображаться. Много переделок в получении запрашиваемой таблицы. Появился лишний файл (он теперь уже не нужен). Класс с таким именем уже есть (Role).

2.Сделан маршрут, контроллер и прочие заготовки для страницы отправки сообщений.

[k17-sergey]

Подготовительное сделано: можно назначать роли посылающим и получающим сообщения; маршрут страницы есть. А вот не могу понять, как сама страница отправки сообщений должна выглядеть в целом?

Пункт «в» выбрать получателя… Это, конечно, можно сделать по-разному. А в чём смысл? Какова цель? — отправить список получателей на сервер и там их обрабатывать, получая из них адреса. Или делать как-то иначе, например, сразу список адресов передавать… Я попробовал, да вот проблема: по-моему, в Laravel нет средств для баз данных, чтобы работать со списком. Или я чего-то не понял. Работать будет, только если подставить готовую строку SQL запроса… Да и если, например, использовать форму ввода на странице… Как организовать список? Ну, извращаться-то можно как угодно, а как правильно представить данные для ввода на странице?

А вот если бы получатели были организованы в группы, тогда было бы понятно. Выбирается группа получателей, и она одна. И только одно значение посылается для обработки. А по ним, уже из БД, получается список адресов.

Темы сообщений. Насколько я понял, каждая тема — это отдельный файл шаблона для почты. И куда-то их нужно будет постоянно записывать, добавляя новые темы. И только один комментарий предполагается добавлять при отправке сообщения. А редактировать темы? — например, исправить ошибки (или опечатки).

В принципе, для выбора получателей можно, например, поставить поле ввода «checkbox». И всё будет работать, только не нравится мне эта затея, почему-то.

[k17-sergey]

В принципе сделано и работает. Только вот непонятно, ведь в условии задачи подразумевается какая-то реализация, почему нельзя о ней что-нибудь сказать? Где, какие данные нужно использовать?

Например, пункт «в) выбрать получателей». Нет таких данных «получатель». Есть имя получателя, есть его почтовый адрес, есть идентификатор и пр. (но самого получателя мы обрабатывать не можем). Может, имелось в виду, выбирая получателя, добавить его e-mail и прочие данные в адресную строку и еще куда-то…

У меня хотя и работающий, но бестолковый алгоритм получился. Такой алгоритм уместен, только если выбирается группа получателей (а не кто-то конкретно из них) или вообще не выбирается группа, а они сами подписываются на ту тему, сообщения которой хотят получать. Все данные есть в БД, там всё и обрабатывается.

А здесь, с выбором конкретных получателей я не знаю, что имеется в виду. И почему это секрет, я не понимаю. И сколько нужно выбрать получателей? — 5 или 25, а может 625… Непонятно.

Поскольку используемые данные не определены (могут быть разные варианты), то детально я ничего не делал. Как случайно что-то встало, так и стоит. Пользователи выбраны, письма отправлены — всё.

Нужно определить структуру данных, тогда можно будет двигаться дальше. А пока на этом всё (задача выполнена).

[k17-sergey]

Переделана страница администратора. Загружается без Аякса, использована навигация страниц Laravel. Результат промежуточный, потому что старый маршрут не удален (и страница тоже, можно войти и в старую, и в новую).

[mikanoz]

Слито в мастер