Нужно ли проверять isUpdatable () при запуске процесса в системном режиме / триггере, чтобы пройти процесс проверки безопасности? - PullRequest
0 голосов
/ 07 февраля 2020

В Salesforce у нас есть сценарий, по триггеру ведущего объекта мы обновляем некоторые записи Campaign. Но пользователь от имени запускаемого нами триггера не имеет прав на редактирование кампании. Мы не сталкиваемся с какими-либо проблемами при обновлении кампании, поскольку триггер запускает операцию в системном режиме. Кроме того, мы подали заявку на проверку безопасности, внесли изменения и добавили проверку объекта isUpdatable (), и после него мы не можем обновить кампанию из-за этой проверки, которая возвращает false для isUpdatable ().

Мои вопросы: можем ли мы пройти проверку безопасности, не применяя проверку isUpdatable ()? если наш процесс имеет бизнес-логику c для обновления кампании / возможности от имени пользователя, у которого нет разрешений на кампанию / возможность?

Если мы не можем пройти проверку безопасности с этим проверьте, что может быть альтернативой для него, когда один пользователь, который не имеет разрешения на кампанию / возможность, выполняет какую-либо операцию над лидерством / контактом, и мы хотим обновить кампанию / возможность в системном режиме после этой операции?

или необходимо предоставить разрешения кампании / возможности для этого пользователя?

1 Ответ

1 голос
/ 08 февраля 2020

Это не вопрос кодирования как таковой, поэтому он может быть закрыт здесь. Рассмотрите возможность перекрестной публикации на https://salesforce.stackexchange.com/

В общем, ваше приложение должно упрощать Salesforce. Повышение ценности за счет предварительно созданного, предварительно протестированного варианта использования для этого клиента и экономии кликов для конечного пользователя. (давайте проигнорируем ситуации, такие как извлечение данных из других систем, запуск некоторого сумасшедшего создания файла Excel, который SF не может сделать легко). С этой философией - вы должны уважать пожелания системного администратора, когда речь заходит о безопасности. Если администратор не предоставил доступ для редактирования профиля X к полю Y - ответ проверки безопасности состоит в том, что вы должны его обнаружить. Если вы можете изящно восстановиться и продолжить свою программу - круто. Если это критическое поле - выведите ошибку, заставьте администратора принять сознательное решение. Потому что, если вы сохраняете клики - пользователь столкнется с той же проблемой в обычном интерфейсе. Это не только «описывает», но и «без обмена», например.

Есть еще один слой - лицензирование. В прежние времена «Маркетинговый пользователь» (для доступа к кампаниям) представлял собой отдельную лицензию, вы назначали ее, установив флажок «Пользователь», но ее нужно было купить. Теперь это немного проще, часть полной пользовательской лицензии (я думаю). Но все еще существуют ситуации, когда вы не можете получить доступ к возможностям, например (лицензия на платформу) или можете получить доступ только к учетной записи, контакту и 10 пользовательским объектам (лицензия Chatter Plus или как-то по-новому).

Если вы злоупотребляете Системный режим для извлечения данных из объектов, которые пользователь не может видеть (или сохранять в них) - официальный ответ: SF теряет деньги из-за вас. Разрешение действительно должно быть назначено, а при необходимости - лицензия куплена. Я не юрист, я не знаю, кто нарушает Генеральное соглашение об обслуживании с Salesforce, вы или клиент, который установил приложение, или и то, и другое. Я бы сказал, прочитайте контракты и посмотрите, что вы можете сделать, чтобы защитить себя. Если это означает, что ваше приложение не может быть установлено клиентами в Essentials / Professional (или оно может быть установлено где угодно, но может использоваться только полными пользователями, а не платформой / Chatter / Community) - ну, это то, что оно есть. Решите плюсы и минусы, юридические последствия, если его поймают ...

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

PS Вы знаете, что вам больше не нужно описывать? Spring'20 выходит в эфир на этой и следующей неделе, и "WITH SECURITY ENFORCED" и "stripinaccessiblefields" становятся общедоступными:)

PPS, вам действительно нужен триггер? Рабочий процесс, компоновщик процессов, поток (гадость) - все, что не имеет кода = не нуждается в isAccessible, и если он эффективно умирает от разрешений - это проблема системного клиента?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...