Вопрос

Добрый день.
Уже писала про фильтрацию в разделе Процессы в теме
Теперь заметили следующую особенность : в реестре всегда отражается, что Ответственный за элемент процесса = создатель этого элемента. (как на рисунке)
Где закралась ошибка? ведь на самом деле ответственный за указанный элемент следующий по процессу сотрудник, а не его создатель.
Фильтр в разделе по ответственному от этого работает не правильно, и пользователи не могут в разделе увидеть свои текущие элементы процессов.

У меня такой же вопрос

7 комментариев

А Вы в самом процессе переназначаете Ответственного на следующего? А то, я подозреваю, что при создании элемента процесса ответственный ставится как раз равным автору этого (нового) элемента процесса, т.е. текущему пользователю - тому, кто выполняет этот шаг.

Ответственный указан на уровне диаграммы процесса (прямо в дизайнере элемента задача или при передаче параметров процесса) - и это разные пользователи.
Кроме этого вообще-то возможен вариант когда при создании задачи пользователя поменяли вручную (опять же это разные пользователи).

Попробуйте в sq_Workflow добавить JOIN с tbl_Tasl по по WorkflowID, и затем вытащить колонку OwnerID (ну и соответственно OwnerName). Тогда в ней будет отображаться именно ответственный по задаче, а не по процессу.

Проблема не совсем в этом.
По OwnerID элемента процесса в разделе стоит фильтр - отражаются только элементы, за которые пользователь ответственный. Поскольку в самом поле ответственный неправильно указан , то и этот наложенный фильтр работает не правильно.
Пользователи (не администраторы системы) видят в этом разделе только чужие элементы процесса, которые следуют за их собственными выполненными элементами. Те текущего действительно активного своего процесса пользователь не увидит, пока не выполнит этот элемент.
Мой sq_Workflow в приложенном файле.
Как сделать так, чтобы пользователи видели в разделе все же именно свои элементы?

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

OwnerID элемента процесса = ID контакта запустившего процесс и != ID контакта ответственного по элементу.

Для того, чтобы в реестре настроить колонку, которая бы отображала именно ответственного элемента задачи процесса, необходимо sq_Workflow привести к следующему виду:

2

Итого получим:

1

Нашла ошибку почему отражался в колонке неправильный Ответственный за элемент !
Проблема была в том, что в запрос OwnerName вытягивался как ответственный процесса.
Необходимо в sq_Workflow добавить в JOIN по WorkflowID добавить tbl_Contact, и затем вытащить колонку OwnerName из этой таблицы.
Тогда в колонке будет отображаться именно ответственный за элемент процесса (создатель элемента, а не самого процесса).

Дополнительно добавила в sq_Workflow JOIN с tbl_Tasl по по WorkflowID, для отражения ответственного по самой задаче.

Теперь касательно фильтра, который накладывается в разделе.
Я делала так, чтобы Создатель процесса видел все элементы по этому процессу + Создатель элемента процесса видел этот элемент + Ответственный за задачу видел свои задачи и элементы процесса по этим задачам.
Запрос в файле.
Вопрос закрыт.

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

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

Terrasoft 3.3.0.60
У одного из пользователей внезапно появился такой баг:
При попытке копировать ранее уже созданный документ (ответственным по которому является этот же пользователь) в поле "Ответственный" пусто. При попытке выбрать ответственного из списка пользователей вручную - отображаются все, кроме этого самого пользователя.

Подскажите пожалуйста хоть в какую сторону копать...
Заранее спасибо!

У меня такой же вопрос

2 комментария

Не в правах ли пользователя на данного недоступного ответственного дело? http://www.community.terrasoft.ua/forum/topic/6744 вчерашнее

Спасибо, Александр!! ))
Помогло ))

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

Добрый день!

Почему не отправляется письмо ответственному за инцидент, как это реализовано в Задаче?
Вроде все функции есть (стандартный функционал, ничего не меняла). Сообщение с вопросом об отправке письма появляется, а письмо не приходит на почту.

версия TS XRM 3.3.1.97

У меня такой же вопрос

5 комментариев

1. Из задач письмо отсылается нормально?
2. Что видно в отправленных или исходящих в Outlook после попытки отправить письмо?

1. да
2. не создается письмо

Кстати, а можно такой же функционал (отправка письма ответственному) как в задаче сделать и в Проекте, но не копирую полностью все, а как-то проще?

Попробуйте проверить шаблон, назначенный (есть ли он и работает ли) в системных параметрах для отправки уведомления для раздела инциденты.

проверила. шаблона не было просто) создала его и привязала к системной переменной через настройки.

а что по поводу отправления писем из проектов можете посоветовать? слишком уж много функций используется при отправке письма в задаче. как-то упростить процесс нельзя для проектов?

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

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

Якщо я замість ds_Owner буду використовувати ds_Contact(з необхідним активованим фільтром) для заповнення полів "Відповідальний" (Нпр.:в карточці Задачі), чи будуть негативні наслідки? Справа в тому, що через ds_Owner отримуємо тільки користувачів системи. А мені необхідно розширити до всіх співробітників.
Я так зрозумів, після цього не можна буде використовувати функцію нагадування. Чи можуть бути ще якісь наслідки?
Щиро дякую.

У меня такой же вопрос

7 комментариев

У випадку коли "інших" співробітників(не користувачів) не так багато можна додати користувачив у розділі "Администрирование" та "повісити" на них необхідні контакти з ds_Contact і не купляти ліцензії :).
Це дасть можливість їх визначати як відповідальних у всіх елементах СРМ.
Ми саме так вчинили, в нашому випадку таких співробітників 9ть і вони не користуються СРМ,а лише виконують операційні функції.

Нажаль, багато. Десь біля трьох сот.

Юрий, я не думаю, что при подобном изменении будут какие-то критические последствия. На самом деле механизм напоминаний корректно работает и при изменении ds_Owner на ds_Contact в датасете задачи (Вы можете убедиться в этом, проверив деталь "Напоминания" в разделе "Задачи"). Другой вопрос, что в данном случае необходимо ставить напоминание автору, а не ответственному, так как ответственный может увидеть напоминание только когда войдёт в систему, а без лицензии он этого не сможет сделать.

Возможно, "некорректностью" будут считаться результаты выполнения некоторых действий, которые ссылаются на ds_Owner (например, действие "Изменить ответственного для выбранных записей"). Дело в том, что они обращаются к датасету ds_Owner напрямую из скрипта, и для того, чтобы они работали так же, как и в карточке задачи, необходимо в их обработчиках указать вместо ds_Owner Ваш датасет.

Дякую, Олег. Наскільки я зрозумів, ds_Owner має ті ж дані що і ds_Contact тільки зі своїми фільтрами. В тих місцях, де ці фільтри активуються, мені потрібно замінити на ds_Contact з активацією мого фільтру. Таких місць виявилось не багато. В основному в карточках редагування записів в основних розділах і пара карточок в деталях. Там де дані беруться для грідів і звітів фільтри не використовуються тому збережені дані повністю відображаються.

Да, Юрий, Вы абсолютно правильно поняли. ds_Owner получает данные из той же таблицы tbl_Contact. Но он содержит гораздо меньше полей (всего 4), запрос содержит связь через INNER JOIN с таблицей tbl_AdminUnit (за счёт чего происходит выбор только пользователей) и отличается фильтрами.

Олег, ще одне питання. А якщо у гріда датасет ds_ContactInAccount і поле відповідального посилається на довідник ds_Owner.
Дані про відповідального отримуються через sq_ContactInAccount, а там LEFT OUTER JOIN на tbl_Contact і обмеження немає.
Що ж ds_ContactInAccount отримує із ds_Owner?
Автоматично згенеровані запити для вставки, зміни і видалення? Чи підписку на події цього датасету?

В данном конкретном случае разницы нет, так как эта деталь используется только для отображения, редактировать её нельзя. Но если Вы будете обращаться к полю "Ответственный" датасета ds_ContactInAccount из скрипта и получите датасет этого поля, он будет содержать значения только пользователей системы. Также в общем случае указание датасета ds_Owner вместо ds_Contact даёт:

1) если бы реестр был редактируемый, в поле "Ответственный" можно было бы выбрать значения только из ds_Owner;
2) если бы реестр содержал кнопки "Добавить", "Копировать", "Изменить", "Удалить", и, соответственно, для него было бы определено окно редактирования, то в этом окне также в поле "Ответственный" можно было бы указать только значения из ds_Owner.

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

Здравствуйте.
Terrasoft CRM 3.02. Обладая правами администратора, не могу сменить ответственное лицо в карточке контрагента. Ответственным автоматически назначается пользователь, создавший карточку. Почему так? По логике, администратор должен иметь возможность менять ответственных лиц контрагента.

У меня такой же вопрос

7 комментариев

Может для поля стоит только чтение?
у Вас ошибку выдает или поле просто "серое"?

Вроде, администратору даны все права. Поле не серое. Ошибку не выдает. Но при попытке замены в списке возможных вариантов выдается только запись создавшего контрагента.

Возможно, Вы не очистили поле фильтрации, и у Вас в нём остаётся текущий пользователь. Для отображения остальных нужно очистить поле и нажать кнопку "Поиск".

Олег Лабьяк,
разработчик,
3-я линия Службы поддержки Terrasoft.

Еще вариант - в разделе "Администрирование" у Вас только один пользователь - администратор (и именно он в списке ответственных)
--------------------------------------------
Лабитек
Центр разработки приложений

"Валерий Андрусик" написал:Еще вариант - в разделе "Администрирование" у Вас только один пользователь - администратор (и именно он в списке ответственных)

+1

У нас 2 администратора и несколько пользователей. Но ответственных лиц менять не может никто.
Ответственным лицом становится только тот (админ или пользователь), кто заводит карточку контрагента.

Проблема в версии - не пользуйтесь версией 3.0.2

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

Нередко компаниям, в результате реструктуризации или каких-либо видимых причин необходимо перераздать права доступа на записи в приложении Terrasoft CRM.
В том случае, если база достаточно велика, раздача прав доступа превращается в рутинную работу.
Предлагаю для пользователей sql-запрос, который "перераспределит" права доступа пользователям таким образом, чтобы они видели только те записи, в которых являются ответственными.
Что нужно сделать:
1. Перед выполнением нижеуказанных действий настоятельно рекомендую сделать резервную копию Вашей базы данных во избежание нарушения работоспособности системы и потери данных! 
2. Запустите менеджер по управлению базой данных, в зависимости от используемой Вами СУБД (для SQL - например, Enterprise Manager). Выберите базу, на которой необходимо выполнить Sql-запрос. Откройте окно для нового запроса и вставьте запрос следующего содержания:

DELETE FROM tbl_AccountRight
INSERT INTO tbl_AccountRight (ID, RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
SELECT newid(), A.ID, AU.ID, 1, 1, 1, 1
FROM tbl_Account A
JOIN tbl_AdminUnit AU ON AU.UserContactID = A.[OwnerID]

3. Запустите на выполнение.
4. Данный запрос предназначен для раздачи прав доступа для раздела контрагентов. Вы также можете раздать аналогичные права доступа пользователям на записи путем замены в запросе tbl_Account на название соответствующей таблицы.
5. Затем необходимо запустить рабочее приложение Terrasoft CRM под пользователем с правами администратора. Зайти в раздел «Контакты», выбрать записи тех контактов, которые являются пользователями системы и добавить этих пользователей на закладку «Доступ» менеджера деталей. То есть раздать пользователям права доступа на записи контактов самих себя. Это делается с той целью, чтобы пользователь в поле «Ответственный» мог видеть запись себя.
6. Затем Вы можете зайти в приложение под обычным пользователем и протестировать работоспособность системы.

Желаю удачи!

С уважением,
Мельникова Екатерина

Поделиться

8 комментариев

Если уж делать что-то такое, то скрипт должен учитывать и права доступа по-умолчанию.

К тому же нужно отдавать себе отчет, что права доступа могут содержать какие угодно настройки, которые при таком подходе будут утрачены.

В том то и дело, что этот скрипт не учитывает прав доступа по умолчанию. Это учитывают другие скрипты http://community.terrasoft.ua/blogs/3277
Дело в том, что клиенты нередко обращаются с просьбой предоставить что-то подобное, поскольку регламенты работы в их компаниях предусматривают именно такой функционал.

Мельникова Екатерина

Если у клиента права доступа по-умолчанию настроены каким-то образом, то это, скорее всего, соответствует его регламентам.

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

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

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

Это вполне жизненная задача, также как и остальные требует решения.

Мельникова Екатерина

Так тогда начальник отдела не сможет посмотреть статистику по своим подчиненным.
То что поставили такую задачу, не означает что она имеет смысл :)

Так сделали бы отдельный раздел "База знаний". Ато вытаскивание оттуда кусков в блоги смотрится как-то странно.

"Underscore a.k.a. _" написал:Так тогда начальник отдела не сможет посмотреть статистику по своим подчиненным
Если он конечно не администратор.

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

Войдите или зарегистрируйтесь, чтобы комментировать