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