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

[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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[lev]

Цитата:

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

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

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

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

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

[Pustik]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[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.