Почему display/edit методы не поддерживают переход к основной таблице

[Maxim Gorbunov]

Цитата:

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

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

Решений может быть масса. Соберите данные во временную таблицу, например. Или добавьте свой собственный метод перехода к основной таблице. В любом случае, таких сложносочинённых форм по определению не может быть много. Я бы оценил в процентов 5 от общего количества (если у Вас их больше, имеет смысл задать себе вопрос, почему я так мало пользуюсь отчётами ). Ради такого количества править логику работы прав доступа, dynamic links, и т.д.... в общем, знаете, в этом конкретном случае я на стороне разработчиков из MS

Цитата:

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

С правами в АХ2009 гайки закручены мама не горюй. Мало того, что теперь проверяются лукапы, дак еще и при желании в коде можно закрыть доступ через соответствующее свойство таблицы. Не думаю, что в этом случае это сложнее.

Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?

[S.Kuskov]

Цитата:

Сообщение от Maxim Gorbunov

Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?

Согласен с тем, что ответственность за отображение/скрытие контролов нужно по максимому перекладывать на ядро системы. В случае display-метода, этого можно добиться, например, научив систему анализировать relation на расширенном типе данных у значения возвращаемого методом

[lev]

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

Ну конечно проверять на основе какого EDT (и вообще на его ли основе) создано поле в диалоге, и если у этого EDT есть Relation (ну или заполнено свойство HelpForm), то дать возможность перейти к основной таблице.

[Pustik]

Цитата:

Сообщение от Maxim Gorbunov

В любом случае, таких сложносочинённых форм по определению не может быть много.

Согласен . Я просто с ходу придумал пример, который показывает, что присоединение таблицы не всегда заменит display-метод.

Цитата:

Сообщение от Maxim Gorbunov

Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?

А чего тут думать-то у display-метода есть EDT, который он возвращает.У EDT relation.Определили таблицу.Смотрим свойство FormRef у соответствующей таблицы, если FormRef пустой тогда вот-так Работа с Lookup.Определили форму.Итак нашли и таблицу и форму - все нужные нам объекты. Дальше определяем права у этих объектов в таблице настройки прав стандартным образом. Думаю если найдены объекты с правами не должно быть проблем.

[Maxim Gorbunov]

Цитата:

Сообщение от S.Kuskov

Согласен с тем, что ответственность за отображение/скрытие контролов нужно по максимому перекладывать на ядро системы. В случае display-метода, этого можно добиться, например, научив систему анализировать relation на расширенном типе данных у значения возвращаемого методом

А теперь давайте вспомним, что вообще-то в системе права на primary key и права на foreign key - две разные вещи. То есть, например, если дать пользователю смотреть список заказов, но скрыть таблицу клиентов, поле Клиент в заказе можно оставить доступным. Если делать, как предлагаете Вы, то придётся либо отказаться от такого подхода, либо написать большой документ для администраторов, в котором перечислить, в каких случаях работает так, а в каких - иначе. Кстати, подумайте ещё о том, что тот, кто настраивает права, далеко не всегда (на моей практике так почти никогда) имеет представление о программировании в системе, и для него разница между dislpay-методом и полем в таблице весьма условна.

Цитата:

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

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

Ну конечно проверять на основе какого EDT (и вообще на его ли основе) создано поле в диалоге, и если у этого EDT есть Relation (ну или заполнено свойство HelpForm), то дать возможность перейти к основной таблице.

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

Цитата:

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

Согласен . Я просто с ходу придумал пример, который показывает, что присоединение таблицы не всегда заменит display-метод.

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

Цитата:

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

А чего тут думать-то у display-метода есть EDT, который он возвращает.У EDT relation.Определили таблицу.Смотрим свойство FormRef у соответствующей таблицы, если FormRef пустой тогда вот-так Работа с Lookup.Определили форму.Итак нашли и таблицу и форму - все нужные нам объекты. Дальше определяем права у этих объектов в таблице настройки прав стандартным образом. Думаю если найдены объекты с правами не должно быть проблем.

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

[lev]

Цитата:

Сообщение от Maxim Gorbunov

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

А какое обоснование ругани было (если не секрет) ?

[Pustik]

Цитата:

Сообщение от Maxim Gorbunov

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

За что Ваш консультант так не любит пользователей? Ведь удобно же

Цитата:

Сообщение от Maxim Gorbunov

Я Вам также сходу предложил, как это можно решить, не ломая ядра

А так ломается ядро пользователя..Здесь надо через "Перейти к основной таблице", а там по кнопочке справа в пункте меню.

Цитата:

Сообщение от Maxim Gorbunov

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

Дак ведь здесь речь-то идет о возможности "Перейти к основной таблице". Т.е. права на этот display-метод настроены уже изначально. И если пользователь видит этот метод значит права настроены так, что он должен видить этот метод. Остается проверить права как-раз на объекты, которые он может открыть через "Перейти к основной таблице". Или я что-то не понимаю. Поправьте если я не прав.

[Maxim Gorbunov]

Цитата:

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

А какое обоснование ругани было (если не секрет) ?

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

[Maxim Gorbunov]

Цитата:

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

А так ломается ядро пользователя..Здесь надо через "Перейти к основной таблице", а там по кнопочке справа в пункте меню.

Если очень надо (в чём у меня по-прежнему большие сомнения), можно и без кнопочки. Перекрывайте метод jumpRef() на контроле и программируйте, сколько хотите Я же не говорю, что так делать вообще никогда нельзя. Я лишь говорю, что это настолько специфическая задача, что решать её с помощью ядра - это overkill. Дайте разработчикам MS шанс поработать над более существенными проблемами

Цитата:

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

Дак ведь здесь речь-то идет о возможности "Перейти к основной таблице". Т.е. права на этот display-метод настроены уже изначально. И если пользователь видит этот метод значит права настроены так, что он должен видить этот метод. Остается проверить права как-раз на объекты, которые он может открыть через "Перейти к основной таблице". Или я что-то не понимаю. Поправьте если я не прав.

Не, мы про разные вещи говорим. Я говорю именно про доступ на тот самый контрол, который отображает значение display-метода. Как его спрятать отдельно от формы/таблицы, к которой он привязан?

[S.Kuskov]

Цитата:

Сообщение от Maxim Gorbunov

А теперь давайте вспомним, что вообще-то в системе права на primary key и права на foreign key - две разные вещи. То есть, например, если дать пользователю смотреть список заказов, но скрыть таблицу клиентов, поле Клиент в заказе можно оставить доступным.

Совершенно верно, но вводить код клиента прийдётся вручную без лукап-формы

Цитата:

Сообщение от Maxim Gorbunov

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

Согласен про анализ Relation на ExtendedDataType я возможно поторопился. Но анализ самих ExtendedDataType в теории может предоставить такой инструмент. Как вы считаете, ExtendedDataType гипотетически может выступать объектом-еденицей настройки прав доступа? На память не помню а проверить возможности сейчас нет. Есть ли у объекта ExtendedDataType свойство SecurityKey?

[Maxim Gorbunov]

Цитата:

Сообщение от S.Kuskov

Совершенно верно, но вводить код клиента прийдётся вручную без лукап-формы

А никто и не говорит, что этот пользователь создаёт новые заказы Может это кладовщик.

Цитата:

Сообщение от S.Kuskov

Как вы считаете, ExtendedDataType гипотетически может выступать объектом-еденицей настройки прав доступа?

Боюсь, что это только усложнит уже имеющуюся систему. Да и не очень понятно, как такую задачу решить в принципе. Например, EDT могут наследоваться. Как это будет поддерживаться системой настройки прав?

Цитата:

Сообщение от S.Kuskov

На память не помню а проверить возможности сейчас нет. Есть ли у объекта ExtendedDataType свойство SecurityKey?

Нет. Есть только ConfigurationKey.

[lev]

Цитата:

Сообщение от Maxim Gorbunov

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

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

По поводу "модальности" диалогового окна, вопрос спорный...
В системе диалог открывается не как модальная форма, и это хорошо! Ведь иногда, что бы заполнить поля диалога, нужно сходить в некоторые справочники, и уточнить какое же значение нужно выбрать. Если диалог будет модальным, то его надо будет в начале закрыть, потом уже ходить по справочникам, а вся информация которая уже была введена в диалоге потеряется и её надо будет вводить заново, что не есть хорошо (ведь на диалоге может быть с десяток полей, и вот заполнив 9 (15) полей ты понимаешь, что сейчас тебе надо закрыть окно, а потом заново 9-ть (15-ть) полей заполнить... уверен пользователь по этому поводу немного расстроился бы ).

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

[TasmanianDevil]

Мы пользуем дописанную функцию в классе Global - и для display/edit - методов, и для контролов, передавая в нее расширенный тип и значение

static void makeJump(int _typeId, Anytype _id)
{
    SysDictType     dictType;
    SysDictRelation typeRelation;
    TableId         relationTable;
    FieldId         relationField;
    SysDictTable    dictTable;
    Common          record;

    str             formRef;
    FormRun         fr;
    Args            args;

    ;

    dictType = new SysDictType(typeid2extendedTypeId(_typeId));

    if(dictType)
    {
        typeRelation = dictType.relationObject();

        relationTable = typeRelation.table();
        relationField = typeRelation.lineExternTableValue(1);

        if(relationTable != 0)
        {
            dictTable = new SysDictTable(relationTable);
            if(dictTable)
            {
                formRef = dictTable.formRef();
                if(formRef)
                {
                    record = dictTable.makeRecord();
                    select record where record.(relationField) == _id;

                    if(record)
                    {
                        args = new Args(formRef);
                        args.record(record);

                        fr = new FormRun(args);
                        fr.init();
                        fr.run();
                        fr.wait();
                    }
                    else
                        throw error(strfmt('Для таблицы %1 не найдено значение поля %2 равное "%3"', tableid2name(relationTable), fieldid2name(relationTable, relationField), _id));
                }
                else
                    throw error(strfmt('Таблица %1 не имеет определенной в АОТ формы отображения', tableid2name(relationTable)));
            }
            else
                throw error(strfmt('У расширенного типа %1 в АОТ указана в качестве связанной несуществующая таблица с кодом %2', dictType.name(), relationTable));
        }
        else
            throw error(strfmt('Расширенный тип %1 не имеет в АОТ указания на связанныую с ним таблицу', dictType.name()));
    }
    else
        throw error(strfmt('В системе отсуствует расширенный тип данных с кодом %1', _typeId));

}

[Link]

Все же обычно display\edit методы отображают неключевые данные, чаще расчетные. И привязать их наверняка просто невозможно. Но если нужно добавить переход к форме, то можно так:

Пример перехода к форме наменклатуры по значению из дисплейного метода.

public int showContextMenu(int _menuHandle) 
{ 
    Args                                args;
    FormRun                             formRun;
    
    int                                 goto;
    int                                 selection;
    
    PopupMenu                           popupMenu = PopupMenu::create(_menuHandle, this.hWnd());
; 
    popupMenu.insertBreak();

    goto        = popupMenu.insertItem("Go to form");
    selection   = popupMenu.draw(); 

    switch (selection) 
    { 
        case goto:
            args = new Args();
            args.name(formstr(InventTable));
            args.record(InventTable::find(this.valueStr()));

            formRun = classFactory.formRunClass(args);

            formRun.init();
            formRun.run();
            return 0;
        default:
            return selection;
    } 

    return selection;
}

[S.Kuskov]

Цитата:

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

Все же обычно display\edit методы отображают неключевые данные, чаще расчетные. И привязать их наверняка просто невозможно.

Уже обсуждалось на первой странице. В случае, когда данные не могут быть привязаны к какой-либо "основной таблице", то и расширенный тип даных для отображения/ввода таких данных логично использовать без relation'а. По поводу таких случаев вопросов нет. Вопрос, поднятый в этой теме, касается других случаев, когда для создания display/edit методов программист осознано выбирает расширенный тип данных связанный relation'ом с определённой "осовной таблицей". В таких случаях можно было бы и реализовать возможность перехода к основной таблице. И совсем не нужно анализировать содержащееся в контроле значение, для определения направления перехода. Направление перехода изначально предопределено relation'ом на ExtendedDataType.