Добрый день Андрей!!!

я предлагаю вам ничего не кодировать, а выполнить вашу задачу путем разграничения прав "по колонкам". Для выполнения данной задачи прошу ознакомиться с документацией по Администрированию и настройки прав. Ссылка на Академию террасофт: Раздел [Доступ к объектам] Прошу обратить внимание "Администрирование по колонкам", "Администрирование по записям". именно данный метод вам подойдет для решения вашей задачи. Будут вопросы пишите.

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

Тогда вам Андрей требуется доработка и переработка всей карточки редактирования. Но здесь возникает вопрос и определенная сложность. А если Задача (Активность) участвует в бизнес-процессе, тогда как вы будете использовать данную карточку? Ведь тогда Бизнес-процесс просто будет зависший. Это один момент. Второй момент во время исполнения Бизнес-процесса на карточки редактирования могут появляться Генерируемые поля. С ними что вы будите делать. Я думаю вы слишком замудреную поставили задачу. Ее решить можно но нужно будет предусмотреть все. А это переписать и заместить придется не только карточку редактирования Активности. Может вы как-то упростите задачу. И тогда я вам подскажу как правильно ее решить.

Игорь, здравствуйте!

"Ігор Андрусенко" написал:в який момент прописуються значення описаних полів ?

Значение интерфейсных полей изначально прописываются на клиентской части при помощи DataSource. Определение значений на сервере происходит, когда страница вернется с клиентской части.

"Ігор Андрусенко" написал:Куди потрібно прописувати логіку, яка спирається на вказані значення ?

Логику можно прописывать, например, на событиях изменений значений полей, на подготовку фильтров Lookup полей.
Не могли бы Вы описать логику применения значений полей и почему Вас не устраивает использование DataSource?
Спасибо

"y.perevjazko" написал:Не могли бы Вы описать логику применения значений полей и почему Вас не устраивает использование DataSource?

На карточці заявки на внесення змін є пара полів типу дата.
Значення дат розраховуються в методі SetDeadlineDate().

Якщо метод запускається з якого-небудь обробника, то значення в полях фіксуються, в разі якщо обробник відпрацьовує.

А якщо метод запускається в скрипті PageLoadCompleteScriptTaskExecute,
то значення залишаються не зафіксованими.

Я так розумію, що обробник відпрацьовує по AJAX і дає миттєвий результат, а результат відпрацювання по скрипту фіксується після ситуативного надсилання даних на сервер.

Тому зараз запитання я б сформулював наступним чином:
Як заставити здійснити відправку даних на сервер не через обробник зміни значення якогось поля, а в примусовому порядку, у скрипті PageLoadCompleteScriptTaskExecute ?

Сделайте методу булевский параметр, на PageLoadComplete запускаете SetDeadlineDate(true), из других мест — SetDeadlineDate(false). Внутри метода в зависимости от параметра пишите или в поле датасорса (на PageLoadComplete), или в контрол на карточке.

Дещо "косим" способом запускаю метод:
вставив метод SetDeadlineDate() у скрипт обробки повідомлення SetTaskOwnerButtonClick (натиснення кнопки "Установить Content-менеджера").
При натисненні кнопки метод відпрацьовує, візуально значення змінюється.

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

Page.DeadlineDateEdit.Value
Page.DataSource.ActiveRow.GetTypedColumnValue<DateTime>("DeadlineDate");

то отримую незмінене значення, не те, що в цей момент видно в полі карточки.
Вже коли вікно вибору менеджерів закриваю і потім повторно натискаю кнопку, тоді вичитується значення, яке було підставлене при попередньому натисненні-відпрацюванні SetDeadlineDate().

Це я вже з огляду на даний факт писав про AJAX.
Тому й питання щодо примусової відправки даних на сервер залишається актуальним, бо необхідність двічі розкривати вікно вибору Content-менеджерів навряд чи порадує виконавців.

Что это за окно выбора менеджеров? Оно открывается по кнопке? Как оно связано с полем?
Какой это продукт?

Так по кнопці відкривається вікно OwnerSelectionGridPage
З полем воно пов"язане таким чином:

UserConnection.SessionData["customDeadLine"] = Page.DeadlineDateEdit.Value;

Продукт: ServiceDesk
Я так розумію, що це додаткова розробка.

Але зважаючи на те, що при першому натисненні кнопки значення поля DeadlineDateEdit залишається неоновленим, то й у вікно передається неактуальне значення.
При другому - актуальне.

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

Рекомендуется всюду присваивать через

Page.DataSource.ActiveRow.SetColumnValue("DeadlineDate", DeadlineDate);

а не

Page.DeadlineDateEdit.Value = DeadlineDate;

Значення прописується ось так:

Page.DeadlineDateEdit.SetValue(deadlineDate);

Я так собі уявляю процес:
Значення прописується на боці клієнта, без відправки на сервер.
Тому не обновляється DataSource і, відповідно, зчитується не оновлене значення.
А при відкритті/закритті вікна по кнопці відбувається відправка даних, тому при наступному відпрацюванні SetDeadlineDate() показує, що значення вже оновлені.

А если заменить на Page.DataSource.ActiveRow.SetColumnValue ?

Здравствуйте, Игорь!
В таком случае, наверное лучше биндить параметр видимости на метод, который будет проводить необходимые вычисления и возвращать true или false. См. пример: http://www.community.terrasoft.ru/forum/topic/11983#comment-51919
У групп полей и деталей также есть свойство "visible".
Со вкладками сложнее - у них свойства "visible" нет, нужно либо добавлять css-свойство "display: none", либо динамически удалять/добавлять элементы коллекции "TabsCollection".

Нашел) только это 7.4.1

"Result": {
	"BindParameterEnabledResultToStatus": {
		"ruleType": BusinessRuleModule.enums.RuleType.BINDPARAMETER,
		"property": BusinessRuleModule.enums.Property.ENABLED,
		"conditions": [
			{
				"leftExpression": {
					"type": BusinessRuleModule.enums.ValueType.ATTRIBUTE,
					"attribute": "Status",
					"attributePath": "Finish"
				},
				"comparisonType": Terrasoft.ComparisonType.EQUAL,
				"rightExpression": {
					"type": BusinessRuleModule.enums.ValueType.CONSTANT,
					"value": true
				}
			}
		]
	},
	"BindParameterRequiredResultToStatus": {
		"ruleType": BusinessRuleModule.enums.RuleType.BINDPARAMETER,
		"property": BusinessRuleModule.enums.Property.REQUIRED,
		"logical": Terrasoft.LogicalOperatorType.AND,
		"conditions": [
			{
				"leftExpression": {
					"type": BusinessRuleModule.enums.ValueType.ATTRIBUTE,
					"attribute": "Status",
					"attributePath": "Finish"
				},
				"comparisonType": Terrasoft.ComparisonType.EQUAL,
				"rightExpression": {
					"type": BusinessRuleModule.enums.ValueType.CONSTANT,
					"value": true
				}
			},
			{
				"leftExpression": {
					"type": BusinessRuleModule.enums.ValueType.ATTRIBUTE,
					"attribute": "IsProcessMode"
				},
				"comparisonType": Terrasoft.ComparisonType.EQUAL,
				"rightExpression": {
					"type": BusinessRuleModule.enums.ValueType.CONSTANT,
					"value": true
				}
			}
		]
	}
}

чтобы правило работало на деталь или вкладку - вместо названия поля ("Result") пишите название детали

Спасибо, но в моём случае необходимы несколько
BusinessRuleModule.enums.Property.VISIBLE.
И к сожалению отрабатывает только последнее правило из массива.

так вы не несколько правил добавляйте, а несколько условий - как в правиле BindParameterRequiredResultToStatus

Я добавляю несколько правил BindParameterVisible, в которых в свою очередь в массиве conditions указываю по несколько условий.

вы добавляете несколько правил на одно свойство и ожидаете, что они как-то вместе будут работать?:exclaim: Даже если они как-то по очереди отработают, свойство-то одно и примет только одно, последнее значение

Вот это, к сожалению, и есть проблема, хотя при применении нескольких правил фильтрации поля, они вместе прекрасно отрабатывают. Придётся отказаться от использования rules и обратить свой взор на свойство visible. Спасибо за оказанное внимание

почему вы не можете сливать ваши несколько правил в одно с большим conditions?

Т.к. в каждом из правил есть по несколько condition'ов, объединённых
logical: Terrasoft.LogicalOperatorType.AND. Два параметра "logical" в одном правиле не применить. А в разных правилах присутствует условия, которые строятся на разных значениях одного поля + другое условие.

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

да проще тогда методом)

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

А можно при скрытии как-то перемещать поля по сетке?
Скрыть, а нижние поднять програмно?

Нельза, т.к. расположение элементов в карточке задается статически

Да, "режет глаз" - это еще ладно. Просто, и так поля в bpm'online занимают много места на экране (зачастую нецелесообразно), а тут еще пустые места.

Надо в "Идеи" писать, наверное

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

Добрый день!

Огромное спасибо за пожелание к системе!
Мы обязательно его учтем для реализации в будущих версиях системы.

Разобрался, ошибка была в функции TaskEditOnPrepare, просто строки надо было поменять местами :lol:

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

function edtTest2OnKeyUp(Control, Key, Shift) {
if (Key.Value == 40)
{
MessageBox(Key.Value);
 
Self.FocusedControl =  edtTest1;
}
else
{
MessageBox(Key.Value);
Self.FocusedControl =  NumericEdit;
}

Здравствуйте, Вениамин.

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

Инна Безверхняя,
II линия службы поддержки Terrasoft

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

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

- Detail
Здесь хранятся все сервисы, связанные с деталями раздела
- Dictionaries
Здесь хранятся все сервисы, связанные со справочниками раздела
- General
Здесь находятся сервисы, которые отвечают за отображения основного реестра записей раздела
- Graphs - графики
- Library - библиотека специфичных для этого раздела сервисов
- Reports - различные сервисы, связанные с отчетами FastReport
- User Fields - сервисы, связанные с пользовательскими полями

После того, как вы нашли сервис нужной вам таблицы, открываете этот сервис и слева вы увидите список полей таблицы:

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

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

Здравствуйте, Андрей!
Спасибо за Ваш ответ, да, в целом все верно.

Вениамин, хотелось бы еще добавить, что помимо того, что структура сервисов в TS Admin довольно однотипна для всех разделов, структура таблиц в самой БД также довольно прозрачна и, если можно так сказать, интуитивно понятна.

То есть, для каждого раздела есть основная таблица, на примере раздела "Контрагенты" - tbl_Account, далее, вся связанная информация, которая заносится через детали этого раздела хранится в таблицах, которые начинаются с названия раздела + название детали, то есть tbl_AccountAddressess - адреса контрагентов, tbl_AccountCommunications - средства связи контрагентов и т.д., аналогично справочная информация по данному разделу tbl_AccountType - типы контрагентов и т.д.
По тому же принципу хранится информация о группах записей и правах доступа к записям: tbl_AccountGroup и tbl_AccountRight.

По такому принципу хранится информация из всех разделов со всеми соответствующими связями.
Ну и, конечно, служебные таблицы, такие как, например, tbl_DatabaseInfo, в которой Вы можете посмотреть информацию о версии базы, кешировании сервисов и прочее.

Это в общих чертах, подробнее будем рады ответить на более конкретные вопросы.

Инна Безверхняя,
II линия службы поддержки Terrasoft

Инна, отличное дополнение! Картинка постепенно прорисовывается. Спасибо :)

Вениамин, для более углубленного анализа (уже для этапа программирования конфигурации) могу порекоммендовать SDK, в котором Вы сможете найти описание свойств и методов для используемых в системе интерфейсов.

А вот по какому принципу хранится информация в табличке tbl_Service ? Особенно блоб "XMLData".
В каком виде хранятся тексты "сервисов" ? Ну точно не в виде чистого XML.

Здравствуйте Сергей,
При записи в таблицу tbl_Service, сам сарвис сериализируется, подробнее вы можете почитать в теме http://www.community.terrasoft.ru/forum/topic/6829

"Яворский Алексей" написал:
При записи в таблицу tbl_Service, сам сарвис сериализируется, подробнее вы можете почитать в теме http://www.community.terrasoft.ru/forum/topic/6829

Насколько я понял из приведённого топика - XML-сериализация производится при выгрузке сервиса (модуля) в текстовый файл. При загрузке - XML-десериализация. А вот на стадии записи в БД выполняется маршалинг (сохранение всего объекта, включая программу, данные и метаданные). Попросту вся область памяти объекта (сервиса) выгружается в BLOB. Или я ошибаюсь?

Вопрос простой - как просмотреть/отредактировать модуль (сервис) во внешнем приложении имея доступ к БД? IBExpert воспринимает обсуждаемый BLOB как двоичный (это естественно при неизвестной структуре).

Здравствуйте Сергей,

Для редактирование сервиса из БД необходимо:
1.Получить значение BLOB-поля
2.Разархировать его – получится XML сервиса
3.Редактировать текст XML
4.Заархивировать
5.Записать заархивированный XML в то же поле

Но редактирование XML на прямую может повлечь ошибки. Если сервис неправильно отредактирован и записан в БД, он станет недоступным для редактирования в TSAdmin и для использования в TSClient, т.к. он не сможет правильно дисериализироваться.

Для решения Вашей задачи лучше работать с сервисами через COM-объекты Terrasoft из любого внешнего приложения:
1.Например, запросить сервис sq_Contact (Services.GetNewItemByUSI)
2.Модифицировать его как угодно, добавлять колонки, фильтры, union’ы и т.д. – это минимизирует ошибки, т.к. COM-объекты Terraosft делают проверку возможности тех или иных изменений. А работа напрямую с текстом XML ничего не проверяет
3.И после модификаций сохранить Services.SaveItem(Service, sdoaSave) в БД