Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Предложение добавить альтернативное название для объекта, а в настройках пользователя выбирать желаемое название
как пример для нас и сервисников удобно что машина называется "НЕФАЗ Бензовоз 135", а завгар хочет чтобы было короткое название было в виде номера подразделения и гаражного номера типа "А7Б135" у него типа свая сортировка и т.д.
И данный вопрос с альтернативными названиями встречается уже не первый раз.
Поддерживаю! +1
Возможность задавать второе название объекта было бы неплохо. А то у нас объект проходит просто под номером, а клиент называет его удобным для себя именем. Потом ищешь что и где находится))
Поддерживаю +1
Строить систему учета своих объектов на основании их имен на сервере - тупиковый путь. Поэтому информация о ТС отдельно, о его имени на сервере - отдельно.
А тем временем, что мешает использовать административные поля для этих целей?
SanderAMC Система учета построена не "на основании их имен на сервере". Речь идет об удобстве визуального поиска объектов в списке. Чтобы посмотреть доп.поля нужно либо открыть окно свойств объекта, либо навести на него курсор, что не всегда удобно.
Плюсую, давно надо
Сегодняшнее обновление ввело реквизиты объекта в отношении самого ТС.
Речь идет об удобстве визуального поиска объектов в списке. Чтобы посмотреть доп.поля нужно либо открыть окно свойств объекта, либо навести на него курсор, что не всегда удобно.
Уточнение про поиск понятно.
Но это не следовало из исходного постулата, отсюда и мой комментарий.
SanderAMC Обновление уже заценили, удобнее чем вписывать это же в произвольные поля. Но оно не помогает той цели, что стала здесь обсуждаться. Да, согласен, описания в начале было мало.
Но и далеко не всем нужно подобное решение, но его реализация сильно порадует.
+1
Думаю нужно давать доступ к редактированию имени объекта клиенту. И как клиенту нравится, так пусть и меняет (все для удобства клиента, так же? 
)
Что бы не "потерять" объект прописывал его полное название в произвольные поля.
И насчет новой вкладки характеристики, думаю она бы стала более полезной будь по ней поиск. Тогда можно перенести имена из произвольных полей туда.
Думаю нужно давать доступ к редактированию имени объекта клиенту. И как клиенту нравится, так пусть и меняет (все для удобства клиента, так же? )
Что бы не "потерять" объект прописывал его полное название в произвольные поля.
И насчет новой вкладки характеристики, думаю она бы стала более полезной будь по ней поиск. Тогда можно перенести имена из произвольных полей туда.
Здесь предлагается создать есче одно поле с именем объекта которое может редактировать клиент как угодно, а в настройках пользователя или правах выбирать из какого поля отображать имя объекта
Как то мало людей заинтересовала данная функция, неужели почти никому не надо?
+1
Плюсанул
Мне кажется логично, если объект называется в системе, как нравится клиенту, а для интегратора альтернативное название хранится в административных полях (позволяет быстро найти объект по поиску и т.п.).
Мне кажется логично, если объект называется в системе, как нравится клиенту, а для интегратора альтернативное название хранится в административных полях (позволяет быстро найти объект по поиску и т.п.).
А чем интеграторы не угодили? ) Вариантов применения двух имен объектам масса: от обезличенного для посторонних действующего объекта в demo до оказания услуг клиенту - носителю другого языка. Единственно, право присвоения имен объекта стоит сделать исключительно для интегратора или на его усмотрение.
Ну, допустим. А как программа будет понимать, в какой момент какое имя показывать?
По всей вероятности, как настроить в свойствах пользователя (клиентский или служебный вариант), так и будет показывать. А в свойствах объекта имя общее, и имя служебное (ну или как-то по другому будет называться).
Дмитрий Л, где настроить, мы найдём. Вопрос другой: ЧТО настроить?
По-простому это может быть что-то типа: показывать служебное имя в CMS Manager'e и клиентское имя в основном интерфейсе и во всех аппах. Но аппы ведь тоже могут быть служебными — тогда надо вводить новый признак аппа и его где-то хранить (+ что делать с не-нашими аппами?).
Ну или другой вариант: это может являться признаком пользователя, и в соответствии с этим признаком ВСЕ имена объектов будут показываться ему либо как служебные, либо как клиентские.
alek, думаю, что варианты настройки необходимо рассматривать с позиции задач и применения.
Я вижу основное применение для дилера, когда клиент может видеть свои объекты по госномерам, или по бортовым номерам, или еще по каким, как ему удобно, а дилер обзывает объекты в том виде, как у него обозваны объекты остальных клиентов. Или, к примеру, необходимо скрыть визуальную идентификацию объекта, например, для трансляции в демо, "чтобы и объекты реалистично катались, и клиент спокоен был". В этом случае служебный и клиентский будут показываться по тому же признаку, как, например, показывается или нет телефонный номер навигационного терминала. Причем, если в CMS Manager в колонках могут быть оба названия, то в основном интерфейсе - в зависимости от настроек доступа..
Ну и призрачный вариант применения, когда есть клиент, и есть его владелец, который имеет еще кучу предприятий и желает видеть объекты своих предприятий так, как ему хочется видеть. В этом случае наверное придется делать отдельный признак в настройках доступа.
К сожалению, через настройки доступа это все осуществить невозможно.
Могут быть только вышеописанные варианты (1- по точке входа, 2 - по признаку пользователя) либо какие-то другие, до которых мы пока не додумались.
К сожалению, через настройки доступа это все осуществить невозможно.
Могут быть только вышеописанные варианты (1- по точке входа, 2 - по признаку пользователя) либо какие-то другие, до которых мы пока не додумались.
В настройках объекта добавить поле альтернативное название (есть же второй телефон)
В настойках пользователя добавить галочку "заменять на альтернативное название" (как пример галочка "отрисовывать графики на сервере"), и если клиенту надо он поставил галку и ввел названия какие ему надо
Чего то тема как то умерла.
Неужто почти никому не надо ?
jecash, давайте ещё раз чётко сформулируем цель, ради которой надо вводить альтернативное имя объекта.
Вроде бы проблема такая (поправьте, если не так): интегратору (дилеру) хочется именовать объекты иначе, чем конечнику. Так?
Если это так, то решение такое: реальное имя объекта отдаём в угоду конечнику, а интегратор (дилер) хранит своё имя в административных полях.
Почему именно так, а не наоборот? Потому что конечник осуществляет мониторинг и любуется на свои объекты постоянно, и ему важно, как они у него называются в интерфейсе. Дилер же обращается к объектам в случае нужды (оказать техподдержку, что-то настроить и т.п.). Дилер не занимается постоянным любованием, а совершает какие-то точечные действия с объектами. Поэтому, как мне кажется, используя поиск по административным полям, он сможет быстро найти нужный объект (поиск по админ полям есть везде), сделать всё, что надо, и забыть до следующего раза. Нет нужды городить огород со вторым именем.
Кто что думает на этот счёт?
Аналогичный вопрос возникал, и очень хотелось бы иметь возможность иметь на выбор два имени объекта. Приведу несколько примеров:
1) строители - клиент, пользуются услугами мониторинга объектов, выиграли тендер у иностранной компании, и в условии заключенного договора - предоставить контроль объектов и для них.
2) Аналогичная ситуация, когда клиент является "дочкой" иностранной компании.
3) Клиент желает видеть короткие условные названия своих объектов, и на одном сервисе могут быть объекты разных клиентов, но с одинаковыми названиями, и далеко не всегда удобно администрировать такой "огород".
4) Предоставление пользовательского доступа к просмотру объектов неограниченного круга лиц так же желательно с подменой реальных названий (отображающихся у клиента) на условные. Такое может быть применено с демонстрацией демо-доступа с использованием реальных объектов, или для использования, например, для информации о маршрутах городского транспорта, где объекты будут названы не так, как их видит клиент, а номером городского маршрута.
Предполагаю, что управление выбором основного и дублирующего названий объекта стоит оставить за администратором ресурса, а не за клиентом.
п. 1 и 2 - выглядит так, будто надо просто в названиях кириллицу заменить на латиницу.
п. 3 - с альтернативными именами проблема не решится, а только усугубится, станет ещё больше шансов для совпадений и огорода имен.
п.4 - мы, например, в таких случаях ретрансляторы используем (когда делаем демо для выставок и т.п.)
Так зачем спрашивать, когда проще просто сказать НЕТ и закрыть тему?
Мы пытаемся выявить реальную потребность и реальные кейсы для внедрения такой доработки.
+1 поддерживаю
Мы пытаемся выявить реальную потребность и реальные кейсы для внедрения такой доработки.
Таким методом реальную потребность не выявить. Т.к. у Вас нет связи с конечным пользователем. А 90% клиентов хотят их названия.
И как пример у нас тех поддержка одновременно может отслеживать по штук 50 объектов РАЗНЫХ клиентов одновременно (проблемные машины) и если бы мы переименовали бы их объекты как они хотят, представьте как бы выглядел этот бардак. (если хотябы пару клиентов сделают название по гаражному номеру к примеру "нумерация от 1 до 100" как отличать их машины в списке. )
Пропала со связи к примеру машина №5 а их в списке 10 с таким названием от разных клиентов, и тут начнется произвольные поля и т.д., а я к примеру знаю что у "Васи" эта машина в ремонте и она может выключится и чтобы узнать что это "Васина" машина потухла, а не другого клиента надо будет лезть в свойства, произвольные поля и т.д. чтобы просто узнать эта та машина или нет, а если в моем списке она будет называться к примеру "Вася №5" то одного взгляда хватит для этого
jecash, возможно, машины должны называться, как угодно клиенту, а техподдержка, оказывая помощь этому клиенту, сначала должна залогиниться от него. Тогда никакая левая машина с таким же названием под руки не попадет и у техподдержки перед глазами будет такая же картина, как у конченого клиента. Вам не кажется?
jecash, возможно, машины должны называться, как угодно клиенту, а техподдержка, оказывая помощь этому клиенту, сначала должна залогиниться от него. Тогда никакая левая машина с таким же названием под руки не попадет и у техподдержки перед глазами будет такая же картина, как у конченого клиента. Вам не кажется?
Реальный пример
Есть приборы всем известного Российского производителя, у них проблема пропадают по не известным причинам со связи. Стоят они не у одного клиента. И часть проблем с этими приборами решаются есче до того как клиент мог бы узнать о них (т.к. есть временное решение пока производитель решает эту проблему).
А когда звонит клиент и говорит посмотрите чего то не так показывает, тогда можно зайти под клиентом и обсудить (решить) его проблемы.
Как вы предлагаете отслеживать десятки проблемных машин разных клиентов, сидеть и переключать учетки.
А так добавили эти объекты в текущий список и отслеживаем.
jecash, возможно, машины должны называться, как угодно клиенту, а техподдержка, оказывая помощь этому клиенту, сначала должна залогиниться от него. Тогда никакая левая машина с таким же названием под руки не попадет и у техподдержки перед глазами будет такая же картина, как у конченого клиента. Вам не кажется?
Каким образом отличать объекты с одинаковыми названиями "как захотел клиент" друг от друга при работе в CMS Manager? К примеру, нужно скопировать объект "по образу и подобию" другого объекта, и для этого сначала надо сделать определенные манипуляции, чтобы найти копируемого. Если бы вкладка ОБЪЕКТЫ имела колонку ГРУППЫ, это немного облегчило бы задачу. Но все же перечислили уже много доводов "ЗА", тогда как доводы "ПРОТИВ" имеют решение в виде дополнительных манипуляций, усложняющих работу пользователей продукта ГУРТАМ.
Дмитрий Л в CMS на вкладке объекты есть произвольные и админ поля. Мы в эти поля заносим группу (клиента) по ним можно искать. Нас устраивает.
Дмитрий Л в CMS на вкладке объекты есть произвольные и админ поля. Мы в эти поля заносим группу (клиента) по ним можно искать. Нас устраивает.
Да, я в курсе, говорили уже про произвольные поля. Еще много чего говорили. Все люди взрослые, может стоит тогда не ерзать, а сказать прямо:
...просто сказать НЕТ и закрыть тему?
Моя цель — не сказать ДА или НЕТ, а выяснить практическое применение доработки. Пока что это не удаётся. Слишком много эмоций в постах и слишком мало сути дела.
Вижу следующие ситуации:
1. Техподдержка сидит на сайте мониторинга и выискивает там объекты, которые вышли из строя, с целью заметить их раньше, чем это сделает клиент, и как-то их пофиксить. Допустим, у объектов по два имени. И какое из них надо показывать работнику техподдержки? Видимо, системное (не клиентское). В таком случае, когда клиент звонит и жалует на неработоспособность терминала, работнику техподдержки станет проще локализовать этот объект в списке, учитывая, что у них будут разные имена? Правда проще???
Но вот есть в панели мониторинга одна вещь, которая долдна реально помочь. Если, как говорит jecash это делается исключительно для какого-то определенного вида глючного оборудования, то там есть фильтр по оборудованию, и в рабочий список можно вывести только объекты, работающие на этом оборудовании. Это должно несколько упростить работу (ну или, как минимум, меньше нагружать браузер).
2. Дмитрий Л, Вы предлагаете добавить в ЦМС колонку с группами для таблицы объектов. А не проще ли воспользоваться поиском по группам слева? Также вопрос: а что именно в данном случае обозначает принадлежность к группе? создаёт группу клиент или интегратор? Возможно, колонки с создателем и учеткой отчасти отвечают на вопрос, к какой группе принадлежит объект.
alek, не буду повторяться. Добавлю к уже написанному, в ответ на примеры работы техподдержки.
Часто контроль объектов, действий, водителей и прочего осуществляется посредством уведомлений. Привязка уведомлений к имени объекта. Это тоже может добавить неразберихи.
PS Повторюсь: эти примеры из возможного. Чтобы не получить это в реалиях, приходится ставить перед фактом клиентов, что объект будет называться "так, а не иначе". Но это не убавляет пожеланий клиентов о том, чтобы объекты обзывались так, как им нравится. А у пассажироперевозчиков (такси и автобусов) клиенты меняли названия из-за смены номеров (у некоторых до четырех раз смена номеров производилась). Была путаница для нас.
Если бы вкладка ОБЪЕКТЫ имела колонку ГРУППЫ, это немного облегчило бы задачу.
Надеюсь, вы уже заметили и активно пользуетесь этой функциональностью в CMS manager, т.к. она в одном из последних обновлений попала в релиз.
Дмитрий Л пишет:Если бы вкладка ОБЪЕКТЫ имела колонку ГРУППЫ, это немного облегчило бы задачу.
Надеюсь, вы уже заметили и активно пользуетесь этой функциональностью в CMS manager, т.к. она в одном из последних обновлений попала в релиз.
Спасибо. Не хватает только сортировки по этой колонке, для быстрого поиска необходимого объекта или нескольких объектов в группе.
Чего то тема с альтернативным названием остановилась, неужели почти ни кому не надо?
Не хватает только сортировки по этой колонке, для быстрого поиска необходимого объекта или нескольких объектов в группе.
А часто бывает, что объекты состоят только в одной группе? Т.к. сортировку можно добавить, но она будет сортировать только по первой по алфавиту группе, в которую входит объкт. Есть сомнения, что это будет эффективно.
Чего то тема с альтернативным названием остановилась, неужели почти ни кому не надо?
Очень даже надо! Ждем решения.
И есче раз подниму эту тему.
В виалоне в характеристиках объекта есть поле "Регистрационный номер".
И в зависимости от настроек пользователя заменять наименование объекта (в списке и отчетах) на это поле (или добавить подобное поле).
т.е. минимальные изменения, скрыть одно поле и показать другое в зависимости от установленной галочки. Можно же сейчас добавлять вторую строку в список с вспомогательной информацией, почему это нельзя.
Итак, давайте попробуем синхронизироваться, что у нас есть.
Действующее лицо - клиент.
Что надо? Иметь своё удобное название.
Где? В панели мониторинга, в отчетах, на карте, т.е. везде в WialonHosting вместо оригинального имени.
Надо ли ему видеть оригинальное название? Да, в свойствах объекта, если вдруг нужно будет обратиться к интегратору и найти общий язык.
Пользователь сам заполняет альтернативные имена, сам себе и включает их отображение, когда они будут заполнены.
Действующее лицо - интегратор.
Что надо? Иметь своё удобное название.
Надо ли ему видеть второе название? Да, в свойствах объекта, если вдруг нужно будет обратиться к клиенту и найти общий язык.
Надо иметь возможность найти объект по второму имени.
Действующее лицо - система.
Нужен дополнительный фильтр по второму имени в панели мониторинга и CMS.
Второе название может быть только одно.
Права будут аналогичны как для основного имени, или иначе ограничивать, или совсем не ограничивать?
Верхний пользователь будет видеть всегда только оригинальное название.
Если нет второго имени, а опция включена, то показывать оригинальное имя.
Вопрос: Надо ли помечать какое из имен используется у клиента? Не вызовет ли это путаницы?
Локатор тоже с возможностью двух имен должен быть?
Что из списка правда или нет? Решаются ли таким образом все поднимавшиеся вопросы? Что, может, не учтено?
Надо ли ему видеть оригинальное название?
Ненадо. Если интегратор может найти объект по второму имени зачем оно клиенту. Хотя если он будет видеть хуже никому не будет.
Верхний пользователь будет видеть всегда только оригинальное название.
Пусть также выбирает какое имя ему удобно
Надо ли помечать какое из имен используется у клиента?
зачем, можно зайти в настройки этого пользователя или где это будет менятся и посмотреть что у него включено (оригинальное или альтернативное название)
Локатор тоже с возможностью двух имен должен быть?
да
Права будут аналогичны как для основного имени, или иначе ограничивать, или совсем не ограничивать?
права тоже нужно ограничивать чтобы все кому попало не меняли названия.
Если нет второго имена, а опция включена, то показывать оригинальное имя.
Да.
интересно а какое имя будет отображаться в Locator'e?
интересно а какое имя будет отображаться в Locator'e?
Ну по идее должно отображаться в зависимости от настроек пользователя который создал этот локатор.
Eсть еще мнения? Хотелось бы видеть актуальна ли всё еще тема и правильно ли мы видим концепт, как описано в комментарии выше?
tata не совсем понятна реализация, так как если клиент хочет видеть свое название, то как разделять клиента и не клиента?
єто должно біть удобно, для клиента и не клиента
