В журнале работ по объекту учета можно будет фиксировать все работы, которые проводились на объекте: ремонт оборудования, настройка, профилактический осмотр, перевод на летний/зимний режимы, замена приборов и т.д.
Пожалуйста, определитесь с данной темой. Сначала вы создаете дубликат своей же темы, потом не узнаете ее в планах работ, а сейчас появляется ни с чем не связанный вопрос про поверку.
В одной теме мы обсуждаем только один вопрос. В этой теме мы обсуждаем статус узла учёта, его связь с вводом/выводом из эксплуатации и срывом пломбы из вашего первого сообщения.
Я бы просил разработчиков вернуться к появлению статуса точки учета.
Причем 2 параметров.
статус - для обозначения состояния узлов учета
допуск - определения наличия допуска в коммерческий учет.
Список статусов актуальный для меня следующий:
нет записи;
затоплен;
разграблен;
сорвана пломба;
заполнен (только для объектов, при наличии разных статусов в точках учета объекта).
Список значений допусков актуальный для меня следующий:
дата до который допущен узел учета;
нет допуска (в случае объектов если хотя бы одна точка учета не допущена;
допуск (только для объектов, при допуска у всех точек учета).
Эта информация сейчас часто пишется в параметре “комментарии”. А на этот параметр (комментарии) и так много информации которую приходится там размещать.
Статус и допуск должен назначаться также, как назначается летний/зимний режим работы узла. Быть доступным для групповых операций для назначения и снятия.
Список статусов должен быть доступен в справочниках для редактирования. Хотя, так как уже много справочников, то может имеет смысл группировать справочники по смыслу с использованием закладок (но это offtopic).
Отображаться оба параметра (статус и допуск) должны на списке точек учета и объектов. В том числе в строке точки учета на закладке объекты учета при раскрытии объекта.
Пока поддержка статусов объектов запланирована на версию R26. Вопрос по допускам для нас так же актуален, и мы ведём проработку возможных вариантов решения. Скорее всего, после обсуждения мы поставим реализацию в планы на версию R25.
К написанному выше, хочу добавить, что статусы и допуски следует, на мой взгляд, задавать не заходя в формы редактирования точки учета или объекта. Пользователи, управляющие статусами, не должны иметь права на редактирование точек учета и объектов
хм…
Это все применимо к системам, где либо много объектов, либо много пользователей. Редактировать объекты, точки должны 1, максимум 2 пользователя. Т.к. во-первых описание элементов в ЛЭРС Учете далеко не совсем простое, и чем сложнее система, тем больше нюансов. Если все имеют право вносить изменения, то постоянно происходят изменения, которые не добавляют устойчивости системы. Не понимаю, почему я это описываю. :-): Вроде очевидная вещь :ze_va_et:
А во вторых, слишком много кликов для для того, чтобы просто поменять статус. Операция должна быть простая и не должна требовать много времени.
Это форум и обсуждение должно быть понятно всем пользователям. Лично мне не до конца понятно, почему это должно быть реализовано именно так, а не иначе.
Сама операция смены статуса со списка, без открытия свойств объекта, это оптимизация и вопросов не вызывает. Вопрос только в обоснованности добавления отдельного разрешения.
Получается, что право на редактирование объекта должно включать право на изменение статуса, верно?
В текущей модели безопасности права доступа независимы, соответственно, при добавлении нового права на изменение статуса, возможна ситуация, когда при установке разрешений у пользоватея будет право на редактирование объекта, но при этом будет прямой запрет на изменение статуса. Система должна или отработать этот момент (запрет имеет приоритет над разрешением, потребуется модернизировать весь редактирования параметров объекта) или предотвратить его на этапе настройки разрешений (требуется изменить модель безопасности).
Тут Вам решать как сделать с наименьшими затратами. Меня устроит и:
полностью независимые эти два разрешения;
введение приоритетов; только если их не было, то вопрос вроде не глобальный чтобы делать такие нововведения;
связанность прав на уровне интерфейса настройки, т.е. разрешение редактировать статус, визуально однозначно будет показывать, что добавятся права на редактирование объекта и точки учета; например как при установке компонентов для windows server.
А вообще-то, подозреваю, играя с правами можно и сейчас сделать не одну забавную конструкцию, и это не является вроде проблемой.
Разрешения-то разные, но если они полностью независимые возникает коллизия при открытии окна свойств объекта учета для редактирования.
Статус - это свойство объекта учёта, соответственно, помимо возможности его изменения со списка, должна быть и возможность его редактирования вместе с другими свойствами. Отбирать у пользователя, которому можно редактировать объект право на изменение статуса - нелогично. Но для независимых разрешений возможна ситуация когда редактирование объекта разрешено, а смена статуса запрещена. В этом случае встает проблема с установкой начального статуса при создании объекта (использовать для этого двух пользователей опять же нелогично). Исходя из этого я и написал, что разрешение на редактирование объекта должно в том числе и включать разрешение на редактирование статуса.
Вариант с приоритетами не подходит, т.к. это меняет всю модель безопасности. Запрет всегда должен иметь приоритет над разрешением.
Задача системы - не дать пользователю прострелить себе ногу. Поэтому пожалуйста, сообщайте обо всех подобных конструкциях в разделе ошибок.
Белых мест нет, но нужно принять решение по отдельному разрешению. Это займет больше времени, чем обычно. Только после этого можно получить перечень задач, оценить затраты и определиться с версией.
Возможно, стоит выделить отдельное разрешение (нужно только для установки статуса со списка объектов) в отдельный вопрос и реализовать его позже, после добавления статуса.