Всем привет.
Ситуация из жизни: как только БА начинают "раскладывать" функционал приложения по определенным профайлам, начинаются бесконечные хождения ко мне с ВФ страницами, которые не показывают какое поле или инфу.
в подавляющем большинстве случаем - это не настроенные у профайла FLS, но БА не всегда согласны, когда я им так отвечаю.
если у вас есть примеры кода для быстрой проверки наличия у профайла или юзера доступа к определённому объекту и полю,
поделить пожалуйста,
буду его запускать в консоли и показывать им результат...
Есть у меня такой код. Но назвать его простым я врядли смогу. Используется матадата API и вытягивается инфа из профиля о FLS и CRUD.
Когда-то на AppExchange видел приложение специально для этого - для быстрой настройки grud+fls для профилей с удобным интерфейсов. Не помню уже как называется. Поищи, 100% есть уже готовые решения и я думаю даже бесплатные.
Кода нет, но идея конкретно под эту задачу есть - быстрый и не сложный способ это сделать - через System.runAs в тесте. Отсюда и решение - иметь в dummy test'е такой код, который будет выполняться под нужным профилем/ролью/пользователем и используя обычные object describe и field describe отвечать на вопросы - есть ли доступ к полю, какой доступ и т.д. Что-то в духе:
@istest private static securityCheck
{
@istest private static void checkField()
{
String targetSObject = 'Account';
String targetField = 'Name';
User targetUser;
//code to setup proper user with proper profile, role, etc.
System.runAs(targetUser)
{
Schema.DescribeFieldResult fieldDescription = Schema.getGlobalDescribe()
.get(targetSObject)
.getDescribe()
.fields.getMap()
.get(targetField)
.getDescribe();System.debug(System.LoggingLevel.ERROR, 'Report for ' + targetSObject + '.' + targetField + ':\n'
+ 'Accessible: ' + fieldDescription.isAccessible() + '\n'
+ 'Filterable: ' + fieldDescription.isFilterable() + '\n'
...);
}
}
}
А запускать этот удобнее всего будет например из Eclipse, даже без предварительного деплоймента на сервер - локально подправили классик, локально сохранили, выбрали Run Tests -> profit!
Идея кстати отличная. И можно с успехом применять для разного рода проверок.
А вот если нужно что-то исправить придется использавать другой подход.
Можно просто через Describe без теста
В данном случае нельзя.
думаю, это то что и надо. но не попробовал еще. как БА опять прибегут - попробую
Обязательно отпишись потом - работает или нет 
Да, просто через дискрайб вне теста спокойно работает, будет возвращать доступность поля в контексте текущего пользователя.
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_fields_describe.htm
Думаю тут все или большинство, во всяком случае я уверен что автор так точно, знают как работает интроспекция для SObject'ов и их полей, только вне теста есть одно "маленькое" но - контекст текущего пользователя. Так что получится что человек спрашивает "Доктор, а у Сидорова анализы нормальные?", а вы ему отвечаете "Не знаю, зато знаю что у Петрова холестерин в порядке!"
Код также витиева-то пишешь? ;-)
Если уж нужно селектить под кем запускать, то действительно спасет метадата апи.
Дабы упростить задачу, можно воспользоваться враппером от FF: https://github.com/financialforcedev/apex-mdapi
Вот интересно получается - человек пришел с проблемой/задачей, 10 дней конкретного ничего не предлагали, а когда рабочее решение предложено, вдруг кто-то умный предлагает поклеить обои через замочную скважину. Во-первых - предложенный мной подход прост, элегантен и работает, во-вторых - практически полностью дан код решения, в-третьих - мало того что решение с metadata api надо ещё реализовать, для этой конкретной задачи оно будет не то что не спасением, а даже и близко по простоте и эффективности не приблизится к варианту с System.runAs, в четвёртых - если вы не согласны, я заплачу вам 100 долларов если к понедельнику вы напишите решение на metadata api, но с одним условием - если ваше решение будет не способно дать ответ, тогда когда моё решение его даст - 100 долларов с вас.
Ээээм..
Что же тебя так задело-то? Разве мы не на форуме, дабы обсуждать разные опции?
RunAs может быть очень оправдан для решения очень узкой задачи "Запустить скрипт в консоли - показать БА".
Если же именно брать вопрос "Как проверить полномочия определенного пользователя к определенному полю", то запуск тестов ни разу не вариант и обсуждать его как бы не стоит.
Кстати, тесты прогоняются на сервере, как предлагается запускать "локально сохраненный классик" без деплоя?
Я вполне конкретно описал что меня задело. Что касается обсуждения - я за конструктивный диалог, есть что сказать по делу и конкретное - пишу, если не знаю что сказать - молчу, если уже всё сказали и добавить нечего - тоже молчу. Предложенный подход как раз и решает конкретную поставленную задачу, хотя я бы сказал что он покрывает целый класс подобных задач, но да он не решает проблему питьевой воды в Ботсване и проблему малярии в долине реки Конго. Даже если говорить о задаче "Как проверить полномочия определенного пользователя к определенному полю" и её он решает тоже, и ещё какой это вариант - понадобится в разы если не на порядок меньше кода чтобы реализовать подход который будет динамически создавать маленький тестовый классик, который или через assert или через System.debug будет выводить в лог ответ на поставленную задачу, исполнять его на сервере и парсить результат. В том контексте где будет доступно metadata api, в том же контексте будет доступно выполнение этого кода.
Что касается
Вы бы хоть проверяли перед тем как писать... Что по вашему происходит когда вы выделяете в Eclipse файл или список файлов и выбираете Force.com -> Run Tests? На сервер летит список из имён файлов тесты из которых надо запустить? Берётся локальное содержимое этих классов, тот самый "локально сохранённый классик", всё metadata api на память не знаю, но готов поспорить что там есть что-то в духе executeTests, и вот это самое содержимое запихивается в этот метод и отсылается на сервер для выполнения, "без деплоя". Не верите - проверьте.
Ну и последнее - если вы так уверены что ваш вариант подходит, почему не возьметесь реализовать его, я же вам даже заплатить за это предложил?
Ну ладно, самое последнее - мне чисто интересно, как в условиях тотальных лимитов форса, используя metadata api, не используя подход с System.runAs, ваш код будет отвечать на вопрос "А есть ли у John Doe доступ на чтение к полю А?" при том что помимо профиля на John Doe навешано ещё 100 permission set'ов? Удачи в парсинге циклопического кол-ва XML.
PS: если мой комментарий по-поводу "вдруг кто-то умный предлагает поклеить обои через замочную скважину", вас задел - извиняюсь, просто на форуме встречаются ситуации, когда за конструктивным предложением следует чреда неконструктивных комментариев, иногда даже пытающихся зачмырить само предложение.
Что касается
Вы бы хоть проверяли перед тем как писать... Что по вашему происходит когда вы выделяете в Eclipse файл или список файлов и выбираете Force.com -> Run Tests? На сервер летит список из имён файлов тесты из которых надо запустить? Берётся локальное содержимое этих классов, тот самый "локально сохранённый классик", всё metadata api на память не знаю, но готов поспорить что там есть что-то в духе executeTests, и вот это самое содержимое запихивается в этот метод и отсылается на сервер для выполнения, "без деплоя". Не верите - проверьте.
Ну и последнее - если вы так уверены что ваш вариант подходит, почему не возьметесь реализовать его, я же вам даже заплатить за это предложил?
Ну ладно, самое последнее - мне чисто интересно, как в условиях тотальных лимитов форса, используя metadata api, не используя подход с System.runAs, ваш код будет отвечать на вопрос "А есть ли у John Doe доступ на чтение к полю А?" при том что помимо профиля на John Doe навешано ещё 100 permission set'ов? Удачи в парсинге циклопического кол-ва XML.
PS: если мой комментарий по-поводу "вдруг кто-то умный предлагает поклеить обои через замочную скважину", вас задел - извиняюсь, просто на форуме встречаются ситуации, когда за конструктивным предложением следует чреда неконструктивных комментариев, иногда даже пытающихся зачмырить само предложение.
Эклипсом не пользуюсь, тестил мэйвенсмэйте - запуск тестов запускает серверную копию класса, не локальную.
Насчет пермишен сетов - да, конечно это нужно, ничего трудного в этом нет, структура у них идентичная профилям.
Насчет предложения "спервадобейся" спасибо, перестал на такое вестись еще в школе.
О каком парсинге хмл ты говоришь? Все уже придумано до нас - Эндрю Фаусет из ФФ собрал отличный пакет для работы с метадата апи из апекса, где он уже отлично все разложил - fieldpermission сразу доступен и род профилем, и под сэтом.
С тем же успехом можно и в интерфейсе проверить. :)
Ну Вы мягко говоря не совсем правы.
Берешь делаешь локальный файл. Кладешь его в классы и запускаешь. Ничего на сервер сохранять не нужно.
Да, с интерфейсом - проще всего https://eu2.salesforce.com/setup/layout/flslayoutjump.jsp?setupid=FieldAccessibility&retURL=%2Fui%2Fsetup%2FSetup%3Fsetupid%3DSecurity - БА должно понравится, как раз учтет и права на макет, правда дополнительные пермишен сеты (если используется в орге) на юзере не учтет.
Кстати, что-то я запамятовал, что некоторые метаданные-то выставлены как sObject и доступны через SOQL.
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_objects_permissionset.htm - под под профилем есть Пермишен сет, к которому уже "крепятся" все филд пермишны - все еще проще
Я и не говорю что это сложно, я говорю о рациональности, лимитах и вполне себе обозримому пределу использования этого метода.
Это всё конечно прекрасно, но "никогда не ведусь" всё равно что "всегда ведусь" - точно так же прогнозируемо, а значит доступно для манипуляций.
А вот тут я дал маху, "собрал пакет", это конечно громко сказано - скачал metadata api WSDL, а потом сгенерировал на его основе apex class, но всё равно - реализовать подход с metadata api будет легче чем я предполагал, да и запас прочности у него будет вполне нормальный.
А вот это уже отличное решение! Надо всё таки не забывать обновлять свои знания.
В споре рождается истина...
Ну Вы мягко говоря не совсем правы.
Берешь делаешь локальный файл. Кладешь его в классы и запускаешь. Ничего на сервер сохранять не нужно.
MM не умеет ничего делать с локальными файликами все деплоится с инстанса.
Ну Вы мягко говоря не совсем правы.
Берешь делаешь локальный файл. Кладешь его в классы и запускаешь. Ничего на сервер сохранять не нужно.
MM не умеет ничего делать с локальными файликами все деплоится с инстанса.
Да, видно эклипс умеет деплоить с checkOnly и runSpecifiedTests.
Но нет, пробовал недавно новую версию эклипса - после ММ работать в нем очень сложно :-/
На текущий момент MM самый удобный инструмент, остальное просто неюзабельно.
Да он умеет
Да ладно будет не лень покажу как он запускает локальные скрипты без всякого деплоя :)
Деплоить локальные файлы он точно не умеет
