Сделать-то можно...
Виалон - не учетная система в общем случае, зачем ей подобные функции? На что с т.зрения функционала будут влиять варианты выбора, кроме п.5? Особенно с учетом того, что многие типы по функционалу мониторинга идентичны и выделять их в отдельные смысла нет в принципе.

А если грубее, то: Вам что, сил и времени девать некуда? Все остальное уже сделали, исправили? Не лучше направить силы на более нужные и уже поддержанные обществом доработки?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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