Предлагаю добавить возможность указать адрес e-mail для автоматической рассылки отчета без создания для этого отдельной учетной записи.
Почему нужно: нам необходимо каждый месяц отправлять ведомости параметров своим клиентам, но при этом самим ЛЭРС УЧЕТ они не пользуются, им просто нужен pdf на почту раз в месяц.
Сейчас для этого нужно создавать учетные записи, чтобы была возможность указать e-mail клиента. Это неудобно и усложняет дальнейшее администрирование системы, да и вообще костыль на мой взгляд.
Добрый день!Вообще, специально для этого мы делали параметр учётной записи “Вход запрещён”. Идея была в том, что все рассылки управляются однообразно, и всегда можно просмотреть полную информацию о пользователе, которому отправлялось сообщение. Например, полное имя пользователя отображается в журнале.
А флаг “Вход запрещён” не позволит входить пользователю в систему пока это ему не разрешит администратор.
Пожалуйста, опишите подробнее, чем такой подход усложняет администрирование системы. Возможно, найдём какой-нибудь более простой и элегантный выход.
С точки зрения разработчиков концепция однообразного управления рассылкой и возможность посмотреть кому было отправлено сообщение и соответственно посмотреть полную информацию о пользователе безусловно выглядит логично и даже вроде как удобно для конечных пользователей. В том числе возможность спустя время узнать кто скрывается за неочевидным адресом эл. почты вроде coolhacker007@example.com Но я приведу свой пример уже со стороны администрирования и использования системы:
- У меня в системе около половины учетных записей фиктивные, с установленным флагом “вход запрещён”. При этом установленный флаг не видно в таблице учетных записей. Понять реальная это учетка или фиктивная можно только открыв её свойства. Ну либо указывать эту информацию в описании и затем фильтровать ненужные записи. Т.е. на мой взгляд очевидно что перегружается лишней информацией интерфейс управления учетными записями.
- Когда нужно создать новую рассылку по новым e-mail нужно сначала зайти в учетные записи и создать их там с установленным флагом “вход запрещен”. Многим (особенно недавно начавшим использовать систему) пользователям будет неочевиден такой подход.
- Пока это все писал понял что в свойствах учетной записи можно запретить вход, а можно заблокировать учетную запись. Я понимаю что разница тут в том, что если “вход запрещен” - это когда не нужно указывать пароль. Но все равно это перегружает и усложняет интерфейс.
Думаю тут во всей этой концепции проблема в названии галочки “Вход воспрещен” - оно не отражает своего предназначения. Насколько я понимаю - эта галочка должна разделять тех, кто так или иначе подключается к серверу, и тех, кому учетная запись в системе необходима для других целей (Поля в отчетах, уведомления по СМС, авторассылка и т.д.).
Если коротко: я не хочу во время администрирования учетных записей видеть в списке старших по дому, которые заведены в систему только ради авторассылки и другие подобные учетные записи.
Возможно стоит упростить фильтрацию и отображение учетных записей и пересмотреть названия галочек в свойствах учетной записи “Вход запрещен” и “Заблокировать учетную запись”
Вижу это как еще один столбец с галочками либо другими значками которые будут и наглядными, и по ним можно будет легко отфильтровать.
Вот буквально вчера другой пользователь был введен в заблуждение сложным интерфейсом и справедливо считал что раз у пользователя нет доступа к определенным объектам - то и отчеты по этим объектам ему не придут: https://forum.lers.ru/viewtopic.php?t=11699
Раз мы ищем элегантное решение, и не будем отказываться от использования только учетных записей в качестве получателей рассылки - предлагаю после установки галочки “вход запрещен” скрывать все вкладки свойств учетной записи вроде прав доступа, доступных отчетов, мнемосхем, таймаут неактивности и прочее т.к. нет никакого смысла их настраивать.
Думаю это добавит интуитивности: поставил галочку - остались только настройки для рассылки и уведомлений.
Спасибо за такое подробное пояснение! Нам эта информация очень сильно помогает, так как позволяет понять что думает конечный пользователь нашей системы. Мы, как разработчики, естественно смотрим на неё несколько под другим углом.
- Думаю, стоит сделать фильтрацию по колонке “Вход запрещён”. Это простое действие, но действительно сделает работу с системой гораздо удобнее.
- Ну “Вход запрещён”, строго говоря, обязательным не является. Можно ведь создать и обычную учётную запись, но не сообщать логин и пароль.
- Между заблокированной учёткой и учёткой, которой запрещён вход, различие не только в том, что не нужно задавать пароль. Заблокированной учётке сообщения не отправляются вообще. Поэтому, такую учётную запись для рассылки использовать нельзя. Это не самое очевидное решение, но лучшего пока придумать не удалось.
Интересная идея насчёт блокировки неиспользуемых закладок в свойствах учётной записи, которой запрещён вход. С одной стороны, где-то это может быть проще. С другой стороны, почему бы не дать администратору возможность настроить доступ, а потом, при необходимости, просто убрать флажок.Хочу подчеркнуть, что я не настаиваю на том, что мы не будем делать рассылку по произвольным email-адресам. Я просто хочу понять что будет удобнее для вас и для других пользователей. В итоге, есть три варианта
- Добавить колонку “Вход запрещён” на список учётных записей, чтобы проще их фильтровать.
- Скрыть неиспользуемые закладки в случае если учётке запрещён вход.
- Сделать рассылку без привязки к учётной записи
Первый пункт, думаю, сделать нужно обязательно, мы поставим эти работы в план.Насчёт второго я не совсем уверен, что это хорошая идея. Возможно, действительно, не стоит пытаться “подстроить” существующий инструмент под какие-то нужны и сделать новый инструмент для рассылки отчётов по произвольным адресам. Мы обсудим эти варианты и отпишемся здесь о принятом решении.
Предлагаю другим участникам форума присоединится к обсуждению.
- Согласен с тем, что фильтрация по признаку “вход воспрещен” нужна в любом случае.
- Вы говорите о том, что администратор сначала может настроить различные параметры учетки “на будущее”, чтобы потом при необходимости просто снять флажок и предоставить доступ к серверу, но ведь вы уже блокируете поле ввода пароля учетной записи при установке этого флага.
3.В текущем виде понять как работают галочки “Вход воспрещен” и “Заблокировать учетную запись” при первом знакомстве с программой достаточно проблематично без изучения руководства. Что если хотя бы выводить короткую всплывающую подсказку при наведении на данные пункты? Либо при установке флага “Заблокировать учетную запись” каким либо образом пояснять пользователю что в том числе не будет выполняться рассылка уведомлений и отчетов.
Да, прошу поучаствовать в обсуждении других пользователей. Очень интересно узнать мнение.
В 3.46 мы добавили колонку с признаком “Вход запрещён”.
Мне тоже нравится идея сделать свободную рассылку без привязки к учетным записям, так как у меня 90 % таких учёток, которые только для рассылки.
Добрый день!
В принципе, идея понятная и неплохая. Мы можем поставить её в план, но с одним уточнением. На произвольные email не будут распространяться ограничения по времени отправки сообщений, которые сейчас могут задаваться для учётной записи. Если потребуется такая возможность, мы предложим создать учётку с признаком “Вход запрещён”.
Если такой вариант устраивает, мы поставим реализацию в план на 3.47.
Меня такой вариант устраивает. Ведь в автоматической рассылке я итак указываю время, когда будет отправлен отчет.
Меня тоже вполне устраивает такой вариант. Ведь я именно это и описывал в первом сообщении темы 
Спасибо за обсуждение, мы приняли предложение в работу. Сделаем в версии 3.46.
Не совсем понятно, о чем именно договорились.
В автоматической рассылке просто добавляется список рассылки? На какие объекты распространяется конкретная рассылка, если это отчет о НС и иные аналогичные отчеты.
Будет ли какой-то элемент “список адресов”, которые мы будем пополнять при необходимости, будет ли поле комментарии, чтобы указать что-за получатель скрывается за адресом.
Или в каждой рассылке будет свой список адресов, и нужно будет следить за их полнотой и актуальностью.
Можно ли иметь более одного списка, например, раз речь о старших по дому, то стоит иметь свой список для районов, или УК?
Как этот список адресов сопровождать?
Антон, раскройте, пожалуйста, что именно появится в 3.47?
В задании на автоформирование будет возможность указать простой список email адресов. Справочника адресов не будет. Про объекты не совсем понял. Их список задаётся в самом задании. Отчет по НС по этому списку не отправится так как он формируется по учётным записям. Дополнительные поля не планируются, только адреса.
Если все эти функции нужны, вы можете продолжать рассылать отчеты учетным записям и не использовать этот список.
Т.е. это список адресов, чтобы отправить отчетную карточку. И только.
Если потребуется заменить адрес в этом списке, а это обязательно потребуется. Для этого нужно будетобязательно знать адрес, который меняем. А это в момент замены уже может быть не известно. Если у Вас в списке только адреса электронной почты, задача переходит в проблему 
Я бы предложил добавить поле описание, и с обязательным заполнением.
А вот сейчас я не понял. Если речь о старших, то им нужен 1 отчет по 1 дому. Но домов, как и старших много.
Из Вашего ответа следует, что придется создавать отдельную рассылку под каждый дом? Так?
Да, это так.
Пока не планируется . Можно использовать расширенный формат email Имя <admin@example.com>
Да, как и в случае с учётными записями. Другие способы в этой теме не обсуждались.
Не понимаю для чего нужно реализовывать справочник и поле комментарий, ведь это все как раз реализуется через учётные записи. В том числе группы учетных записей. Я создавал это предложение чтобы был реализован функционал “указал в поле e-mail и не заморачиваешься”. Зачем дублировать функционал? Считаю справочники и поле комментарий не нужны.
Поддерживаю, именно так мы поняли и реализовали это предложение. Как я уже писал, рассылка для учётных записей осталась на месте и никуда не делась, её можно использовать если нужны расширенные функции.
Уточняю. В моей практике старшие по дому сами смотрят все, у них нет рассылки. Но возможно потребуется, поэтому пытаюсь примерить это изменение к существующим проектам. И получается плохо.
Я полагал, что сейчас можно создать учетки под каждое МКД (каждого старшего по дому). Каждая учетка старшей по дому видит только свой МКД. И далее создается 1 задание на рассылку ведомости всем МКД. Задание разошлет каждой учетке ведомости, только по домам, которые доступны конкретной старшей по дому.
1 вопрос. Это не так разве работает?
В мои проектах этих МКД и старших где сотни, а где тысячи. Учетки и права им создаются по API.
Используя текущее изменение, придется создавать по API задание на рассылку.
2 вопрос. Я правильно понял?
При этом, получив все ответы, мне все равно не понятно почему это изменение упростит жизнь.
Предлоожение. Если упрощать, то в объекте есть 2 физ.лица и 1 организация. При этом «ответственное лицо» – это просто поле, без образования учетки. Можно добавить ему поле электронной почты и реквизиты телеграма (телефон или имя). В этом случае достаточно иметь возможность сделать рассылку по ответственным лицам.
Если «ответственное лицо» - несет уже какую-то нагрузку, можно сделать еще 1 физ.лица, например, «ответственный за эксплуатацию»
Такая схема проще в управлении и, на мой взгляд, логичнее