Будущая функциональность: типы объектов и предсозданные типы машин

Спасибо за ваш комментарий, SanderAMC

Поняла, что немного не ввела в курс дела, а сразу с места в карьер. Дополню:

Целей всего этого мероприятия несколько:
1. сейчас поле "Тип т\с" заполнено более чем у 10% объектов хостинга. Это много. К сожалению, это поле не совсем (а если точнее - то "совем не") применяется по его назначению. Там полная каша и мусорка. И из-за того, что каждый использует эти поля как хочет - не дает в полной мере использовать потенциал данных для общего блага. Мы хотим привести поля в порядок. Подбирались мы к этой задаче очень долго, занимаясь более важными вещами, но вот настал этот час

2. в перспективе упростить интерфейс для конечных пользователей, т.е. убрать ненужные поля\вкладки для конкретно их типов объектов. Может быть, заточить интерфейс именно под тот функционал, который будет нужен ежедневно

3. Дать возможность дополнять\вводить нужную информацию по конкретному типу транспорта. Например, многим не хватает количества пассажиров для автобусов, но делать новую настройку\поле для всех будет не очень логично, но добавить такое для именно автобусов помогло бы перевозчикам. Добавить грузоподъемность кранов, отличать грузовики по количеству осей, группировать объекты по их типам в мониторинге, сортировать в поиске по типам и т.д. - все это будет возможным, но только после такой рутинной и ненужной задачи как введение типизации.

Надеюсь, на этом вопрос приоритизации задач будет закрыт и обсуждение будет вестись по существу вопроса

Мне больше шаблоны объектов нужны, чтобы применялись автоматически настройки типа терминала, пробега, детектора поездок, датчики, настройки топлива.
Типа легковой, только навигация - ДУТы не создаются
Грузовой 1 бак/2 бака и т.п.

Ну или в базовом варианте - сохранить какой-то из объектов как шаблон.
"Создать из wlp", это вариант, но имхо - костыль.

SanderAMC, у нас итерационный подход к разработке. Вы правильно поняли, в первой версии будет только сама библиотека. Затем будем вводдить зависимости, скрытие\раскрытие полей, изучать иные нужды и проблемы.

Ringo, спасибо за обратную связь! про шаблоны - по сути, сейчас копирование объектов отвечает вашей нужде?

RedRock, спасибо! я искренне надеюсь, что в приведенной выше библиотеке приведены все типы транспорта, которые могут понадобиться пользователям. Конечно, всегда будет существовать что-то, чего у нас не будет, но мы готовы к тому, что надо будет добавлять новые типы

SanderAMC, конечно у нас есть цели и мы представляем, к чему мы стремимся. По разным причинам пока что о них сообщать не вижу надобности.
Цель этой ветки - предупредить о грядущих изменениях, заранее выслушать отзывы и проблемы, которые могут возникнуть после введения библиотеки типов, трудности, с которыми вы и пользователи могут столкнуться и т.д. Впрочем, похоже, что можно работать как раньше и просто выкатывать изменения без лишних дискуссий

Копирование требует памяти, какой объект был с нужными настройками, потом из скопированного нужно вынести ID, произвольные поля и т.п.
Тоже вариант, конечно, и тоже костыль.

mapa, возможно стоит выделить карьерную технику в отделный раздел. Напрямер тяжолый самосвал больше подходит под класс грузовиков подлежащих оборудованию тахографов с блокам нкм, а карьерный самосвал, такой установки не требует. Т.е. у первого было бы неплохо добавить характеристику тахограф.
Так же, типы обьектов хотелось бы видить в уведомлениях, например при контроле скоросного режима приходиться выдилять группу, а так можно использовать группу клиента, а в уведомления добавить тип тс.
И былобы интересно увидить поиск и сартировку в панели мониторинг по типу транспорта, возможно клиента заинтересует отображать тип транспорта в названии обьекта на карте.
И прям сейчас пришло в голову, в шаблонах отчета такая групировка и фильтр так же необходимы - это опять таки избавит от добавления групп для этих целей.

А можно ли, как-то "запилить" функционал саппорта, Я имею ввиду "пимпу" что б пользователь мог  ставить заявки, на обслуживание с конкретным объектом. А то постоянно сталкиваемся с запросами: " Здравствуйте, вы унас  пол-года назад ставили "линейку" на зеленый вольво, мы его не видим." Так будет ясно кто обращается и чего хотят.

Нет, я имел в виду другое. Если у клиента какие то проблемы с объектом, он пишет на саппорт и или звонит, чаще звонит. И разговор начинается, как правило, что мы ставили год, полгода назад ставили ему на синий вольво, желтый генератор, красную заправку и т.д. (нужное подчеркнуть)   линейку (ДУТ), счетчик. и ОНО не работает. Выяснение того, как минимум,  кто это звонит, что это за объект, когда и что поизошло, затягивается. Так как клиент, искренне считает что все сотрудники должны знать о чем именно он говорит. По этому, было бы удобно, что б в карточке автомобиля была кнопка, нажав на которую,  клиент мог сообщить что у данного объекта, не работает ДУТ, проточник, концевик и т.д, а саппорт, мог автоматом увидеть это. таким образом саппорт, видит что это за объект, что за заказчик.  что нужно сделать, отправить туда монтажников или ребутнуть трекер. Идея в том, что б интегрировать сообщения о неработоспособности, непосредственно в виалон. пусть это будет отдельный платный модуль, но когда у тебя много объектов, в разных концах страны, + пользователи котрые чуть что звонят, такой бы функционал, очень облегчил жизнь интеграторам

vad_98, буду вас немного пытать, но - а зачем вам этот номер сим? вы его каким образом потом используете?
сейчас можете использовать для записи вкладку "произвольные поля", где Имя - это будет имя поля (в вашем случае - Номер сим в формате ICCID), а в поле Значение - собственно, сам номер.

Есть возможность создать ретранслятор из существующих объектов, тут подробнее https://docs.wialon.com/ru/hosting/cms/retra/retra.
Или вы имеете в виду, чтобы была возможность привязать получение данных от нескольких трекеров в один объект?

Не заметил   информации будет ли данное поле обязательно к заполнению (хотелось чтобы не было).  Пока в описанном потенциальном функционале  необходимости не вижу.   

А вот предложение Ringo  относительно шаблонов настроек (которые пользователь сам корректирует) заметно упростило и ускорило бы  работу

По загрузки из wlp, есть ли возможность сохранять wlp шаблоны на ресурсе, например так же как ddd файлы водителей или по примеру хранения мультимедии.
Если будит возможность загружать из wlp файды с ресурса УЗ, то сам интегратор может решить какие шаблоные ему нужны.

Rotinberg_VO, спасибо большое за отзыв! периодически обращаются по поводу использования объектов как прицепы и возможность отслеживать сцепки объектов с объектами. Подобная задача есть в списке улучшений, но скажу честно: пока что она выглядит крайне ресурсозатратной, в ближайших планах ее реализация не планируется.

Действительно, вашу задачу библиотека типов никак не решит. Но мы сделали пока что только первый шаг в этом улучшении. На данном этапе мы пока что только внедрили унифицированную среди всех пользователей библиотеку.
Следующим логическим шагом станет внедрение фильтрации объектов по этому признаку в разных частях функционала. К сожалению, мы не можем всё и сразу

Было бы очень круто, если бы вы нашли время и в подробностях расписали, почему не подходит модуль прицепов для решения ваших задач. Точнее, какие у вас есть задачи и как вы их решаете текущим функционалом.

funhrum, спасибо большое за ваш неравнодушный пост! Я очень рада, что могу с кем-то подискуссировать на тему типизации транспорта

Не только на вкладке Основное, но и на Характеристиках
А какой функционал вы бы ожидали от поля?

Я думаю, что все поля одинаково нужны и важны. Особенно на вкладке Основное. Мы действительно думали над тем, чтобы сделать Тип Объекта тоже обязательным полем. Но передумали. Возможно, мы ошиблись.
Мне искренне жаль, если мы внесли негодуйство в ваше сердце. Будем смотреть на отзывы и то, как пользуются полем. Возможно, будут какие-то изменения.

Очень хороший вопрос Для чего оно надо: во-первых, для того, чтобы уменьшить количество папок с объектами у пользователей. Тип транспорта становится свойством для фильтрации, вместо того, чтобы множить папки. Во-вторых, теперь у всех пользователей типизация будет идентичной. Пользователи из одной организации больше не должны синхронизироваться вручную, выверяя написание каждого типа транспорта.
В-третьих, сфера применения типов транспорта очень широка и на ее основе можно менять вообще все Поэтому я и спрашиваю, что партнеры хотели бы улучшить во взаимодействии с системой с использованием этой типизации. Мне кажется, партнерские ответы на вопрос "что бы нам ещё такого-разэдокого сделать", это и есть то, для чего оно надо. У меня есть свое видение, куда и как оно должно\может применяться. Но очень хочется сделать так, чтобы для вас это было применимым и полезным.

Дайте, пожалуйста, знать, если у вас остались вопросы "для чего оно надо". Я люблю отвечать на вопросы

Сейчас эту возможность закрывают Услуги, их ручное назначение и управление. Хочется минимизировать времязатраты партнера, чтобы тип объекта пользователя предопределял интерфейс. Настроек у нас так много, что в существующих надо разбираться часами... А вы предлагаете еще одну.

Да, очень хочется так и сделать: "для шаблона "Человек" рост и вес, для "Животное" имя и чем кормить" во вкладке Характеристики (ведь это характеристики объектов Человек и Животное соответственно.
Для таких способов применения и заводилась унифицированная типизация объектов. Без нее все это невозможно. Но проанализировать для всех типов объектов необходимый набор полей и реализовать - достаточно тяжелая задача. Поэтому сначала мы выпустили просто возможность установки типов, а потом будем смотреть, что на основе этого можно еще сделать.
Немного не понимаю, причем тут поиск по произвольным полям. Почему бы не структурировать имеющуюся информацию и чтобы каждому отдельному пользователю не надо было изобретать свой велосипед с характеристиками объектов?
Если я неправильно вас тут поняла - дайте знать.

где-то выше в треде (или в другой ветке) был обоснованный ответ от партнера, почему текущая функциональность не совсем удобная

Я рада, что вам нравится возможность создавать группы объектов. Но некоторые общепринятые и самые популярные критерии объектов можно сделать признаками для фильтрации. С существующей функциональностью можно сделать всё, но мы хотим сделать это "всё" еще удобнее. В конечном счете, можно вообще не использовать никакие фильтрации и поиски для объектов, если создавать для каждого признака свою группу.
Вам хватает существующей функциональности, каким-то другим пользователям нет.

Нет, сущности у нас остаются прежние: объекты, пассажиры, водители, прицепы... Это скорее единый критерий (или характеристика ) для объекта.

Добрый день, Any0ne! Спасибо за обращение, обязательно в ближайшее время крестик вернется! Извините за неудобство

Nayn, спасибо за сообщение

первое "Другое" на скриншоте относится к категории "Персональный трекер", а второе "Другое" - к категории "Стационарный объект".

К сожалению, цель унифицированной библиотеки как раз в том, чтобы все типы были настоящими и реально существующими. А Произвольные поля (как вкладка) остались и там вы все еще можете написать любой тип транспорта, даже если это Звёздный лорд

Ну, а если серьезно - а какой тип транспорта вы бы хотели тут проставить? Какого не хватает? Мы готовы дополнять библиотеку и уже дополняли ее как раз после заявок партнеров. Если что - на вкладке Характеристики больший выбор типов именно транспорта, а не объекта

InformByuro спасибо большое за комментарий, такая задача существует в списке возможных задач на будущее. будет реализована как только будет приоритизирована среди других задач.

Предлагаю создать шаблоны для датчиков. Формулы писать как бы не совсем правильно в свойствах.
У меня например с математикой проблемы )) зато с физикой все огонь.
То как сейчас реализовано, ну как бы не каждому дано понять.