Добрый день!

Актуальная версия приложения BPMonline CRM на данный момент: BPMonline_CRM_RUS_MSSQL_5.4.0.1208

С уважением,
Белецкий Арсений
Группа компаний Terrasoft

Здравствуйте, Ольга!

Да, компонент, аналогичный TreeView есть, к примеру, он используется в окне выбора Сервиса в сервисном договоре.

Здравствуйте, Ольга!
Как сказала, Анна, такая возможность есть.
Для этого необходимо в дизайнере объектов установить в поле "Родитель в иерархии" колонку, которая будет родительской. При этом у Вас для страницы реестра нужно установить глубину вложенности (по умолчанию 1).
Но... Не все так просто.:cry:
Реестр отображает только 41 запись из БД. При установлении иерархического отображения реестра пропадает возможность постраничного просмотра.:cry:
Команда разработчиков системы на данный момент занимается исправлением этой ошибки, и в ближайших версиях BPMonline эта ошибка обязательно будет исправлена.
Спасибо Вам за вопрос.

Добрый день.

Вы можете настроить SMTP relay на Вашем почтовом сервере. В таком случае в поле отправителя будет подставляться алиас, которым на уровне BPM-a является почтовый адрес контакта.

ммммммм, подумаю, не совсем только понял, так как, по моему, когда создаешь в бизнес-процессе задачу отправки письма поле от кого не редактируемое.....

в смысле как Domino заставить в зависимости от алиаса подставлять нужный обратный адрес -- это я легко :-), но как BPMу сказать ставить разные алиасы в зависимости от того контрагента от которого ведется деятельность....

Бизнес-процесс письмо не отправляет, только создает активность.
А От Кого заполняется в момент отправки, будет подставлен адрес текущего активного пользователя совершающего отправку.

Логично, вот тут и интересует возможность выбора обратного адреса....

Попробуйте включить поле От Кого в карточке е-мейла (EmailEditPage) и прописывать адрес вручную.

Александр, а как Вы создаете Email? Если через карточку редактирования, то вручную, а если БП, то при создании Активности типа Email, проверяйте адрес контрагента и проставляйте его в поле ОТ.

THNX
Я пока не создаю :-) Я почву вентилирую :-)
Все равно спасибо, направление движения я понял, думаю все получится в итоге :-)

Вопрос закрыт открытием поля От кого в активности на редактирование. В связке c Domino работает на ура.
По крайней мере гугл и яндекс честно говорят, что письмо пришло с адреса, который писали в поле От кого в активности. Осталось прикрутить список к полю, который формируется в зависимости от текущего пользователя.

"Ильюша Сергей Николаевич" написал:1. Как можно скрыть полностью детали по уровню доступа ? Или они будут так и висеть, но там не будет не видно записей ? В разделе контрагенты снял галочку администрируется по записям, на объект детали поставил только галочку администруется по операциям и запретил группе доступ к ней. Но деталь видна в списке деталей. Редис очистил.

Скрыть деталь можно только путем удаления ее из Рабочих мест - просто сделать ее невидимой не предусмотрено в системе, поскольку отображаемые детали кэшатся в Redis. Этот вопрос уже неоднократно обсуждался ранее на Community. Оптимальное решение в Вашем случае - не добавлять деталь в рабочие места, а отдельно добавить ее в карточку (такая возможность есть в Рабочих местах). Детали карточки могут появляться/скрываться динамически.

2. Как можно в справочнике запретить доступ к определенной записи, в раздели понятно по детали, а в справочнике не нашел.

Программно настраивать видимость записей в справочнике нельзя, для этого требуется выполнить доработки в системе.

Один из вариантов такой доработки - связанные справочники, то есть, фильтрация одного поля в зависимости от другого. Пример реализации можно посмотреть в справочнике типов результатов в зависимости от типа задачи.

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

3. Есть объект с которого сделаны две детали, к одной открыть доступ к другой закрыть ? Как это реализовать? Администрировать по записям так не выйдет

В данном случае рекомендуется создать отдельные представления, и фильтровать их непосредственно в представлении. Обратите внимание, раздавать доступ на представления нельзя.

В данном случае оптимальным будет вариант, указанный в пункте 1 - добавить деталь только в карточку, и не добавлять в раздел.

4. Как закрыть доступ к "Аналитике" и "Печатям"? нашел эти объекты закрыл доступ но все равно вижу их и могу использовать.

Для того, чтобы скрыть эти детали из раздела, следует снять галочку "включить аналитику" в рабочих местах. Что касается отдельных элементов, Вам следует раздать доступ на соответствующие объекты.

В случае, если Вам нужно скрыть кнопку "Печать" в отдельном разделе, ее можно скрыть программно. Что касается Аналитики, ситуация такая же, как с деталями: можно только скрыть в рабочих местах.

Здравствуйте, Александр!

Боюсь, дам Вам повод для грусти, однако же данная функция зашита в ядро.

Есть и отрадная новость: права по умолчанию гибко настраиваются. В частности, можно для объекта установить так называемого Владельца. Для этого следует выбрать в расширенных свойствах объекта одно из полей (Ответственный, Автор, Создал) и выпадающем меню поля Владелец.

В этом случае соответствующий пользователь не будет виден на детали Доступ, однако будет иметь полные права на запись.

Кроме того, BPMonline также поддерживает различный уровень вложенности при работе с записями. Рекомендую обратить Ваши взоры к системной настройке Способ администрирования связанных объектов (QueryJoinRightLevel)

[Способ администрирования связанных объектов] — позволяет определить способ администрирования связанных объектов, например, при отображении информации об основном контакте (должности или дате рождения) из раздела [Контрагенты]. Тип: целое число. Значение по умолчанию: 0. Настройке можно присвоить следующие значения:

0 — отображать данные только по записям связанного объекта, к которым у текущего пользователя есть доступ;
1 — отображать данные только по записям связанного объекта, к которым у текущего пользователя есть доступ, но в случае отсутствия доступа к записи, отображать данные основного отображаемого поля;
2 — отображать данные по всем записям связанного объекта независимо от распределения прав доступа.

А вообще, поделитесь прикладной задачей, возможно, ее решение уже давно предусмотрено в системе, и ждет вашего правильно сформулированного вопроса :)

Спасибо за ответ, Анна! Принцип понял.
Вопрос на данный момент имеет, как и писал, теоретически-образовательный характер.

Изменил на

Добавить результат выборки по объекту -> Вхождение пользователя в роль -> В фильтре "Роль = Группа"

По логике всё должно работать, но поле "Группа" невозможно подставить в условие и приравнять к полю "Роль" - оно не отображается через элемент "Чтение данных".

Решение найдено. В фильтре объекта Вхождение пользователя в роль следует прописывать так: Роль.Id равно %чтение данных%.Группа.

Здравствуйте!

Появившаяся ошибка явно указывает на переполнение журнала транзакций БД.
Это может быть связано с тем, что на накопителе, где находится файл БД недостаточно свободного места, либо действует ограничение на размер файла БД при использовании EXPRESS версии MS SQL Server.

Для устранения ошибки попробуйте сжать БД, для этого в Management Studio в контекстном меню выберите пункт [Tasks] - [Shrink] - [Database]:

Так-же, возможно Вам будет полезна следующая статья:

http://msdn.microsoft.com/ru-ru/library/ms175495.aspx

С уважением,
Шипко Илья
Специалист службы поддержки II линии
BPMonline

Илья, спасибо! Действительно, на сервере не осталось свободного места.

Акмаль, проверьте, пожалуйста, добавляются ли данные непосредственно в таблицу БД.
При создании уведомления необходимо заполнять поля Время, Объект и Источник

Хочу уточнить, что при создании активности типа "E-mail" собственно электронное письмо не отправляется адресатам. Для отправки письма необходимо дополнительно настроить соотв. "Рассылку".

Наталия, а какими значениями можно заполнять указанные Вами поля?

Вы хотите сказать, что уведомление создаётся с помощью элемента E-mail?

Время - период, в который должно отобразиться уведомление.
Объект - идентификатор записи активности, по которой создается уведомление.
Источник - идентификатор источника уведомления (уведомление создается автору либо ответственному активности).
Источник, скорее всего, можно пропустить.

"Салихов А" написал:Вы хотите сказать, что уведомление создаётся с помощью элемента E-mail

Смотря какие уведомления. Email уведомления создаются с помощью элемента E-mail.

Наталия, а объектом может быть запись инцидента? Или только активность?

И ещё вопрос - как можно в поле Кому поставить руководителя команды, которая занималась инцидентом?

Наталия, в таблицу Reminding ничего не добавляется...

Судя по всему возникает проблема с полем Объект. Я в это поле заношу Id созданной ранее задачи. При открытии страницы уведомления в колонке Объект надпись "Нет доступа". При двойном клике на уведомлении переход на задачу не осуществляется - возникает ошибка.

Разобрался - в Объект нужно записывать схему объекта Активность.

Здравствуйте, Акмаль!

Можно. Привязывайте.

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

Какой именно учет какого времени Вам нужно реализовать в системе? Как это должно работать?

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

Здравствуйте, Акмаль!

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

С точки зрения программной реализации это существенная проектная доработка, т.к. расчет срока реакции крайне сложен и учитывает множество значений:

1. Срок по сервису;
2. Срок по пакету сервисов;
3. Критичность и срочность;
4. Часовой пояс.

Исходя из всех параметров выбирается минимальный срок реакции, и подставляется в карточку. Функциональность реализована в схеме BaseServiceRequestInBPMonlineEditPage. Для того. чтобы внести изменения в данную функциональность необходима объемная проектная доработка.

Добрый день!

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

Думаю, подойти к решению можно так:
1) Провести анализ по отработанным инцидентам в срезах: линии (1-я, 2-я, 3-я...)
2) По собранной статистической информации провести анализ времени решения инцидента на каждой из линий.
3) Провести анализ загружености (к примеру: среднее время за которое специалист приступает к решению инцидента с момента его регистрации).

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