#validation #salesforce
#проверка #salesforce
Вопрос:
В настоящее время у меня есть правило проверки, которое запрещает пользователю вносить изменения в запись, когда ее статус завершен. Пользователям разрешается вносить изменения, только если статус черновик или зарегистрирован.
AND(
TEXT(Current_Status__c) <> "Draft",
TEXT(Current_Status__c) <> "Registered"
)
Существует новое требование, позволяющее пользователю обновлять только определенное поле значения раскрывающегося списка, даже если статус записи завершен. Если я удалю правило проверки, пользователь сможет изменять любые поля в макете страницы, которые не будут работать.
Настройка объекта для профиля — чтение, создание, редактирование. Этот объект является дочерним объектом Opportunity, OWD контролируется родительским.
Есть какие-либо рекомендации по решению этой проблемы?
Заранее спасибо.
Ответ №1:
Мы можем переписать ваше правило так, ISPICKVAL(Current_Status__c, 'Completed') например, чтобы оно выглядело немного чище. Однако ваш вызов можно оставить как есть.
Итак, вам понадобится что-то вроде ISPICKVAL(Current_Status__c, 'Completed') amp;amp; !ISCHANGED(Some_Picklist__c) . Это должно позволить редактировать, если вы изменяете этот список выбора.
Проблема в том, что он не проверяет, единственное ли это изменение. Пользователь может обмануть, изменить 10 полей, и они будут «подключены» и сохранятся нормально, если одно из них является этим списком выбора.
Писать проверку, подобную ISPICKVAL(Current_Status__c, 'Completed') amp;amp; !ISCHANGED(Some_Picklist__c) amp;amp; (ISCHANGED(Field1__c) || ISCHANGED(Field2__c) || ISCHANGED(Field3__c)) , довольно сложно. Вам придется добавлять в нее все редактируемые поля, изменять ее каждый раз, когда вы создаете новое. И в конечном итоге вы достигнете ограничений по длине.
Я знаю 3 варианта для этого, если это беспокоит вас:
-
Попросите разработчика переписать вашу логику в Apex trigger, после чего она может динамично перемещаться по всем полям (используя вызовы «describe» для изучения имен полей или тому подобное
getPopulatedFieldsAsMap. -
Другой трюк заключается в том, чтобы разрешить редактирование завершенных записей только с помощью быстрого действия, а не обычной страницы редактирования. В этом действии вы могли бы установить какой-нибудь скрытый флажок на этапе предварительного заполнения поля, и ваша проверка позволила бы сохранить только в том случае, если этот флажок установлен. Но тогда вам все равно нужно как-то ее деактивировать, иначе обход будет включен постоянно.
-
Если у вас не слишком много типов записей на объекте, распространенным приемом является изменение типа записи по завершении (рабочий процесс, конструктор процессов и т.д.). И создайте другой макет страницы со всеми заблокированными полями, кроме этого специального раскрывающегося списка. Это работает достаточно хорошо для изменений пользовательского интерфейса, но не защитит, если у вас также есть код и интеграции, записываемые в объект.