Форум

[QUOTE]Dmitry Valyanov пишет:
Как уже сказал Алексей Сидоренко, задача такая у нас есть в плане работ по модулю.
Проблема в том, что в продукте отсутствует такая сущность как "компания", т.е. людей сложно сгруппировать по какому-то признаку. Заводить для них отдельную группу не удобно. [/QUOTE]

Есть два вопроса:
1. Планируется создания чего то типа справочника организаций и привязки пользователей к нему?
2. А возможность коллективной работы с тикетами? (сотрудников или клиентов службы поддержки)

[QUOTE]mymanager пишет:
Ну должен быть еще какой-то параметр, который определяет что за организация. И к этой организации должны быть описания какие-то и данные по срокам техподдержки.[/QUOTE]
Параметр то есть. В данных пользователя. Его можно заполнить. Это может быть одним вариантом.
Вторым вариантом может быть создание нескольких групп пользователей. Т.е. одна группа - одна организация. (Только аккуратнее с правами). Может быть еще что нибудь можно придумать.

Ну а вообще задача сводится более конкретно к следующему:
Как сделать так, чтобы любой пользователь из определенной организации, мог видеть тикеты таких же пользователей как и он из этой же организации?
А в битриксе пользователь видит только свои тикеты :)
В этом как раз и загвоздка :)
Все остальное скорее второстепенное.

Можно, в принципе попробовать вариант два. Только определитmcz с тем, каким образом будет происходить фильтрация: либо по записи в поле организации профиля пользователя, либо по группе пользователей, либо еще как то иначе.

А вот по поводу статистики ничего не скажу. Я так понял стандартная не подойдет?
Тем более, если требуется получить статистику в разрезе организаций.
Похоже, придется делать свою.

Еще могу посоветовать следующее:

Если ситуация действительно настолько безвыходна:

Во-первых: Обратиться в техподдержку 1С-Битрикс с данным вопросом. Там точно скажут самое простое решение:) Уже личный опыт был.
Во-вторых: Посмотреть компоненты службы поддержки [B]Например( bitrix:support.ticket.list)[/B]
Может быть можно сделать свои компоненты на основе типовых, слегка изменив фильтры выборок, настроив под ваш процесс. (пользователи ведь будут через веб-интерфейс работать)

Вопрос только будет в том, что получится со статистикой.
Как потом разобраться в тикетах? :( Можно ли будет считать статистику достоверной?

[QUOTE]Даниил Макеев пишет:
Алексей Коваленко, вопрос (насколько я вижу) о коммандной работе, а не о публичности процесса. Как минимум два применения того:
- инструментарий руководителя отела технической поддержки, позволяющий оперативно оценивать состояние дел и принимать решения.
- режим "стажировки", позволяющий куратору отслеживать работу стажера[/QUOTE]

Если это так, то согласен. Вопрос надо рассматривать с другой стороны
Но все же я ориентировался на строчку:
[QUOTE]mymanager пишет:
Одна организация, в которой несколько пользователей. Надо, чтобы эти пользователи при обращении в техподдержку видели не только свои предыдущие запросы, но и запросы других пользователейЖ [/QUOTE]
Т.е. речь все таки о скорее о том, что коллектив то будет со стороны клиента?

Автор, наверное, уточнит?

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

Но задача решается.
Если выбрать данные по тикетам из техподдержки (методом CTicket::GetList), то в них есть поле с ID пользователя сотворившего тикет.
Найти по ID элемент пользователя методом (CUser::GetByID) еще проще. А там и получить из этого элемента организацию труда не составляет.
[B]Однако:[/B] [I]Вот тут может быть проблемка.
Организацию то каждый из пользователей может заполнять по разному. И если есть вероятность, что это поле может отличаться хотя бы символом....то увы :( Не применять же тут способы обработки строк и анализа данных.[/I] Гарантировать точность обработки данных в этом случае тяжело.

А вообще...если правильно сгруппировать данные, то можно получить любую статистику.
Хоть по организации, хоть по профессии. За исключением риска неточного соответствия данных в полях.
Пример несоответствия: организация [I]ООО "СК Восток"[/I] и организация [I]ООО "Строительная компания Восток"[/I] - вещи разные.
Или другой пример:
[I]Инженер-программист[/I] и [I]программист[/I]
Это, к сожалению, основная проблема организации любой базы данных.
Не зря же программисты стремятся унифицировать все что можно, создавая справочники, раздавая ID налево и направо :)

А каким образм вы определяете организацию пользователя? по профайлу?

Бизнес процессов техподдержки может быть множество.
В 1С-Битрикс упор сделан на персональную работу с клиентом.

Если подойти к задаче организации техподдержки [B]клиентоориентировано[/B], то ваша задача - [B]решить конкретную проблему клиента [/B]и [B]получить результат [/B]в кратчайшие сроки. И [B]оценить данный результат[/B] по тем или иным меркам. Вмешательство других клиентов приводит к неправильной оценке результата.

Вы работаете в данном случае не на публику. Ваша [B]задача - удовлетворенность конкретного клиента [/B]и эффективность достижения этой удовлетворенности.
Вот это примерно и есть техподдержка в Битрикс.
Возможно, меня поправят или что нибудь добавят.

А если надо на публику... используйте форум :)
[QUOTE]mymanager пишет:
- Чтобы можно было видеть вопрос/тему/ответы
- Чтобы можно было продолжать задавать вопросы начатые одним пользователем другим пользователем [/QUOTE]
Все что вы написали может форум :)
Сделайте закрытый форум для клиентов и, пожалуйста, пусть они общаются :) А вы модерируйте так как вам нравится.

Что касаемо в разрезе организаций...Тут вопрос философский.
А надо ли это?
Если вы работаете с организацией, то чем больше посредников будет тем хуже.
Исключите ненужные информационные каналы. Вам же легче будет.

Выполнил следующее:
Для нужного элемента сделал выборку с фильтром [B]WF_PARENT_ELEMENT_ID[/B], равным ID данного элемента. Кроме того в фильтре включил историю. А сортировку по убыванию сделал по полю [B]TIMESTAMP_X[/B]
После этого взял первое попавшееся значение выборки.
Вот состояние данного элемента в документообороте и получилось текущим состоянием в документообороте для нужного мне блока.
Возможно что то сделал неправильно, но работает.

А нет ли других способов сделать все попроще?

Пока сделал такую попытку:
Осуществил выборку данного элемента с включенным в фильтре [B]SHOW_HISTORY[/B]
Но :)...получил всю историю данного элемента.
А как выбрать только текущее (последнее) состояние?
Экспериментировал с другими параметрами фильтра. Но пока результата не достиг.

Был некий элемент инфоблока.
В документообороте его состояние перевели в Draft из Published.
В списке его состояние стало отображаться как Draft/Published.
Свойство [B]WF_STATUS_ID[/B] элемента по прежнему содержит "1". Этот ID соответствует состоянию Published.
Где можно обнаружить что этот элемент все же переведен в состояние Draft?
Как правильно получить текущее состояние в документообороте для определенного элемента инфоблока?