Однако при работе с множеством однотипных учётных записей не хватает удобных средств управления ими. В частности, хотелось бы иметь возможность объединять учётные записи в единую групповую сущность и затем использовать эту сущность при назначении рассылок, поддерживая состав группы в одном месте, а не в каждой рассылке отдельно.
Чтобы было понятно, о чём речь. Сейчас есть два кейса.
В первом нужно ежемесячно рассылать отчёты по бюджетным организациям, при этом их состав в системе постоянно меняется: одни организации добавляются, другие — выходят из контракта из‑за переподчинения или изменения статуса.
Во втором кейсе ещё сложнее: есть две группы объектов с разными наборами отчётов, при этом объекты периодически мигрируют между этими группами. То есть одним объектам в рассылке нужны одни документы и одни сроки, другим — другой набор отчётов и иные сроки.
По названию напрашивается термин «группа учётных записей», но он у вас уже используется.
Во 2-ом еще запутаннее две группы объектов, в которых набор отчетов разный, но при этом происходит миграция объектов между списками. Т.е. объектам нужно в рассылке разные докуементы и немного разные сроки
По названию сущности просится группа учетных записей, но этот термин вы уже используете.
Предложение: добавить новую сущность, в которой можно объединять учётные записи и затем использовать эту сущность в расписаниях автоматических рассылок отчётов, параллельно с отдельными учётными записями. То есть в расписании можно было бы указать как новую сущность, так и конкретную учётную запись пользователя, который будет контролировать рассылку.
Я из этого описания так и не понял чем не подходят для этих целей существующие группы учётных записей. Добавлять новую группу к существующим мы точно не станем. Это уже точно излишнее усложнение, когда в системе присутствуют две практически одинаковые сущности. Лучше продумать можно ли использовать существующий функционал.
А как новая эрзац-группа учётных записей эту задачу сможет решить? И если пользователю нужны все объекты, логично дать ему доступ ко всем объектам. А если нужны не все объекты, то ничего не поделаешь - списком разрешённых придётся управлять. У нас довольно гибкие механизмы, которые назначают разрешения группам объектов и группам учётных записей.
Насколько я понимаю, сама задача ясна. Если её можно решить с помощью существующих групп учётных записей, давайте решим без создания новой сущности. Мне нужно решить задачу, и не обязательно вводить новую сущность. Но без её создания я вижу пару «но»:
Сейчас я использую группы учётных записей для назначения прав. Использовать их одновременно как признак объединения учётных записей не совсем привычно, это явно потребует большей аккуратности при настройке и почти наверняка приведёт к ошибкам с правами.
При использовании групп учётных записей для объединения учеток будет сложно контролировать права, и, простовы управления, скорее всего, придётся создавать несколько похожих групп с близкими наборами прав.
Например, если вернуться к примеру с бюджетными организациями, я вижу два признака, по которым отличаются ответственные за объект:
наличие права опроса;
наличие или отсутствие доступа к диагностике: база настроечных параметров, события прибора, температурный график.
Как вы видите решение этой задачи с учетом моего дополнения?
Мне нужно иметь группы учётных записей, которые можно привязать к автоматической рассылке и затем не трогать настройки самой рассылки при изменении состава учётных записей, получающих эти отчёты.
Поясню на конкретном кейсе. Есть более 200 бюджетных организаций. У каждой есть ответственный, которому нужно отправлять отчёт только по его объектам (обычно от 1 до 5 объектов), но есть и небольшие сетевые структуры от 3 до 15 объектов. Все объекты собраны в группу объектов, по этой группе настроена рассылка, в настройках выбрана опция «формировать отчёт отдельно для каждого пользователя из списка рассылки». Список объектов — «живой», он меняется от месяца к месяцу, и пользователи ответсвенные за рассылку отражают эти изменения, просто правя состав группы объектов в одном месте, что удобно и не приводит к ошибкам.
Состав пользователей, получающих рассылку, тоже получается «живым». Сейчас нужно настраивать для каждой рассылки свой список, в который нужно вносить изменения. Такой порядок точно соберет множество ошибок.
Желаемый результат.
Идеальным вариантом было бы привязать конкретную учётную запись как ответственного за объект, а дальше управлять только группой объектов, по которой идёт рассылка.
При этом остаётся востребованной схема, когда к рассылке можно привязать как отдельную учётную запись, так и группу учётных записей. Для сетевых структур отчёты должны уходить 2–3 пользователям, наверное для контроля или подстраховки
Не вижу пока зачем нужна отдельная сущность. Если разрешить добавлять группы в список рассылки, можно сделать первую группу “Ответственные”, вторую группу с этим самым “живым” списком и выбираете обе группы в качестве списка рассылки. Кроме того, при этих изменениях в качестве адресата можно будет выбрать как группу, так и конечного пользователя, эти сущности у нас в системе объединены, так что сделать это не проблема.
Для этих двух групп можете назначать права доступа, можете не назначать, для групп это не обязательно.
Отчёты всё равно будут формироваться для конечных пользователей, которые входят в группу, так что, думаю, проблем тут не будет.
