Denis Trunin's Blogs: Tool to filter in a query as a developer

[Blog bot]

Источник: https://denistrunin.com//xpptools-queryfieldsaotname/
==============

X++ tool that adds a system field name in a standard query filter field lookup

Источник: https://denistrunin.com//xpptools-queryfieldsaotname/

[wojzeh]

такую штуку бы ещё в Personalization-Add field добавить, а то никак не догадаешься, какое из 4 одинаковых полей твоё

[trud]

Ага, хорошая идея, добавил
https://github.com/TrudAX/XppTools#-...e-query-filter

[Logger]

Цитата:

Сообщение от wojzeh

такую штуку бы ещё в Personalization-Add field добавить, а то никак не догадаешься, какое из 4 одинаковых полей твоё

Ага.

А я еще делал такую настройку:
1. Выбор формата как показывать Xppname/Label или Label/Xppname. Как показывает практика, аналитикам удобнее смотреть когда первым значением идет метка. А программистам удобнее когда в начале идет X++ наименование. По ним же и сортировка идет.
2. Возможность игнорировать опцию AllowAdd для поля. Ее значение по дефолту - Restricted, что приводит к тому что если поле не выведено на форму то штатным средством его уже не выведешь. Так вот, иногда бывает полезно игнорировать значение Restricted и считать что можно добавить. Это делается одной строкой кода.

[sukhanchik]

Цитата:

Сообщение от Logger

Это делается одной строкой кода.

Это в 2012. В D365 так может и не получиться. Проект-то по D365.
Впрочем надо исследовать

[trud]

Цитата:

Сообщение от Logger

А я еще делал такую настройку:
1. Выбор формата как показывать Xppname/Label или Label/Xppname. Как показывает практика, аналитикам удобнее смотреть когда первым значением идет метка. А программистам удобнее когда в начале идет X++ наименование. По ним же и сортировка идет.

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

Цитата:

Сообщение от Logger

2. Возможность игнорировать опцию AllowAdd для поля. Ее значение по дефолту - Restricted, что приводит к тому что если поле не выведено на форму то штатным средством его уже не выведешь. Так вот, иногда бывает полезно игнорировать значение Restricted и считать что можно добавить. Это делается одной строкой кода.

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

[Logger]

Про синхронизацию не совсем понял.
Если вы про хранение опций в настроечной табличке, которую надо создавать при установке, то можно этого избежать. Чем-нить типа SysLastValue / pack / unpack.

[Logger]

Цитата:

Сообщение от trud

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

В 2012-й для добавления полей это
\Classes\SysSetupForm\fieldTreeAddFields

в нем

...
            switch (formDataObject.allowAdd())
            {
                case FormAllowAdd::Restricted:
...

подправить это место. Обрабатывать FormAllowAdd::Restricted так же как FormAllowAdd::Add

Возможно в 365-й это не сработает. Надо смотреть.

[trud]

Цитата:

Сообщение от Logger

В 2012-й для добавления полей это
\Classes\SysSetupForm\fieldTreeAddFields
Возможно в 365-й это не сработает. Надо смотреть.

В D365 нет такого класса, наверное и проблема ушла

[sukhanchik]

Цитата:

Сообщение от trud

В D365 нет такого класса, наверное и проблема ушла

Пока на примере формы групп клиентов я вижу, что можно добавить все поля, кроме системных и ссылочных (в частности, DefaultDimension)
Интересный момент, связанный с формой InventOnhandItem. В InventSum добавили поле InventIsExcludedFromInventoryValue, но форму после этого не восстановили. В результате в форму это поле добавить нельзя, но его и нет в списке полей датасорса.

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

Но все эти примеры неполноценные - на формы выведены по сути все поля таблицы.