Binding признака обязательности поля на attributes > isRequired не работает корректно
Здравствуйте,
BPM 7.5 off-site. Нужно делать поля обязательными / отменять признак обязательности по условию. Поле лукапное, не эксперементировал с другими типами. Поле НЕ помечено как обязательнтое в базе. Вычитал на форуме, что это делается посредством атрибутов:
{
"isRequired":
{
"bindTo": "getUsrCustomerIsRequired"
}
},
Код функции:
{
var department = this.get("UsrDepartmentUsr");
var departmentEngineering = 'c7f45266-747b-47d3-9af1-63978f63f321';
var result = department && department.value === departmentEngineering;
return result;
},
Проблема - даже когда функция возвращает false, то тогда пропадают красненькие звёздочки, однако поле нельзя оставить пустым, оно ведёт себя как обязательное.
Вопросы:
1. Это баг?
2. Какие есть обходные решения, желательно, работающие? Правила?
UPDATE: Правила работают корректно. Однако, хотелось бы услышать и про биндинг на isRequired атрибута. Ведь если нужно будет более сложное условие, то атрибута будет мало...
Спасибо
-----
Lohika
Нравится
Добрый день!
Вы пытаетесь биндиться на поле, а необходимо на колонку в diff.
Нужно установить атрибут isRequired колонке в diff и забиндить на Ваше свойство.
"Вильшанский Дмитрий" написал:Добрый день!
Вы пытаетесь биндиться на поле, а необходимо на колонку в diff.
Нужно установить атрибут isRequired колонке в diff и забиндить на Ваше свойство.
Помнится, я уже делал так ранее, однако, всё что происходило - появлялся красненький текст и астерикс (валидация), однако поле НЕ становилось required, всмысле, можно было сохранить, даже тогда, когда всё красненькое и поле ПУСТОЕ )) Т.е. тут баг наоборот..
Я поискал на форуме, и нашел пост пользователя, который писал, что надо биндится на атрибут..
Попробую и отпишусь, но я почти уверен в своих словах..
Проверил, увы, я был прав :)
Вообщем, саммари:
1. С помощью правил работает (красный текст и нельзя сохранить пустое поле), однако, он не поможет, если сложная логика, нужна функция.
2. С помощью атрибута - пустое поле ВСЕГДА НЕЛЬЗЯ сохранить, даже если текст перестал быть красным.
3. С помощью биндинга на isRequired в diff - пустое поле ВСЕГДА МОЖНО сохранить, даже когда текст становится красный.
Вот такие пироги..
Может, я что то сделал неправильно, тогда, приведите, пожалуйста, работающй код подобного биндинга. Вот мой код
{ "operation": "insert", "name": "UsrCustomer", "values": { "layout": { "column": 0, "row": 5, "colSpan": 12, "rowSpan": 1 }, "bindTo": "UsrCustomer", "caption": { "bindTo": "Resources.Strings.UsrCustomerCaption" }, "textSize": 0, "contentType": 5, "labelConfig": { "visible": true /*, "isRequired": { "bindTo": "getUsrCustomerIsRequired" }*/ }, "enabled": { "bindTo": "getUsrCustomerEnabled" }, "isRequired": { "bindTo": "getUsrCustomerIsRequired" } }, "parentName": "Header", "propertyName": "items", "index": 11 },
Здравствуйте снова.
Вы не могли бы как то откомментировать предыдущий пост с анализом?
Например:
1. Здравствуйте, ведётся анализ разработчиками
2. Здравствуйте, я еще не читал ваше сообщение
3. Здравствуйте, у нас всё работает (но я не проверял)
4. Здравствуйте, я проверил, и у нас всё работает
5. Здр, вы правы, во всём, всегда :)
6. Здр. вы правы насчёт вариантов X и Y, но с Z мы вы неправильно сделали, нужно так..
7. Здравствуйте, есть 4й способ..
8. Ну и так далее
Просто холдер на холдере, бесплатные тестировщики :)
Спасибо!
Еще одна проблема. Я не только должен добавить / убрать признак обязательности, но еще и стереть значение (оно нерелеватно в данном случае). Добавляю / убираю признак isRequired я с помощью правила. Стираю значение я в функции вызываемой из attributes > dependencies, используя this.setColumnValue("ColumnName", null). Что происходит (подозреваю)? Я не могу контролировать порядок вызова методов. Сначала вызвается метод, стирающий значение, пр этом поле еще required, появляется индикация "Specify the value". После этого поле становится required, однако, индикация не пропадает. Сущность сохранить МОЖНО, однако, индикация сбивает пользователя с толку. Он может захотеть попытаться заполнить поле (хотя оно у меня еще и disabled делается).
Здравствуйте,
"Вильшанский Дмитрий" написал:Пришлите, пожалуйста, полный листинг кода.
Просьба странная, я вам описал 4 проблемы. Две из них различные НЕРАБОТАЮЩИЕ варианты сделать одно и тоже (required по условию). Было бы глупо в коде исползовать то, что не работает. 3-е решение (проблема) работает, именно его я и использовал в коде (используя правила). Проблема этого решения - раздутый синтаксис правил, слишком много кода, чтобы решить такую мелкую проблему, учитывая, что полей может быть много, и вся логика будет разбросана по rules, diff, attributes. 4-я проблема связана с использованием 3-его работающего решения + стиранием значения поля использую attributes > dependencies > this.setColumnValue("FieldName", null) - если поле, будучи required по условию, содержало значение, условие поменялось, и на false условия мы хотим сбросить значение используя attributes > dependencies > this.setColumnValue("FieldName", null), то остаётся надпись "Specify the value", при этом сущность можно сохранить, однако, эта надпись может озадачить пользователя, и он может совершить ненужные действия.
------
Я записал 4 видео, где воспроизвёл все 4 проблемы, показал также клиентский код из инспектора. Надеюсь, Вам это заменит "полный листинг кода".
1. Сценарий 1 - биндинг функции на diff > isRequied (ВСЕГДА МОЖНО сохранить пустое поле)
https://dl.dropboxusercontent.com/u/54624048/ShareX/2015/07/2015-07-11_…
2. Сценарий 2 - биндинг функции на attributes > isRequired (ВСЕГДА НЕЛЬЗЯ сохранить пустое поле)
https://dl.dropboxusercontent.com/u/54624048/ShareX/2015/07/2015-07-11_…
3. Сценарий 3 - использования rules - единственное рабочее решение. Кроме как в сочетании с
https://dl.dropboxusercontent.com/u/54624048/ShareX/2015/07/2015-07-11_…
4. Сценарий 4 - сценарий 3 + сброс значения поля - остаётся нерелватный validation message - "Specify the value"
https://dl.dropboxusercontent.com/u/54624048/ShareX/2015/07/2015-07-11_…
-----
Разбор полётов. Если я очень глупо где-то ошибся - очень сильно прощу прощения, и беру все свои слова обратно.
Я (разработчик, представляю компанию, ваших потенциальных Customers) создал тему на форуме, где указал, что определённый способ решения задачи не работает. Параллельно создал тикет на портале самообслуживания. Тикет быстро закрыли как дубликат на тему на форуме (???). Мне предложили другой вариант. Я ответил, что я уже пробовал тот другой, и он не работал, но так и быть, я перепроверю. Я перепроверил, и сказал, что я был прав, это способ нерабочий. Итого - поддержка дала мне неработающее решение. Возможно, я сделал что-то не так, однако мне не предоставили "правильный" листинг кода. Более того, я провёл анализ известным мне способов достичь желаемого, и достаточно подробно для человека "в теме" описал, что 2 из них откровенно НЕ РАБОТАЮТ, 1 работает (УРА!), однако, он очень громоздкий, особенное, если нужна проверка не НЕСКОЛЬКО условий одновременно.
Я ждал ответа, как соловей лета (в ловушке, как мотылёк в ванной). Ответа ждал почти 2 дня. Написал еще одно сообщение, где попросил поддержку сообщить о статусе. Тишина. Потом, начальство узнало об этом всём, возмутилось, почему закрыли тикет как дубликат на эту тему, и настоятельно попросило ПЕРЕОТКРЫТЬ тикет, что я и сделал. Возможно, еще какие-то рычаги применились. Тут же запустилась формальная процедура (подозреваю), на тикет ответили, и на форуме ответили - предоставьте полный листинг кода.
------------
Мои (наши, компании) ожидания были немного другими:
1. Информацию, которую мы предоставили, проанализируют. Даже в целях улучшения качества продукта, за что нам нужно сказать спасибо. Уже несколько серьёзных проблем было добавлено в Ваш бэклог, что должно Вас радовать, а вот ваших QA нет.
2. Ответственный QA попытается воспроизвести сценарии, отпишется по результатах, и по цепочке это приведёт к ответу.
3. В случае некомпетенции QA, вопрос будет передан разработчику, который сделает то же.
4. Не нужно будет "давить" переоткрытием тикета для реакции.
5. Поддержка даёт только те советы, в которых уверена. А не то, что она "думает", что работает, или работало раньше, или что "наверное работает.". Проверять свои заготовленные "copy-paste" шаблоны на актуальность и соответствие версии продукта.
-------
Ничего личного, отношусь ко всему с юмором, в рестроспективе :)
Спасибо
Используя бизнес правила и dependency на поле изменить поведение системы не получится, чтобы не отображать сообщение о валидации.
В карточке счета реализована асинхронная валидация полей "Контакт" и "Контрагент". Это может помочь.
В схеме InvoicePage2, в методах validateAccountOrContactFilling и asyncValidate реализована обязательность заполнения одного из полей - "Контакт", "Контрагент".
Физически поля не являются required, но они валидируются.
Прилагаю схему InvoicePage2
Уже 7.8.1, а установки обязательности через атрибуты до сих пор нет.
Игорь, здравствуйте!
Данную информацию передали в департамент разработки для рассмотрения возможной реализации в будущих версиях
"Коновалов Игорь" написал:Уже 7.8.1, а установки обязательности через атрибуты до сих пор нет.
Похоже, что в 7.10 тоже :cry:
С помощью валидатора можно выйти из положения в 7.11, если мастер бизнес-правил не подходит (потому, что при некоторых комбинациях условий на одно поле правило может не работать), но вообще печально :сry: https://academy.terrasoft.ru/documents/technic-sdk/7-11/dobavlenie-vali…
Также см. соседнее обсуждение.
А вообще, есть такая информация:
Это не ошибка.
Diff – отвечает за представление. И только. Никакой валидации View не делает.Этим занимается модель. Если атрибуту модели дописать свойство isRequired – тогда сработает валидация модели при сохранении.