this.getSelectedRecords();

Id ТЕКУЩЕЙ карточки (из которой был открыт lookup)

С замещением модуля не всё просто.

Возможно, как-то можно получать Id записи из стека прошлых открытых страниц системы, с которым работают при помощи GetHistoryState, ReplaceHistoryState и PushHistoryState.

Вам нужно в карточке редактирования переопределить метод save. Например:

            save: function() {

              // Здесь будет вызов нужных Вам методов  

              this.callParent(arguments);

            }

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

Автоматическое заполнение можно реализовать либо в бизнес-правиле фильтрации, либо через свойства атрибута dependencies.

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

Можно сделать всю логику во встроенном БП объекта, на событии Saving (до момента сохранения) или на Saved (после). Например, вторым способом формируют номер по порядку в некоторых разделах.

А в чем тогда отличие save от onSaved ?

Это разные вещи, функция на клиенте на JS и на сервере на C#.

То что это разные вещи и так понятно. Вопрос в чем конкретно отличие?!

Соломонов Алексей Михайлович,

save - это метод, который вызывает обработчик onSaved события save.

Вот кусок кода из BasePage:

            /**

             * @inheritdoc Terrasoft.BaseEntityPage#save

             * @override

             */

            save: function(config) {

                this.callParent([function() {

                    this.Terrasoft.chain(this.saveDetailsInChain, function() {

                        this.onSaved(this.cardSaveResponse, config);

                        this.cardSaveResponse = null;

                        delete this.cardSaveResponse;

                    }, this);

                }, this]);

            },

Нужно просто настроить запрещающий доступ по колонкам.

Так же вы на уровне можете скрыть поле на уроне Entity (будет существовать в БД, невозможно будет создать колонку с таким же именем и тд), но тогда обращение к нему стандартными методами будет затруднено. Для этого необходимо изменить режим использования 

Запрещающий доступ не подходит, поскольку администрировать нужно по каждой записи отдельно. Сценарий - индивидуальный менеджер видит все по своему контрагенту, любой менеджер - только часть. Может, есть где-то нормальная документация по sdk с комментариями чуть полнее, чем Overloaded :) ?

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

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

Так доработку мы и ведем, сейчас наткнулись на то, что вычитать "запрещенные" колонки можем, но скрыть их - нет, поскольку в схеме и сущности разные нотации, а гарантированно сопоставить одни с другими не можем.

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

Так мы пока и сделали, но это явный костыль, не ясно, как отработает колонка, у которой Id уже присутствует в названии. Поэтому и ищем более чистое решение.

Если у справочной колонки уже есть «Id» как часть названия, то в базе будет, соответственно, «IdId». Но лучше таких названий избегать.

Исправить первый пост не могу, там не <имя>Value, а <имя>Name, что впрочем не принципиально. Принципиально, что о гглупости, или незнанию, или умышленно созданная колонка ContactName не будет отличаться от Contact.Name, а потом такую ошибку черта лысого найдешь.

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

Спасибо, мы все это смотрели, но мы делаем более-менее generic решение, с тем, чтобы оно работало без дополнительных ограничений и не только в момент сдачи, поэтому варианты посмотреть, перечислить явно и т.п. никак не подходят. Нужна или аутентичная процедура получения одного из другого (или хотя бы документированное API, по которому не приходится догадываться, что имеется в виду), или официальній документ о требованиях к именованию, или (что хуже всего) авторитетное утверждение, что єти колонки каждій именует как Бог на душу положит и задача не решается в принципе.

Требования к именованию публиковались ещё во времена 3.Х.

Если Вы делаете универсальный механизм выдачи прав, можно делать подобно уже существующим: права для колонок хранятся в таблице SysEntitySchemaColumnRight. Там указывается не название, а именно Id колонки.

Мы так и делаем, правда там хранятся не Id, а UId, и я пытаюсь от имеющихся UId перейти к columnName, которые можно передать в Entity.SetColumnValue. Думал, что нашел, но см. первый пост этой ветки.

Поскольку на https://community.terrasoft.ru/questions/spisok-ne-administriruemyh-kol… никто не отвечает по сути вопроса, я просто пробую другой подход, основная часть задачи решена, а то, что казалось очевидным при беглом взгляде на имеющийся API, оказалось проблемой.

Обычно имена в базе и схеме совпадают, отличие только для справочных. Можно проверять, справочник ли это и затем добавлять или удалять «Id».

Также можно получить в виде JSON метаданные объекта и анализировать их: для каждой  справочной колонки там в соответствующих полях есть тройка названий: для поля-объекта, поля с Guid и поля для отображения. Например, "Type", "TypeId" и "TypeName".

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

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

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

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

вот, да, но копипастить не хочется. Может кто из разрабов ответит?

Если стандартными средствами настроить правила не получится, можно делать кодом, привязав им всем «isRequired» к логике какой-либо функции. Например, такой код есть в EmailTemplateUserTaskPropertiesPage.

Могу предложить "элегантный костыль":

string contact = "846d8d33-004b-4a3e-b778-10cfd163f3bb";

string result = String.Join(String.Empty, "{", contact.ToUpper(), "}");

Если используете механизмы EntityShchemaQuery или Select/Insert/Update/Delete, то ничего преобразовывать не нужно, в функции передаётся переменная типа Guid и при генерации SQL в нужном формате подставится само. Если же самостоятельно создаёте SQL, воспользуйтесь своим кодом или советом выше.

Эелегантность костыля в виде сокращения записи обращения к переменной иррелевантна задаче :)

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

Причина в том, что основная поддерживаемая база  — MS SQL, где есть тип «uniqueidentifier» и база поймёт вставку в любом формате. А поддержка Oracle добавлена опционально.

В этом и была суть вопроса: если в Oracle используется просто текст, какая разница, что туда писать? Зачем эти скобочки? Чтобы что-то в базе посмотреть, скопировать Id из URL не получится, это минус. Как и при склеивании ESQ и Select. А плюсы вообще есть?

Этот текст, хоть и не является отдельным типом «uniqueidentifier», но служит в качестве первичного или внешнего ключа. Соответственно, если писать в двух полях один GUID разным способом, связи между ними не получится.

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

В каких 2-х полях??? Почему не писать ОДНИМ способом, в нижнем регистре и без скобок? Везде.

В версии для MS SQL пишите как вам нужно, а в Oracle — именно требуемым способом.

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

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

Дмитрий, оно и приведено к единому знаменателю — с фигурными скобками в верхнем регистре. Нет смысла в версиях с 3.0 по 7.13 использовать один формат, а потом внезапно менять просто потому, что не нравятся скобки.

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

При обычной работе с форматом написания не сталкиваются никак, все C#-классы принимают значения типа Guid и преобразуют в нужный формат при генерации SQL автоматически. В чём именно негативное влияние фигурных скобок, Вы так и не объяснили. 

Вероятно, первоисточник именно такого написания — стандартная функция CreateGuid в Delphi, на котором была написана система Terrasoft 3.X. Она генерирует именно в таком формате. И в таблицу базы Firebird и Oracle, где нет встроенных типов для хранения GUID, так и записывали.

В Microsoft для C# рекомендуют для получения нужного формата использовать для переменной типа Guid метод ToString("N") в сочетании с String.ToUpper.

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

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

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

Выполнять прямой запрос к БД или через Microsoft Management Studio если у вас On-Site или через SQL Script в Админки BPM'Online. Нужна помощь в написании SQL скрипта пишите поможем.

а средствами BPM?

В С#-коде можно сформировать и запустить Update-запрос. Пример запроса:

Query update = new Update(UserConnection, "SysEntitySchemaRecordDefRight")
	.Set("AuthorSysAdminUnitId", Column.Parameter(authorId))
	.Where("Id").IsEqual(Column.Parameter(RedactedRecordId));
update.Execute();

В Вашем случае будет ещё и без условия Where.

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

Данная конструкция на C# может не сработать, так как ключевые входные данные это 1 миллион записей. Есть вероятность что по Таймауту ошибка выйдет.

Здесь лучше чтобы Автор поста описал свои знания и от этого лучше отталкиваться чтобы дать совет.

Если много записей, можно порциями, where Id in select top 1000 Id from...

1000000 это не записи, а значение в колонку... Знаний на уровня С# нету....(( Хотелось бизнес-процессом...

В  БП есть элемент «Изменить данные», который делает примерно то же.  Возможно, медленнее, за счёт отрабатывания событий сохранения по каждой записи.

Зверев Александр, этим элементом можно только значения из справочника передать, а у меня дробное число((

Числовые тоже можно.

Колосов Алексей,

Если Вам нужно это выполнить единоразово, то проще всего cделать, действительно, sql-запросом вида:

update Account

set Field1 = value

where IsNull(Field1, 0) = 0

где Field1 - это название Вашего поля, value - его значение.

А выполнить этот запрос можно либо предложенным в первом комментарии способом, либо установив бесплатное расширение SQL Executor.

Спасибо, разобрался... наверное - понедельник был)))

Вы в справочное поле вставляет "Пустой объект", поэтому в вашем случае с точки зрения валидатора поле заполнено.

Делайте так: 

this.set("UsrDealerAccount", null);

Литвинко Павел,Там потом ошибки в консоли валятся

Алексей-Карягин пишет:

Литвинко Павел,Там потом ошибки в консоли валятся

В каком случае и какие ошибки? 

Литвинко Павел,

у меня фильтрация этого поля правилом, когда туда плюхаешь нул, он ругается на этот нул.

Алексей-Карягин пишет:

Попробуйте тогда, вместо null использовать  Terrasoft.GUID_EMPTY может поможет

Литвинко Павел,

к сожалению, нет

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

Я делаю так: 

1) у кнопки сохранить bind меняю на другую функцию (пр. onBeforeSave)

2) в onBeforeSave реализую логику, а дальше вызываю/не вызываю save-метод

Также можно в save зашить проверку какого-либо параметра. Сохранять arguments, проверять параметр, если false-> вызывать свою функцию, в конце своей функции параметр = true и вызвать save с  сохр. аргументами. Тоже в принципе вариант

Добрый день, нужно либо смотреть в сторону asyncValidate (пример есть в DocumentPageV2), либо переопределить Save.

save: function(config,flag) {
    if (flag) {
        this.callParent(arguments);
    } else {
        //Validation Block
        Terrasoft.chain(
            this.checkPhonesCount,
            function (callback, scope) {
                this.save(config||{}, true),
                    callback.call(scope || this);
            },
            this
        );
    }
 
},
/**
 * Проверка количества телефонов
 * */
checkPhonesCount: function (callback, scope) {
    var leadId = this.get("Id");
    var esq = this.Ext.create("Terrasoft.EntitySchemaQuery", {
        rootSchemaName: "UsrLeadPhone"
    });
    esq.addAggregationSchemaColumn("Id", Terrasoft.AggregationType.COUNT, "Count");
 
    esq.filters.addItem(Terrasoft.createColumnFilterWithParameter(
        Terrasoft.ComparisonType.EQUAL, "UsrLead", leadId));
    esq.filters.addItem(Terrasoft.createColumnFilterWithParameter(
        Terrasoft.ComparisonType.NOT_EQUAL, "UsrPhone", ""));
    esq.filters.addItem(Terrasoft.createColumnIsNotNullFilter("UsrPhone"));
    esq.getEntityCollection(function (response) {
        if (response && response.success) {
            var collection = response.collection;
            if (collection && collection.getCount() > 0) {
                var count = collection.getByIndex(0).get("Count");
                if (count >= 1) {
                    callback.call(scope || this);
                    return;
                }
            }
            var msg = this.get("Resources.Strings.PhonesErrorMessage");
            msg = this.Ext.String.format(msg, 1);
            Terrasoft.showInformation(msg);
        }
    }, this);
},

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

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

1. Если не вчитываться в смысл задачи, а только подсказать как сделать желаемое то вот этот способ:

save: function() {
   ...
   var args = arguments;
   var parentMethod = this.getParentMethod();
   ....
   esq.GetEntity(function() {
       parentMethod.apply(this, args)
   }, this);
}

2. По смыслу же задачи, вам нужно делать валидацию, а не переопределять методы сохранения. посмотрите примеры в коде с использованием методов addColumnValidator, validate, asyncValidate. 

addColumnValidator, validate делают синхронные проверки. asyncValidate асинхронная валидация, используется когда нужно сделать например запрос в БД для проверки.

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