Как вы проверяете, что пользователь - администратор?
Насколько я помню проблема с этим актуальна на локализованных проектах. Потому что кроме как по имени проверить других способов простых я не слышал (DeveloperName нет на Profile). А при смене локали пользователя у стандартных профилей имена тоже переводятся.
Я один раз столкнулся на одном проекте даааавно. Честно не помню как решили - или отказались от затеи или просто два варианта на разных языках проверяли.
Или использовать сеттингс с хардкодед ид или сделать клон профиля и использовать уже его.
А проверить есть ли у него ModifyAll permission?
Сегодня узнал что не профайлы нахрен не работают когда выполняется DML в Apex.
В каком смысле? У меня не разрешает вставить запись, если правов нет.
Это нужно сделать в пакете.
Языков может быть больше чем 2.
Была проверка на основе permission, но выяснилась еще пробблема с лицензиями и версиями оргов.
А проверить тип лицензии и тип орга можно из Apex?
Создаешь нового юзера в профайле выключаешь доступ к объекту на создание и делаешь кнопку которая инсертит этот объект все инсерт проходит, как мне объяснили код работает в особом режиме который не никогда не смотрит на профайлы.
Что за кнопку такую делаешь?
Скрин можешь приложить?
Не совсем понимаю зачем это. Но в пакете делается настройка и эта настройка сохраняется пользователем при установке или апдейте пакета.
Определенные действия может делать только админ, настройка в данном случае крайне не желательна.
Command button три строчки кода insert contact
Не знаю, я бы в этом случае не опирался на стандартные профили. Мало ли как клиенты будут их использовать. Может какому-то клиенту надо одному админу дать права, а другому не давать.
Я вы в этом случае лучше сделал PublicGroup специальную и давал бы в пакете права только на эту группу. Сорри не знаю какой оферхед будет в этом случае по настройкам, но точно лучшу и гибче и проверить проще. Добавить пользователя в эту группу и проконтролировать в 2 клика не так уж сложно.
Попробуй через Tooling API, SELECT Id, FullName, Metadata FROM Profile ORDER BY Name, но используй 34 API
может с другой стороны подойти к вопросу: а что делает профайл администраторским?
какие есть ключевые отличия между обычным профайлом и администраторским? можно ли эти отличия как-то "прошарить" программными средствами? может попробовать под этим юзером програмно выполнить какие-то действия, которые точно доступны только администратору и посмотреть результат?
Можно, например, добавить в Package Permission Set с именем Package Admin. А в коде уже проверять текущего пользователя на наличие этого Permission Set'а.
Это все понятно, но желание было проверить, что у юзера есть права как раз без участия юзера.
Задача решилась проверкой определенный стандартных пермишенов, но мне не очень нравится это решение.
Попробуй через Tooling API, SELECT Id, FullName, Metadata FROM Profile ORDER BY Name, но используй 34 API
А чем тебе это решение не понравилось ?
А что там имеено в 34 версии?
В этой версии ты можешь получить поле FullName для нескольких полей.
Хотя сейчас подумал что тебе это не важно.
Делай FullName='Admin' и можно использовать любую версию.
field 'FullName' can not be filtered in query call
Блин точно, поэтому и нужно API 34 для выборки всех профилей и потом в цикле поиска Amin профиля.
Проблема еще в том, что кастомные профили, созданные на основе админа, не всегда называют %Admin%.
Значит дай более четкое определение что для вас считается профилем Админа.
