Братцы, как знаете не хуже меня, есть такое v('ITEM_NAME') внутри вызываемого на странице PL/SQL, благодаря чему всегда понятно, на какой странице и в каком приложении работает конкретный код или каково значение Item на странице.
А вот есть ли у вас мысли, как организовать подобное понимание конкретно в Condition? Ведь у каждого item имеется уникальный код... Можно ли его получить в Condition?

Друзья, все ваши упрёки справедливы. Но должен заметить, что форумов, где нет возможности откорректировать своё собственное сообщение после постинга на форуме в Сети ещё поискать... Однако sql.ru мы любим не за это.

Итак, уточняю свой вопрос. Любой элемент в APEX имеет настройку Condition, суть которой в том, рендерить или нет данный элемент. В том случае, если тип этого Condition представляет из себя PL/SQL, возникает желание внутри этого кода установить "координаты" вызова данного кода, а именно, приложение, страницу и некий идентификатор, или имя хотя бы элемента, откуда код вызван при рендеренге. Что касается номера приложения и страницы, тут всё просто v('APP_ID') и v('APP_PAGE_ID'), а вот с элементом что-то никак...

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

Возникает желание объединить с одной стороны элементы интерфейса в группы, с другой пользователей в группы и сопоставить их друг другу в третьей табличке на предмет наличия запрета. После чего разместить вызов PL/SQL в Condition. Этот код без труда установит группу пользователя по идентификатору пользователя, хранящемуся в APP_USER.

Что можно сказать о группе элемента? Ничего, если PL/SQL не знает, как его идентифицировать.
Не знаю, слабая это связь или сильная, но пока мне ничего не пришло в голову кроме как передавать в этом вызове строку названия элемента, совпадающего с его именем. Выглядит не очень.

Друзья, очень благодарен вам за ваши размышления! sql.ru это просто сборище маньяков-профи! Даже и не думайте взломать мой смартфон при помощи вашего SQL!

#CURRENT_ITEM_NAME# это вообще откровение какое-то! Жаль, что не работает ((( APEX_APPLICATION.GET_COMPONENT только для APEX 4.

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

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

Поскольку речь идёт об аутентификации внутри веб-приложения, до оракла здесь как-то дотягиваться желания особого не возникает. Це ж апекс, зачем тут Оракл? APEX_PUBLIC_USER и все дела )))
Поясните, может я не понял мысль? Вы используете аутентификацию пользователей оракл для целей работы с апекс-приложением? То есть на сто клиентов набегает тысяча пользователей и всех вы их в Оракле заводите?

Кэш таблица имеется в виду опция CACHE для CREATE TABLE? Круто!

>>Когда программист слишком многое придумывает, возможно он не
>>сформулировал USE CASE? По ГОСТ'у?

В вашей терминологии я вряд ли являюсь программистом. Так, самоучка со стажем, вряд ли более.

>>Вот если бы решили не использовать механизм condition, тогда другой разговор.

Кроме authorization и condition других штатных способах прятать элементы не слыхал. Причём по ходу тут семантика сплошная, а суть одна. Просто в authorization не передать ничего вовсе, а в condition что-то можно.

регионы в апекс это стратегия Оракле). Которую вы игнорируете.

В не подумайте, я обеими руками за стратегии Оракла! Но если элементы не объединяются в регион, то, боюсь, ничего тут не поделать. Задачу как-то надо решать.

Пока вижу всё то же решение: передавать в condition название элемента и содержать три таблицы: группы элементов, пользователей и привилегий, объединяющих эти группы.

В таком случае, заходя на страничку с клиентами, бухгалтерия увидит своё, дизайнеры свой, а продаваны - своё. И да, наверное можно налепить кучу страниц (или даже приложений)на каждый отдел, а потом все их содержать. Но это совсем уж за пределами добра и зла.

есть такая путаница смешения понятий Видимость и Видимость по безопасности).
У меня критерий - бизнес логика. Это первое - видимость.
Безопасность делаю чисто по авторизации и правам (слово - НЕЛЬЗЯ).

Бухгалтеру нельзя удалять клиента, менеджеру можно.
менеджеру нельзя видеть колонку дебиторки, бухгалтеру можно.

Какая разница, безопасность это или видимость? Что решает данная терминология, если реализация в Апексе по сути отличается лишь семантически?

Petro123ещё не хватало туда передавать.
Вы и в Видимость зря передаёте.
По крайней мере оснований не видно.

Как же вы коллега решаете такие банальные задачи про менеджера и бухгалтера? Неужто без Condition (authorization)?

Хорошо поговорили, спасибо!
Буду чаще сюда заходить!

Совсем забыл сказать, тут еще такое дело. Приложение-то облачное, клиентов сотня. И кому одно спрятать, куму другое показать...
Здорово, наверное, спроектировать АРМ в количестве клиенты Х отделы и наслаждаться поддержкой этого всего.

Наслаждение, доступное только программистам.