Yes, it's sub organizations just set Category as "Office" or someting like do you have.
Пользователь
Поиск по сайту
Реклама
Опрос
Погода
Василий Каменев (все сообщения)
| |||||||||||||||||||||
|
|
Services Used by Customer
|
|
|
|
|
|
Services Used by Customer
|
So,
Organiztion it's a structure, doing the next: ParentOrg1 --> Main Office--> SLA-PO1 --> SVC-PO1 |---SubOrg1 --> SLA-SO1 --> SVC-SO1 |---SubOrg2 --> SLA SO2 --> SVC-S02 |---... It's is solution for you? |
|
|
|
|
Services Used by Customer
|
Hi Will!
Yes, we have not translator - use a google translator. 
So, about your question. The SD have internal searching by services list using the next way: Person(as Customer)-> Organization -> SLA -> Services -> SubServices Person(as Customer)-----------------> Spetcial query not exist, because all working thought Java Object Model. The seaching working perfectly, why are like change it? Are you like show in list(view) additional(CF) fields, but the system not allow you do it? br. |
|
|
|
|
Перенос вложений из заявок (servisecall ) в задания (workorder) автоматом
|
Java, но реализовать то можно на чём угодно, главное правильно высчитывать где лежит файл /000/000/.... и так же формировать эту структуру для нового файла надо корректно, а файл регить мона используя web-api СД(копировать она не умеет).
|
|
|
|
|
Перенос вложений из заявок (servisecall ) в задания (workorder) автоматом
|
Да, реализованно так: рул запускает код который копирует аттачи и создаёт записи в бд о том что скопировал.
|
|
|
|
|
Привязка ОЗ к обращению, Привязка ОЗ к обращению выдает ошибку
|
просто подумай сам и посмотри как это устроено.
История это реляционное поле, и в слиянии он просто говорит что оно изменилось. ему всё равно что там изменилось, просто количество записей иное. Если бы система делала проверку по каждой записи в Истории, тогда это был бы тормоз для системы. |
|
|
|
|
Привязка ОЗ к обращению, Привязка ОЗ к обращению выдает ошибку
|
объединение невозможно когда инфа-я измен-а в одном и том же поле в базе и на форме.
|
|
|
|
|
Привязка ОЗ к обращению, Привязка ОЗ к обращению выдает ошибку
|
А это и не пользователь, это скорее всего рулы или sd_event. Ты открываешь, рул отрабатывает или эвент, данные изменились и не совпадают с твоими, вот это ты и имеешь.
|
|
|
|
|
Время реакции, Таймер на время реакции
|
Нет этого в СД как одно целое.
У тебя 2 "проблемы", котрые надо и решать отдельно. 1-е, это расчёт "Время реакции", всё что предоставляет СД - это рулы, Приоритет = Опред. времени реакции, и так надо наплодить кучу рулов. Либо написать что-то внешнее и что будет вести такой пересчёт. 2-е, это сообщение. Таймер есть в рулах и его можно использовать для нотификации. Но если у тебя в час к примеру 50 Запросов, и в среднем их Время реакции 8 часов, то все они будут висеть в памяти апплик сервера по 8 часов - это 8*50=300 задач. Это не так страшно, но если Время реакции больше или кол. запросов выше, то всё это выростает в разы. А если ещё и это время будут двигать в любую сторону, то их количество выростет так же. У меня доходило до 4000 , после чего я просто отказался от использования этой технологии. Варианты такие: - написать внешний парсер, котрый и будет заниматся рассылкой "спама" - либо задействовать систему эскалации при помощи рапортовой системы, чтоб он присылал отчёт но уже на группу или самому чел-ку - либо поставить эту задачу хелдеску, чтоб они сами смотрели и сделать им вьюхи эту тему. |
|
|
|
|
Загрузка данных в Entity Reference (Обращения), Загрузка данных в Entity Reference (Обращения)
|
Если тип поля который был обьявлен ранее, например это Персоны и связанно с уже сушествующей таблицей, то смотри в Import Map, оно там должно быть. А вот если ты его сам придумал и объявил новую таблицу(по сути новый тип Ent), то для этого ооочень много надо сделать в плане того чтоб поле заработало.
|
|
|
|
|
Сегодня были (гостей: 9, пользователей: 0, из них скрытых: 0)