В принципе до состояния "черновика" задачу решил, "сырое" выкладываю на всякий случай, может кому пригодится

// функция возвращает есть ли для данного типа (DocumentTypeID) поле с названием FieldName
function ExistFieldForDocumentType(DocumentTypeID, FieldName){ 
	var TypeDataset = GetDocumentTypesDatasetForUserField(FieldName);
	TypeDataset.GotoFirst();
	var Result = false;
	while (!TypeDataset.IsEOF){
		if (TypeDataset.Values('KeyValue') == DocumentTypeID){
			Result = true;
		}
		TypeDataset.GotoNext();
	}
        TypeDataset.Close();
	return Result;
}
 
// возвращает открытый memory dataset со списком ID типов, для которых используется данное поле
function GetDocumentTypesDatasetForUserField(ItemName){
    var SelectedUserFields = Services.GetNewItemByUSI('uf_Documents');	
	var dsUserFieldsTypes = Services.GetNewItemByUSI('mds_UserFieldsTypes');
	var TypeDBDataset = Services.GetNewItemByUSI('ds_DocumentType');
	dsUserFieldsTypes.Attributes('TypeDBDataset') = 
		TypeDBDataset;
	dsUserFieldsTypes.Attributes('SelectedItem') = 
		SelectedUserFields.Items.ItemsByName(ItemName);
	dsUserFieldsTypes.Attributes('UserFields') = 
		SelectedUserFields;
	dsUserFieldsTypes.Open();
	return dsUserFieldsTypes;
}

Дальше можно сделать функции универсальными - для любого набора UserFields (тут uf_Documents), для любого датасета критериев (тут ds_DocumentType)... но это уже не так интересно, тему можно считать закрытой:wink:

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

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

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

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

Пользователь, указанный на детали Контакты в данном справочнике, обладает всеми правами на детали Визы. Т.е. он может как давать визу так и удалять запись. Отдельной настройки прав для данной детали нет.

"Смоляков Станислав Игоревич" написал: Отдельной настройки прав для данной детали нет.

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

"Смоляков Станислав Игоревич" написал:

Права доступа на редактирование (в том числе и удаление Виз) настраиваются в справочнике "Типы Виз". Соответственно JavaScript будет иметь возможность отработать по удалению Виз только если пользователь под которым запускается данный скрипт (который вошел в систему и изменяет Статус Запроса на изменение) имеет соответствующие права в справочнике "Типы Виз".
Таким образом Вам необходимо настроить справочник "Тип Виз" по всем пользователям которые работают с изменением Статуса запросов на изменение. Но в этом случае эти же пользователи смогут на самой детали Визы вносить изменения. Вы можете отслеживать эти изменения используя деталь "Журнал изменений".

Станислав, извиняюсь, где именно устанавливать права на удаление/изменение виз для Запросов на изменение (tbl_ChangeRequestVises)? Искал и в "Файл-Справочники-Настройка справочников", и в "Файл-Справочники-Общие справочники-Типы виз", через администрирование "Права доступа к таблицам" - нигде не нашел этих настроек.

Вы правильно нашли: в справочнике "Файл-Справочники-Общие справочники-Типы виз". В верхнем уровне указывается название визы, а в нижнем - пользователи, которые будут обладать всеми правами по этой визе. Например, если Вы добавить к визе Бухгалтер пользователя Иванова, то Иванов сможет изменять состояние Визы, а также удалить эту запись с детали Визы. Если пользователя нет в этом справочнике, то он сможет только добавить визу (создать запись на детали Визы), но ничего не сможет с ней сделать.

"Смоляков Станислав Игоревич" написал:Например, если Вы добавить к визе Бухгалтер пользователя Иванова, то Иванов сможет изменять состояние Визы, а также удалить эту запись с детали Визы. Если пользователя нет в этом справочнике, то он сможет только добавить визу (создать запись на детали Визы), но ничего не сможет с ней сделать.

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

Нет, если для пользователя SYS также будет указана именная лицензия.

"Кулак Олег" написал:Нет, если для пользователя SYS также будет указана именная лицензия.

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

Более подробная информация Вам отправлена письменно по Вашему запросу в Службу технической поддержки.

все понятно большое спасибо

Все решил проблему! тема закрыта

Если нет необходимости, то убирайте перечисление у компонента:

    ecAllCommunication.Enum = System.EmptyValue;

В базовой конфигурации все enum'ы или же заполняются значениями, или же обнуляются через System.EmptyValue. Возьмите, например, глобальным поиском по конфигурации по строчке ".Enum"

спсб...

Алексей, что-то я не вижу почему вам не подходят права по умолчанию. Можете другой пример привести? :)

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

"просто Алексей" написал:а в правах по умолчанию будут добавлены обе группы

"просто Алексей" написал:все участники строго распределены между этими двумя группами

"Осауленко Александр" написал:
Это в том случае, когда создавший входит в обе группы. Вы уверены что

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

Вероятно вы некорректно задаете раздачу прав по умолчанию.
Принцип следующий:
- в разделе Администрирование выбираете вкладку "Права по умолчанию"
- слева выбираете группу (Группа А), участник которой будет создавать новый объект
- справа в списке разделов выбираете раздел (Контакты)
- справа внизу добавляете те группы, которым будут при этом выданы права (Группа А).

Аналогично настраиваете для группы Б. В итоге, если пользователь, создающий новый контакт, входит только в группу А, то и права будут выданы группе А.

"Валерий Андрусик" написал:Вероятно вы некорректно задаете раздачу прав по умолчанию.

Я думаю у Вас все получиться, у меня примерно такая же ситуация, я справляюсь следующим образом:
- В Права по умолчанию для группы А, на объект допустим Задачи, добавлена только Группа А и группа "Руководитель проекта".
Аналогично и для Группы Б.
Автор объекта - Задачи по умолчанию имеет доступ к этому Объекту. Автоматом добавляются права только для Ответственного(если он отличен от Автора). Во всех остальных случаях если это не настроено отдельно никто кроме автора объекта доступ к нему не имеет(как вариант группа "все пользователи", если так изначально настроено в Конфигурации)
В случае если есть необходимость пересечения по доступу, члены этих групп сами дают доступ к объекту на детали Доступ в Разделе.

Здравствуйте!
Web-пользователей необходимо добавлять в специальном разделе.Данный раздел появляется только после загрузки лицензий Terrasoft Service Desk Web User.
Также напомню, что у пользователя, от имени которого запускается web-форма (того, который прописан в web.config) обязательно должны быть именные лицензии Terrasoft Service Desk Web User и Terrasoft Service Desk Agent.

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

Не совсем так. Сами лицензии для web-пользователей - конкурентные. Таким образом пользователи могут быть созданы после заказа лицензий. Именные же лицензии Web User необходимы для управления конкурентными лицензиями для web-пользователей.

Спасибо прояснилось! а пользователя web-user я так понимаю надо просто создать отдельно, как обычно?(пользователь веб-формы) и web-пользователей затем уже создавать просто под обычным администраторским аккаунтом например supervisor -правильно?

Пользователей, которые будут непосредственно входить на web-форму, необходимо создавать в разделе [Web-пользователи]. Данный раздел будет доступен только тем пользователям, у которых есть именные лицензии Terrasoft Service Desk Web User. Т.е. если у пользователя supervisor будут именные лицензии Terrasoft Service Desk Web User и Terrasoft Service Desk Agent, то он сможет и создавать web-пользователей, и его же учетные данные можно прописать в файле web.config для запуска web-формы.

Вот сейчас все понятно ...Спасибо Влад!

Было такое, решали тем, что "замыкали" выходы со всех задач старого процесса на новый. Возможно вариации, но общая схема такая:
1) В новом процессе:
- добавляем параметр процесса OldActionName, тип строка, в нем будет передано название того элемента старого процесса, из которого попали в новый. Если процесс запускаем сам по себе - значение будет пусто.
- в начале ставим блок-условие, которое анализирует значение параметра OldActionName и переходит на соответствующую задачу.
2) В старом процессе:
- добавляем блок-подпроцесс с новым процессом
- после блоков-задач ставим блок-скрипт, который выставляет значение параметра OldActionName нового процесса, и собственно переходит на новый процесс.

Чтобы не превращать оба процесса в "паутину" связей :), можно сначала запросом к таблице tbl_WorkflowItem определить названия незавершенных элементов процессов, и настроить переходы только для них.

"Валерий Андрусик" написал:Возможно вариации, но общая схема такая

А что если изменять значения параметров в диаграмме и элементах уже запущенного БП, и сделать так, чтобы эти параметры указывали на следующий исполняемый элемент из нового БП, тогда не нужно будет 2 отдельных процесса (старый и новый), то есть внести изменения в таблицы tbl_Workflow и tbl_WorkflowItem?

Дело в том, что сама диаграмма хранится как сервис. В tbl_WorkflowItem мы видим только отработанные и текущие элементы процессов (будущих там нет). Ядро Террасофт создает следующую запись в tbl_WorkflowItem только при отработке текущей задачи, ориентирусь на схему процесса в tbl_Service.
Если я правильно понял, у вас на рабочей базе работает старый процесс, а на базе разработки вы расширили его же. Если при этом у вас в новой версии диаграммы сохранились все элементы старой, с теми же кодами, то думаю можно просто обновить сервис - при отработке элемента ядро найдет в новой диаграмме новые связи. А вот если изменения повлекли в том числе и удаление элементов или их переименование - тогда хуже. Я бы тогда советовал сделать новый процесс (с другим USI), и настроить переход на него. Может еще специалисты Террасофт посоветует что-то.

То есть, насколько я понимаю, ключевым является наличие последнего выполняемого элемента и не завершенного в новом БП? То есть оно должно его найти в новой схеме БП и дальше идти по схеме? Если оно этого элемента, на котором в старой схеме БП остановилось, не находит в новом, то тогда ошибка, иначе - все должно быть ок.

Очень интересненько... возьму на заметку.

Да, правильно

Действительно, Валерий правильно подсказал решение. Оно и довольно простое, но в то же время приводит к результату. Процессы при экспорте-импорте в xml файлах указаны только перечень элементов процесса. Элементы же хранятся в tbl_WorkflowItem и кто у них следующий узнают только после перехода в состояние "Выполнено", тогда в сервисе процесса ищется тот, который должен выполняться следующим. Поэтому предложенная "подмена" - это почти законный способ "перевести" элементы старого процесса на выполнение в рамках нового.

Каждый пользователь Terrasoft может менять свои пароли, перейдя в меню [Файл]->[Сервис]->[Смена пароля пользователя].
В случае если пользователь принадлежит группе(в разделе [Администрирование]), у которой указана частота смены пароля, то по истечению данного срока пользователю будет выдаваться сообщение о необходимости смены пароля. Также стоит обратить внимание, чтобы в карточке пользователя не была установлена галочка [Время действия пароля не ограничено]

Что касается Web-пользователей, функции смены паролей самим пользователем не предусмотрено.

Спасибо!

В Версии Terrasoft Service Desk 3.3.2.149 как я понимаю уже включена возможность добавления web-пользователей с домена по умолчанию и ничего дополнительно делать не нужно? Или опять нужно загружать сервисы?

???

Мы у себя управление частотой смены и сложности паролей (мы не используем пока доменную авторизацию)настроили на уровне БД (в нашем сл. Oracle 10).

Спасибо за ответ,Иван. А интересно как вы извещаете пользователей о том что их пароли поменялись?и как они узнают новые пароли?)

"Алекс Васильев Викторович" написал:

Спасибо Николай за ответ.Я уже выяснил это.Но для нас это не подходит, так как компьютеры находятся в домене Novell, а не MS.
У меня возник еще такой вопрос насчет создания веб пользователей:вот здесь вот http://www.community.terrasoft.com.ua/blogs/5401 веб-пользователи добавляются в специальном меню WEB-пользователи.Но у меня нету такого меню.И насколько я помню Web-пользователей нужно добавлять в меню Администрирование.Там же где обычных пользователей в формате xxxxxx@domain.com. Разве это не так???
спасибо!

Нет. web-пользователей может добавлять только пользователь Terrasoft с именной лицензией Web-User. Раздел управления web-пользователями [Web] вы найдете в группе меню [Сервис] и [Инструменты]

ХМ странно а вот здесь http://community.terrasoft.ua/forum/topic/6115 пишут по другому,что он появляется только после заливки других лицензий.)

Дословно лицензия именно так и называется Terrasoft Service Desk Web User

Сообщите, пожалуйста, воспроизводится ли данная ошибка под администратором?
Также сообщите, пожалуйста, версию бинарных файлов.

Если заходить на терминал под тем пользователем, то под любым пользователем не работало. Проблему уже решил, похоже просто права не сразу применились для пользователя!

Поздравляю! Всегда необходимо уделять внимание раздачи прав пользователям.