Закрытый дневник в личном кабинете
Здравствуйте!
Возникла необходимость, для одного проекта реализовать возможность ведения записей в личном кабинете. Пока — в свободной форме в текстовом поле. В дальнейшем разбить на формы с выводом графика каких либо изменений. Видеть записи могут конкретный пользователь и администратор. Это закрытые данные, своеобразная связь пациента с лечащим врачом.
Что-то не приходит в голову не один компонент, имеющий какие то подобные простые функции. Буду благодарен за наводку. Если простого варианта не будет найдено, придётся рассматривать возможность написания такого компонента.
Возникла необходимость, для одного проекта реализовать возможность ведения записей в личном кабинете. Пока — в свободной форме в текстовом поле. В дальнейшем разбить на формы с выводом графика каких либо изменений. Видеть записи могут конкретный пользователь и администратор. Это закрытые данные, своеобразная связь пациента с лечащим врачом.
Что-то не приходит в голову не один компонент, имеющий какие то подобные простые функции. Буду благодарен за наводку. Если простого варианта не будет найдено, придётся рассматривать возможность написания такого компонента.
Комментарии: 3
Да можно использовать Ticket. Просто открывать просмотр выбранному пользователю. К примеру в список вывести врачей, написал и указал врача, и при открытии только он может видеть.у себя к примеру в личном кабинете в разделе Написали мне. типо того
Способ 1:
1. Создаешь страницу «Дневники» (/diary/), в которой будут храниться дневники всех пользователей. Лучше сделать страницу коллекцией, чтобы админка не захламлялась.
2. Создаешь плагин, который при регистрации пользователя нужной группы создает раздел с тикетами в странице из шага 1. Код плагина будет примерно таким.
3. Для шаблона разделов с дневниками и страниц с записями (тикеты) закрываешь просмотр всем, кроме администратора и автора:
4. Закрываем страницы от индексации, sitemap-a и прочее СЕО.
Плюсы: все дневники пользователей и записи разделены как в админке, так и во фронтэнде. Решение достаточно простое и, фактически, ограничивается возможностями дополнений из коробки.
Минусы: плодятся множество страниц. При большом объеме пользователей и их хорошей активности, объем БД и нагрузка на процессоры, связанные с работой ресурсов MODX-a (очистка кэша, генерация дерева и тд) будет выше, чем от самостоятельной таблицы.
Способ 2:
1. Создаешь раздел тикетов «Дневники» (/diary/). Все тикеты всех пользователей добавляются в данный раздел.
2. В шаблоне из пункта 1 совершаешь проверку пользователей по такому принципу:
3. Аналогично закрываем страницу тикета, sitemap, СЕО и тд и тп.
Плюсы: меньше разделов тикетов и глубина вложенности страниц, чем в пункте 1.
Минусы: не так удобно смотреть записи из админки.
Способ 3:
1-N. Написать свою таблицу с нужными полями, свою маршрутизацию запросов и вообще все с нуля.
Плюсы: самое быстрая итоговая скорость, минимально отягощающая работу самого MODX-a.
Минусы: реализация займет гораздо больше времени, а требования к навыкам намного выше.
1. Создаешь страницу «Дневники» (/diary/), в которой будут храниться дневники всех пользователей. Лучше сделать страницу коллекцией, чтобы админка не захламлялась.
2. Создаешь плагин, который при регистрации пользователя нужной группы создает раздел с тикетами в странице из шага 1. Код плагина будет примерно таким.
3. Для шаблона разделов с дневниками и страниц с записями (тикеты) закрываешь просмотр всем, кроме администратора и автора:
{if $_modx->isAuthenticated($_modx->context.key) == 0}
Для просмотра публикации необходимо авторизоваться
{else}
{if ($_modx->user.id | ismember : 'Administrator') || ($_modx->user.id == $_modx->resource.createdon)}
Контент
{else}
{$_modx->sendRedirect($_modx->makeUrl(1), ['responseCode' => 'HTTP/1.1 403 Forbidden'])}
{/if}
{/if}
4. Закрываем страницы от индексации, sitemap-a и прочее СЕО.
Плюсы: все дневники пользователей и записи разделены как в админке, так и во фронтэнде. Решение достаточно простое и, фактически, ограничивается возможностями дополнений из коробки.
Минусы: плодятся множество страниц. При большом объеме пользователей и их хорошей активности, объем БД и нагрузка на процессоры, связанные с работой ресурсов MODX-a (очистка кэша, генерация дерева и тд) будет выше, чем от самостоятельной таблицы.
Способ 2:
1. Создаешь раздел тикетов «Дневники» (/diary/). Все тикеты всех пользователей добавляются в данный раздел.
2. В шаблоне из пункта 1 совершаешь проверку пользователей по такому принципу:
{if $_modx->isAuthenticated($_modx->context.key) == 0}
Для просмотра публикации необходимо авторизоваться
{else}
{if ($_modx->user.id | ismember : 'Administrator')}
{var $where = ''}
{else}
{var $where = ' "createdby": ' ~ $_modx->user.id}
{/if}
Дальше передаем {$where} в сниппет, выводящий список тикетов, чтобы показывать лишь нужные данные.
{/if}
3. Аналогично закрываем страницу тикета, sitemap, СЕО и тд и тп.
Плюсы: меньше разделов тикетов и глубина вложенности страниц, чем в пункте 1.
Минусы: не так удобно смотреть записи из админки.
Способ 3:
1-N. Написать свою таблицу с нужными полями, свою маршрутизацию запросов и вообще все с нуля.
Плюсы: самое быстрая итоговая скорость, минимально отягощающая работу самого MODX-a.
Минусы: реализация займет гораздо больше времени, а требования к навыкам намного выше.
Спасибо за комментарии!
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.