Переопределить метод удаления пользовательского объекта

Question

У нас есть пользовательский объект в нашем экземпляре, который эффективно является объектом соединения. Прямо сейчас, если связь удалена, запись в объекте соединения удаляется.

Мы хотим изменить это поведение таким образом, чтобы объект соединения был помечен как удаленный, но физически не удален (пожалуйста, поймите, что я не могу вдаваться в подробности о том, почему есть хорошие деловые причины). Поскольку у нас есть несколько клиентов, обращающихся к нашему экземпляру через API SOAP и REST, я хотел бы реализовать решение, в котором я переопределяю стандартную функциональность удаления настраиваемого объекта, чтобы просто проверить пользовательское поле is_deleted, а не удалять запись.

Возможно ли это?

Приветствия,

Dan

Answer 1

Я полагаю, вы не можете просто положить триггер-удаления на объекте?

Если вы можете, просто добавьте триггерный код для обновления поля, а затем присоедините ошибку к удаляемой записи (поэтому удаление не проходит). В официальных документах есть много примеров того, как это сделать.

Помните, все bulkified (процесс все записи удаляется сразу, из списка) ...

На стороне записки, удаленные записи в SalesForce хранятся в корзине на орг для Через 15 дней после удаления. Таким образом, вы также можете выбрать их из объекта, используя форму запроса SELECT ... ALL ROWS.

Answer 2

Я не думаю, что вы действительно можете переопределить действие удаления. Вы можете переопределить кнопку (с помощью страницы Visualforce), но это никоим образом не поможет вам, если удаление удалено из API.

Я подозреваю, что вы хотите притворяться, что пользователи API (SOAP, REST и т. Д.), Которые записывают, были удалены, а на самом деле их где-то сохраняли? Пахнет какой-то теневой деловой практикой, если честно, но что угодно, давайте предположим, что это действительно законно ... Конечно, вы не можете внезапно бросать ошибки в операции, потому что ваши конечные пользователи заметят.

Я думаю, что я поеду со скрытым 1-к-1 соответствующим «теневым» объектом и синхронизирую каждое действие с ним. Вам понадобится триггер для вставки/обновления/удаления/восстановления вашего соединения, который бы реплицировал действие (разница в этом пользовательском флажке «мягкое удаление»). У этого есть много проблем, как использование памяти, но хорошо.

Одна вещь, которая приходит на ум, состоит в том, что (если я правильно помню) триггеры на соединительном объекте не срабатывают, если вы удаляете одного из мастеров. Поэтому, если это реальный объект соединения (вы написали «действует как»), вам придется иметь дело с этим сценарием и поместить логику в триггеры главных объектов.

Если это не настоящий объект соединения (т. Е. Он имеет видимое поле OwnerId), и ваши правила совместного доступа разрешают - возможно, вы можете передать право собственности на запись на какой-то специальный пользователь/очередь за пределами иерархии ролей, чтобы она стала невидимой ... Но я сомневаюсь, что это сработает, в конце концов, удаление должно выглядеть успешно, не так ли? Может быть, в сочетании с некоторыми @future, которые немедленно восстановили бы их & передачи ... Все еще - беспорядочно!