31.10.2019, 14:09 | #1 |
Участник
|
Ax2012: внезапно отрабатывающий display method в лукапе
Добрый день.
Столкнулся с загадочной ситуацией. Есть кастомный лукап, написанный с помощью SysTableLookup, в нём есть два дисплейных поля. При запуске под админскими правами - работает отлично. При запуске под пользователем, лукап открывается, а в дисплейных полях пусто. Но если изменить сортировку или, скажем, попробовать отфильтровать значения в лукапе, дисплейный метод магическим образом отрабатывает. Кто-нибудь сталкивался с подобной ситуацией? ax 2012R3 CU13 |
|
01.11.2019, 05:41 | #2 |
Мрачный тип
|
Предлагаете лечить даже не по фото, а по описанию фото ?
Переопределенный лукап и дисплейные методы в студию ...
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
01.11.2019, 09:41 | #3 |
Участник
|
Встречались ситуации, когда ядро в целях оптимизации исключало из выборки поля которые явно не отображаются на гриде. Попробуйте в своём дисплейном методе работать не нпрямую с this, а перевыбрать запись из таблицы по уникальному ключу включающему те поля, которые вынесены в лукап.
|
|
01.11.2019, 09:59 | #4 |
Участник
|
Простите, привожу код:
Лукап: X++: public static void lookupSalesAgreementIdExecutant(FormControl _callingControl, CustAccount _custAccount, AgreementExecutant _executant) { Query query; QueryBuildDataSource qbds; SysTableLookup sysTableLookup = SysTableLookup::newParameters(tableNum(SalesAgreementHeader), _callingControl); sysTableLookup.addLookupfield(fieldNum(SalesAgreementHeader, DocumentTitle)); sysTableLookup.addLookupMethod(tableMethodStr(AgreementHeader, AgreementDate_RU)); sysTableLookup.addLookupMethod(tableMethodStr(SalesAgreementHeader, custNameAlias)); sysTableLookup.addLookupfield(fieldNum(SalesAgreementHeader, CustAccount)); sysTableLookup.addLookupfield(fieldNum(SalesAgreementHeader, Currency)); sysTableLookup.addLookupfield(fieldNum(SalesAgreementHeader, AgreementClassification)); sysTableLookup.addLookupfield(fieldNum(SalesAgreementHeader, SalesNumberSequence), true); query = AgreementHeader::partyAgreementsQuery(tableNum(SalesAgreementHeader), fieldNum(SalesAgreementHeader, CustAccount), _custAccount ? _custAccount : SysQuery::valueUnlimited(), systemDateGet(), false, 0, _executant ); qbds = query.dataSourceTable(tableNum(SalesAgreementHeader)); qbds.addSortField(fieldNum(SalesAgreementHeader, DocumentTitle)); qbds = query.dataSourceTable(tableNum(SalesAgreementHeader)); qbds = qbds.addDataSource(tableNum(SalesAgreementHeaderExt_RU)); qbds.relations(true); qbds.joinMode(JoinMode::ExistsJoin); sysTableLookup.parmQuery(query); sysTableLookup.parmUseLookupValue(false); sysTableLookup.performFormLookup(); } X++: //BP Deviation Documented public display CustName custNameAlias() { CustTable custTable; DirPartyTable partyTable; if (this.CustAccount) { select firstonly Party from custTable where custTable.AccountNum == this.CustAccount join NameAlias from partyTable where partyTable.RecId == custTable.Party; } return partyTable.NameAlias; } |
|
01.11.2019, 10:04 | #5 |
Участник
|
Цитата:
Сообщение от S.Kuskov
Встречались ситуации, когда ядро в целях оптимизации исключало из выборки поля которые явно не отображаются на гриде. Попробуйте в своём дисплейном методе работать не нпрямую с this, а перевыбрать запись из таблицы по уникальному ключу включающему те поля, которые вынесены в лукап.
|
|
01.11.2019, 12:28 | #6 |
Участник
|
RLS?
|
|
01.11.2019, 12:49 | #7 |
Участник
|
|
|
01.11.2019, 16:00 | #8 |
Участник
|
попробуйте указать skipAosValidation(true) в display методе
|
|
01.11.2019, 17:20 | #9 |
Участник
|
Тут RLS вряд ли влияет. Все таки выборка идет select, а не Query, а, насколько помню, select как раз по умолчанию без RLS и его для select наоборот нужно явно включать, если это нужно.
Есть подозрение, что как-то криво работает SysTableLookup с таблицами, которые в иерархии наследования. |
|
Теги |
lookup |
|
|