Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Добрый день. Есть компания имеющая свыше 1000 авто по всем регионам. головной офис желает видеть: Главный пользователь-
группа Регион 1: район 1, район 2, район 3.
группа Регион 2: район 1, район 2, район 3 и т.д.
а в свою очередь каждый РЕГИОН хочет видеть свои районы по группам.
Требуем разбивку группы и подгруппы!!!
После всех рассмотрений и обсуждений остался один вариант, который можем предложить, - сбросить все существующие группы и начать всё с чистого листа. Дать возможность разветвлять группы, а объекты добавлять только в одну подгруппу.
Только так можно организовать нормальную работу панели мониторинга, системы прав и создать при этом простую систему подгрупп.
Но мы не готовы так поступить с пользователями Wialon, т.к. ущерба будет несоизмеримо больше, чем пользы.
Поддерживаю введение подгрупп. Причём объект должен иметь возможность входить как в основную группу, так и в какие-то подгруппы (кто-то строит групповые отчёты по всему парку, кто-то - только по своему подразделению). Это поможет делу организации доступности групповых шаблонов для разных подразделений одной организации.
При одноуровневой системе группы начинают "лезть" в основной список, их приходится закрывать, они вылезают снова - становится трудно работать...
Коллеги никто так и не решил вопрос с подгруппами ?
а объекты добавлять только в одну подгруппу.
Звучит как ерунда какая-то. Это усечение имеющегося функционала, сейчас можно объект включать в любой список для разных целей и отчётов.
сбросить все существующие группы
Так делать точно нельзя. Забыли, что было, когда настройки топлива "сбросили"? Притом, что там было расширение функционала в виде ДПРД.
Только так можно организовать нормальную работу панели мониторинга, системы прав и создать при этом простую систему подгрупп.
Знакомый программистский подход - опять всё переделать. И снова, и снова.
На мой взгляд это крайне важный функционал, позволяющий функционально структурировать объекты, где объект также может находиться в нескольких группах/подгруппах. На текущий момент множество групп крайне неудобно.
К примеру: информация используется разными отделами крупной компании (логисты или СБ), которым нужно видеть определенные объекты, которые уже участвуют в master группировке и состоят в отдельных группах ("Фургон", "Тягач","Бортовой","Автобус") разграниченные территориально (Уфа, Лондон, Сидней). При текущей группировке необходимо создать 12 групп (это для 1 функциональной единицы).
Также не забываем и про восприятие пользователями (другой пример): в случае группировки по следующей схеме: "Регион - Предприятие - Подразделение - Тип техники - Внутренняя классификация", длина названия групп уже вместила в себя 5 слов. И если исходить из того, что на каждом этапе у нас может быть хотя бы 2 структурные единицы, то получаем список у руководителя из 32 групп (на мой взгляд может сложиться ощущение, что смотришь не список объектов, а содержание к какому-то постановлению). Та же ситуация и с геозонами - при разбиении по группам возникает огромное количество групп, которые состоят из одних и тех же объектов.
Реализаций подобных структур множество. Последняя платформа где с ними посчастливилось поработать - АСК-Навигация.
В очередной раз подошли к этой теме. Считаю что подгруппы нужны и необходимы. Каждый клиент подрастая начинает группировать свои транспортные средства.
