В разделе есть несколько типов страницы редактирования. Как установить условия на видимость кнопки добавления для одного из типов? В каком модуле определены данные кнопки? Заранее спасибо!

Изображение удалено.

Нравится

11 комментариев
Лучший ответ

В diff схемы реестра раздела добавляем 

{

            "operation": "merge",

            "name": "SeparateModeAddRecordButton",

            "parentName": "SeparateModeActionButtonsLeftContainer",

            "propertyName": "items",

            "values": {

                "itemType": Terrasoft.ViewItemType.BUTTON,

                "style": Terrasoft.controls.ButtonEnums.style.GREEN,

                "caption": {"bindTo": "AddRecordButtonCaption"},

                "click": false,

                "visible": {"bindTo": "IsAddRecordButtonVisible"},

                "classes": {

                    "textClass": ["actions-button-margin-right"],

                    "wrapperClass": ["actions-button-margin-right"]

                },

                "controlConfig": {

                    "menu": {

                        "items": {

                            "bindTo": "EditPages",

                            "bindConfig": {

                                "converter": function(editPages) {

                                    if (editPages.getCount() === 0) {

                                        return null;

                                    }

                                    var operationHash = {

                                        "38d26ca1-ab6a-474c-950d-f9ac9b630967": "CanAbilityToAdd1", //здесь guid это id справочника по которому определяется страница редактирования

                                        "2495b17d-2465-41cb-b625-ac36d9aef931": "CanAbilityToAdd2"

                                    };

                                    

                                    var allowedPages = [];

                                    

                                    if (this.get("CanAbilityToAdd1")) {

                                        allowedPages.push("CanAbilityToAdd1");

                                    }

                                    

                                    if (this.get("CanAbilityToAdd2")) {

                                        allowedPages.push("CanAbilityToAdd2");

                                    }

                                    for (var key in operationHash) {

                                        var hashItem = departmentToOperationHash[key];

                                        if (allowedPages.indexOf(hashItem) === -1) {

                                            editPages.collection.remove(editPages.collection.getByKey(key));

                                        }

                                    }

                                    return editPages;

                                }

                            }

                        }

                    }

                }

            }

        }

}

 

В init добавляем к примеру проверку на доступ по операции, либо другую функциональность

initCanAbilityToAdd1: function() {

                RightUtilities.checkCanExecuteOperation({

                    operation: "CanAbilityToAdd1"

                }, function(result) {

                    this.set("CanAbilityToAdd1", result);

                }, this);

            },

Добрый вечер.

Кнопки для добавления разных типов записей генерируются автоматически в зависимости от информации в таблице SysModuleEdit и поля TypeColumnValue в этой таблице.

Названия пунктов меню для разных страниц редактирования берутся из поля ActionKindCaption.

Более подробную информацию посмотрите в этом посте.

Пользовательскими настройками (без внесения дополнительных изменений в программный код) настроить видимость пункта меню в кнопке [Добавить] этого сделать не получится.

Базовая логика добавления пунктов меню для кнопки [Добавить] раздела реализована в схеме 'BaseDataView' пакета NUI.

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

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

Зверев Александр,

Не уверенна, что разграничение прав доступа, как-то повлияет на видимость пункта меню кнопки [Добавить] для этого типа.

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

В diff схемы реестра раздела добавляем 

{

            "operation": "merge",

            "name": "SeparateModeAddRecordButton",

            "parentName": "SeparateModeActionButtonsLeftContainer",

            "propertyName": "items",

            "values": {

                "itemType": Terrasoft.ViewItemType.BUTTON,

                "style": Terrasoft.controls.ButtonEnums.style.GREEN,

                "caption": {"bindTo": "AddRecordButtonCaption"},

                "click": false,

                "visible": {"bindTo": "IsAddRecordButtonVisible"},

                "classes": {

                    "textClass": ["actions-button-margin-right"],

                    "wrapperClass": ["actions-button-margin-right"]

                },

                "controlConfig": {

                    "menu": {

                        "items": {

                            "bindTo": "EditPages",

                            "bindConfig": {

                                "converter": function(editPages) {

                                    if (editPages.getCount() === 0) {

                                        return null;

                                    }

                                    var operationHash = {

                                        "38d26ca1-ab6a-474c-950d-f9ac9b630967": "CanAbilityToAdd1", //здесь guid это id справочника по которому определяется страница редактирования

                                        "2495b17d-2465-41cb-b625-ac36d9aef931": "CanAbilityToAdd2"

                                    };

                                    

                                    var allowedPages = [];

                                    

                                    if (this.get("CanAbilityToAdd1")) {

                                        allowedPages.push("CanAbilityToAdd1");

                                    }

                                    

                                    if (this.get("CanAbilityToAdd2")) {

                                        allowedPages.push("CanAbilityToAdd2");

                                    }

                                    for (var key in operationHash) {

                                        var hashItem = departmentToOperationHash[key];

                                        if (allowedPages.indexOf(hashItem) === -1) {

                                            editPages.collection.remove(editPages.collection.getByKey(key));

                                        }

                                    }

                                    return editPages;

                                }

                            }

                        }

                    }

                }

            }

        }

}

 

В init добавляем к примеру проверку на доступ по операции, либо другую функциональность

initCanAbilityToAdd1: function() {

                RightUtilities.checkCanExecuteOperation({

                    operation: "CanAbilityToAdd1"

                }, function(result) {

                    this.set("CanAbilityToAdd1", result);

                }, this);

            },

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

 

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

Полозюков Евгений Петрович,

 пытаюсь сделать что-то подобное, все проверила 10 раз, но отладчик выдает:

Uncaught (in promise) TypeError: RightUtilities.checkCanExecuteOperation is not a function

А Вы добавили в начале в квадратных скобках и параметрах ссылку на RightUtilities? Посмотреть, как это сделано, можно в других схемах, где её используют:

define("SysOperationAuditSectionV2", ["BaseFiltersGenerateModule", "SysOperationAudit", "SysOperationAuditArch",
	"RightUtilities"],
function(BaseFiltersGenerateModule, SysOperationAudit, SysOperationAuditArch, RightUtilities) {
	return {

 

Зверев Александр, да, была проблема с последовательностью схем и параметров, передаваемых в схему)

Алла Савельева,

 

Спасибо, что подсказали на тему замещения BaseDataView. Натолкнули на верный путь!

Если кому то поможет, вот проверка на доступ к просмотру указанного типа страницы. Очень коряво, но я учусь и это работает)

define("ActivitySectionV2", ["ConfigurationConstants","RightUtilities","ProcessModuleUtilities","BaseDataView"],
function(ConfigurationConstants,RightUtilities,ProcessModuleUtilities) {
	return {
		entitySchemaName: "Activity",
		details: /**SCHEMA_DETAILS*/{}/**SCHEMA_DETAILS*/,
		attributes: 
		{ 
			"UsrCanManageItTask": {
				dataValueType: this.Terrasoft.DataValueType.BOOLEAN,
				type: this.Terrasoft.ViewModelColumnType.VIRTUAL_COLUMN,
				value: false
			}
		},
		diff: /**SCHEMA_DIFF*/[
 
			]/**SCHEMA_DIFF*/,
		methods: {
			init: function()
			{
					this.getUserSettingsOperationRight();
					window.console.log("Инициализация");
					this.callParent(arguments);
					window.console.log("Права");
 
			},
 
			initEditPages: function() {
				window.console.log("Определение кнопок начало");
 
				var enabledEditPages = new this.Terrasoft.Collection();
 
					this.callParent(arguments);
					var editPages = this.get("EditPages");
 
					window.console.log("Получение страниц");
					var flag = this.get("UsrCanManageItTask");
					this.Terrasoft.each(editPages.getItems(), function(item) {
						window.console.log("Проверка типа");
						window.console.log(item.get("Id"));
						//window.console.log(ConfigurationConstants.Activity.Type.Email);ConfigurationConstants.Activity.Type.Call
						if (item.get("Id") !== "e2831dec-cfc0-df11-b00f-001d60e938c6" &&
							item.get("Id") !== "e1831dec-cfc0-df11-b00f-001d60e938c6") {
 
							if (item.get("Id") !== "f5921924-3e81-4a5f-ae4c-5a6f1b6e7661")
							{
								enabledEditPages.add(item);
								//window.console.log("ок");
							}
							else { 
								if (flag)
								{
										enabledEditPages.add(item);
										//window.console.log("ок");
								}
							}
						}
					});
					window.console.log("Проверка типа конец");
					this.set("EnabledEditPages", enabledEditPages);
 
					window.console.log("Определение кнопок конец");
			},
 
			getFilters: function() {
						window.console.log("Добавление фильтра");
						var filters = this.callParent(arguments);
						if (!this.get("UsrCanManageItTask"))
						{
							filters.add("NotItTask", this.Terrasoft.createColumnFilterWithParameter(
							this.Terrasoft.ComparisonType.NOT_EQUAL, "Type", "f5921924-3e81-4a5f-ae4c-5a6f1b6e7661"
							));
							window.console.log("Добавление фильтра");
						}
						return filters;
			},
 
			getUserSettingsOperationRight: function() {
				//debugger;
				var operationsToRequest = ["UsrCanManageItTask"];
				//operationsToRequest.push("UsrCanManageItTask");
				window.console.log("Права");
 
				RightUtilities.checkCanExecuteOperations(operationsToRequest, function(result) {
					if (result) {
						this.set("UsrCanManageItTask", result.UsrCanManageItTask);
						window.console.log("Права на ит-задачи: "+result.UsrCanManageItTask);
					}
				}, this);
			}
		}
 
	};
});

 

Показать все комментарии

Добрый день!

Подскажите как перейти в другой раздел по нажатию кнопки на клиентской стороне, например в раздел итоги или обращения

 

Видел вариант с переход по вкладкам

this.setActiveTab("имя_вкладки");

Нравится

2 комментария
Лучший ответ

Вешаете на кнопку обработчик. А в него что-то вроде этого: 

var tag = "SectionModuleV2/ActivitySectionV2/";
this.sandbox.publish("PushHistoryState", {hash: tag});

ActivitySectionV2 - реестр раздела Активности

Вешаете на кнопку обработчик. А в него что-то вроде этого: 

var tag = "SectionModuleV2/ActivitySectionV2/";
this.sandbox.publish("PushHistoryState", {hash: tag});

ActivitySectionV2 - реестр раздела Активности

Дмитрий А.,

Спасибо, попробую

Показать все комментарии

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

Изображение удалено.

Есть раздел, в котором есть поле, принимающее значения из этого справочника (UsrYesNo), а также ряд других полей, содержащих значения INTEGER (UsrIntValue), TEXT (UsrTextValue) и т.п.



Есть необходимость извлечь значение соответствующего поля в коде клиентской части. Примерно так:

 

// Возвращает целочиcленное значение, работает корректно
var a = this.get("UsrIntValue");
// Возвращает строковое значение, работает тоже корректно
var b = this.get("UsrTextValue");
// По идее, должно возвращать значение из справочника, выбранное для записи раздела.
// Но по факту выдает undefined.
var c = this.get("UsrYesNo.Name");

Что я делаю не так?

Нравится

4 комментария
Лучший ответ

Генин Юрий пишет:

var c = this.get("UsrYesNo").Name;

Да, верно. Мы берём поле и читаем его атрибуты. 

Указать эту колонку в attributes

attributes: {
     "UsrYesNo": {
          "dataValueType": Terrasoft.DataValueType.LOOKUP,
          "lookupListConfig": {
               "columns": ["Name"]
            }
      }
 }

Или в данном случае достаточно взять this.get("UsrYesNo").displayValue

Владимир Соколов,

Вариант с this.get("UsrYesNo").displayValue сработал, спасибо. Но добавление атрибута (в схему страницы редактирования) ничего не поменяло:  this.get("UsrYesNo.Name") все равно возвращает undefined. 

Владимир Соколов,

А вот так, кстати, сработало:

attributes: {
     "UsrYesNo": {          
          lookupListConfig: {
               columns: ["Name"]
            }
      }
 }

и

var c = this.get("UsrYesNo").Name;

Интересно, почему...

Генин Юрий пишет:

var c = this.get("UsrYesNo").Name;

Да, верно. Мы берём поле и читаем его атрибуты. 

Показать все комментарии

Доброго времени суток!

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

Нравится

3 комментария
Лучший ответ

Добрый день!

 

На клиентской части в карточке редактирования Вы можете переопределить метод BasePageV2#onSaved

onSaved: function() {
	this.callParent(arguments);
},

Обратите внимание, если Вам нужно производить какие-то манипуляции с данными (пересчеты/обновления в других объектах и т.д.), то лучше использовать подход сигналов/событий объекта, тк при обработке на клиенте обрабатываться будет только "ручной" ввод, а во время импортов/интеграций/БП это логика останется "за бортом"

Добрый день!

 

На клиентской части в карточке редактирования Вы можете переопределить метод BasePageV2#onSaved

onSaved: function() {
	this.callParent(arguments);
},

Обратите внимание, если Вам нужно производить какие-то манипуляции с данными (пересчеты/обновления в других объектах и т.д.), то лучше использовать подход сигналов/событий объекта, тк при обработке на клиенте обрабатываться будет только "ручной" ввод, а во время импортов/интеграций/БП это логика останется "за бортом"

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

Лопатин Константин, Благодарю за совет! 

Показать все комментарии

Коллеги, доброго времени суток!



Есть необходимость вывести дополнительную информацию в виде колонки реестра раздела для каждой записи.

 

Кейс: 

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

 

Изображение удалено.

Необходимо, чтобы контакты отображались даже когда строка неактивна, то есть также, как данные других колонок (всегда).

Обычным способом такую колонку добавить не получается.

Изображение удалено.

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

Заранее спасибо за помощь!

 

Нравится

6 комментариев
Лучший ответ

Дмитрий, причина отсутствия колонок в изначальном вопросе в том, что в раздел можно выводить с детали только обобщённые значения: количество, сумму, среднее, минимум, максимум.

Дмитрий Анисько пишет:

то на мой взгляд проще добавить строковое поле в объект Контрагент и обновлять его на все нужные события для поддержания актуальности данных.

Лучше всего именно так. На уровне встроенного БП объекта детали или отдельным БП заполнять новое текстовое поле в объекте раздела. Можно ещё триггером в базе, но это Вам не подойдёт.

Дмитрий Анисько пишет:

Может быть Вы знаете, как можно добавить колонку в реестр именно на этапе формирования вью-модели?

 Даже если такое возможно, рисков больше, чем преимуществ. От большей нагрузки на сервер и базу, когда для каждой видимой в реестре строки будет отдельный запрос, до неполной функциональности, когда такая колонка не будет полноценно работать в выгрузке в Excel, итогах, печатных формах, OData и прочих интеграциях.

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

 

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

Вариантов решения такой задачи несколько, например:

1. Добавляем view с 2 колонками - Guid и string. Средствами sql формируем запрос, который в первую колонку будет возвращать Id контрагента, во вторую все "склеенные" в одну строку имена относящихся к нему контактов

2. В контрагенте добавляем колонку-справочник на нашу view (не забываем про галочку контроля целосности)

3. На событии OnInserting контрагента копируем значение колонки Id в колонку из п.2

4. Дальше пользуемся базовой настройкой колонок

 

Манипуляции из пп. 2-3 нужны для того, чтобы сохранить прямую связь

Лопатин Константин,



Большое спасибо за ответ, но указанный способ не подходит.

Нужно сохранить поддержку всех 3-х субд, а создавать View для каждой - не очень удобно. Да и если идти подобным путем, то на мой взгляд проще добавить строковое поле в объект Контрагент и обновлять его на все нужные события для поддержания актуальности данных.

 

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

 

Дмитрий, причина отсутствия колонок в изначальном вопросе в том, что в раздел можно выводить с детали только обобщённые значения: количество, сумму, среднее, минимум, максимум.

Дмитрий Анисько пишет:

то на мой взгляд проще добавить строковое поле в объект Контрагент и обновлять его на все нужные события для поддержания актуальности данных.

Лучше всего именно так. На уровне встроенного БП объекта детали или отдельным БП заполнять новое текстовое поле в объекте раздела. Можно ещё триггером в базе, но это Вам не подойдёт.

Дмитрий Анисько пишет:

Может быть Вы знаете, как можно добавить колонку в реестр именно на этапе формирования вью-модели?

 Даже если такое возможно, рисков больше, чем преимуществ. От большей нагрузки на сервер и базу, когда для каждой видимой в реестре строки будет отдельный запрос, до неполной функциональности, когда такая колонка не будет полноценно работать в выгрузке в Excel, итогах, печатных формах, OData и прочих интеграциях.

Коллеги, большое спасибо за ответы.

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

Дмитрий Анисько пишет:

Коллеги, большое спасибо за ответы.

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

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

 

Нужно сохранить поддержку всех 3-х субд, а создавать View для каждой - не очень удобно

Тоже не вижу особой проблемы с учетом того, что синтаксис аналогичный.

Лопатин Константин пишет:

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

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

Показать все комментарии

Коллеги, добрый день. 

 

Не могу найти информацию о том, как настроить права доступа на вкладки "Обращение". 

Требуется "забрать" возможноть видеть вкладки у части агентов, после определённого события. 

Нравится

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

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

 

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

 

Ну и программное скрытие вкладок не спасёт от сильно хитрых пользователей, которые могут и подправить код на стороне браузера. Надёжнее забрать права на колонки или на таблицы деталей.

Зверев Александр,

Зачастую не требуется настолько секьюрного подхода.

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

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

Показать все комментарии

Подскажите как забиндить настройку страниц в разделе? Это я так вижу таблица и должна отдельно от настройки раздела быть, но не как не найду ее. При сохранение настроек (нажатие "Сохранить" в настройках раздела) нужные данные не сохраняются в пакет, и при установке его на другую среду таблица со списком есть но вторая колонка (справа) пустая, данные не сохраняются в ней

Изображение удалено.

Нравится

11 комментариев
Лучший ответ

Александр Тыра,

1. Уточните, пожалуйста, версию bpm'online, в которой Вы выполняете настройки?

2. Я правильно понимаю, что при создании нескольких страниц редактирования, через мастер разделов, не выполняется автоматическая привязка данных об этих страницах в таблицу SysModuleEdit?

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

У нас был похожий опыт переноса дополнительных страниц редактирования для стандартных разделов году в 2018. На сколько я помню, все кастомные разделы с несколькими страницами редактирования переносятся нормально, а для стандартных разделов нужно выполнить это не привязкой данных, а SQL скриптом на целевой среде после переноса. Я попробую поискать вариант скрипта в архивах. Если найду - вышлю вам.



 

Нашел.

Необходимо добавить связь в таблицу SysModuleEdit. Детальнее можно почитать здесь. Нам помогло.

 https://community.terrasoft.ru/questions/rucnaa-registracia-razdela

Сидоров Александр Валерьевич,

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

Александр Тыра,

1. Уточните, пожалуйста, версию bpm'online, в которой Вы выполняете настройки?

2. Я правильно понимаю, что при создании нескольких страниц редактирования, через мастер разделов, не выполняется автоматическая привязка данных об этих страницах в таблицу SysModuleEdit?

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

Александр Тыра пишет:

не могу найти колонку что отвечает за справочник (таблицу в которой значения на основе которых разные страницы прописываются)

В таблице SysModuleEntity колонка TypeColumnUId.

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

Алла Савельева,

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

Алла Савельева,

Колонка TypeColumnUId заполнена у страниц, проверил на корректность. Но справочник (выделенное поле) не заполнен, и потому думаю не происходит установка значений из пакета (связка видимо не дает)

Алла Савельева,

Думаю это оно и есть, просто уже перенес данные и думаю потому не вижу разницы, но вот думаю это оно. Спасибо большое

Александр Тыра,

Интересно, исправлено ли это в последней актуальной на текущий момент версии 7.15.4?

Алла, с версии 7.14.3 заведена проблема «Перенос пакетов. При переносе пакетами раздела с несколькими страницами редактирования настройка типизированных страниц не переносится - используемые значения справочников не переносятся пока для колонки  TypeColumnValue не установить признак Force Update», она ещё не решена.

Зверев Александр,

Решил попробовать то что Вы процетировали, и после того как указал принудительное обновление колонок все перенеслось.

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

Показать все комментарии

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

Есть необходимость создать новый раздел на основании объекта активности.

Проведённые работы:

1. Создана схема Раздела и Страницы редактирования

2. Создана запись в SysModuleEntity с указанием UId объекта Активности

3. Создана запись в SysModule с указанием SysModuleEntityId из п.2 и UId схем из п.1.

4. Создана запись в SysModuleEdit с указанием SysModuleEntityId из п.2

В итоге раздел зарегистрирован и  работает корректно.

Но теперь при открытии мастера раздела в р. Активности открывается конфигурация  нового раздела (хотя в адресной строке указан SysModuleId раздела активности)

Есть подозрение, что Мастер раздела берёт последнюю запись (по дате создания) из таблицы SysModuleEntity.

Подскажите как решить эту проблему.

И правильно ли это поведение системы?

Нравится

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

Добрый день.

 

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

 

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

Спасибо, Алла. Этот вариант тоже рассматривал.

Но хотелось бы получить комментарий от Тех.поддержки.

Т.к. лично мне не понятно, почему для формирования наполнения мастера раздела не используются данные из SysModuleEntity?  

Ведь по логике не должно быть разницы какая схема объекта привязана к записи SysModuleEntity, если для каждого раздела есть своя запись в SysModuleEntity.

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



К сожалению, пользовательской возможности разделить записи одного объекта на два раздела нет в коробочной версии приложения.



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

Для этого Вы можете использовать базовое поле "Тип" в карточке контрагента. Добавить собственный тип Вы можете в справочнике "Типы контрагента".

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

 

Для интересующего Вас раздела активностей это уже сделано, для задачи и звонка используется одна карточка, а для email настроена другая.



Разделять записи в реестре раздела можно с помощью динамических групп настроив фильтр по полю "Тип".  

 

Если Вы нашли альтернативные варианты реализации желаемой функциональности, и дело только в неверном определении такого раздела в мастере, то можно сначала полностью настроить первый раздел, затем создать и настроить второй, а мелкие правки в объект и карточки раздела вносить вручную правкой схем. Либо на время разработки модифицировать найденные Вами записи в системных таблицах.

Мотков Илья,

Илья меня интересует именно отдельный раздел и с полностью рабочей функциональностью.

И мне интересно почему мастер раздела не основывается при  построении на данные из SysModuleEntity?

Т.к. именно эта таблица связывает зарегистрированный раздел (SysModule) с объектом(SysSchema).

Так почему при загрузке мастер основывается на объект и на последний  зарегистрированный по этому объекту раздел?

 

Игорь, здравствуйте, Вам удалось решить проблему? Если да, не подскажите каким образом?

Показать все комментарии

Так получилось, что был создан объект и деталь, а потом выяснилось, что нужен и полноценный раздел. Раздел был создан скриптами по инструкции, однако, в нем отсутствуют группы и оно понятно.

Вопрос - достаточно ли будет создать ОбъектFoder и ОбъектInFolder, чтобы всё заработало?

Нравится

4 комментария
Лучший ответ

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

Хотя может быть в Вашей версии тегов ещё не было frown

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

Хотя может быть в Вашей версии тегов ещё не было frown

Теги были ещё в 7.7, а скорее всего, и до того.

Алла Савельева,

В общем, да, создал 2 объекта и всё получилось

Алексей-Карягин,

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

Показать все комментарии

Хочу отловить двойной клик по записи в разделе.

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

Вопрос как?

Нравится

3 комментария
Лучший ответ

Добрый день. В 7.13 или 7.13.1 это есть уже в коробке. Можете посмотреть, как реализовано там. Работает и в разделах, и в деталях.

 

Проверьте метод onGridDoubleClick, возможно это то, что вам нужно

Пример работы с этим методом есть на детали «Пользователи» раздела «Организационные роли». По двойному клику открывается карточка пользователя. Логика реализована в схеме UsersDetailV2.

Добрый день. В 7.13 или 7.13.1 это есть уже в коробке. Можете посмотреть, как реализовано там. Работает и в разделах, и в деталях.

 

Показать все комментарии