Неожиданное пожелание от заказчика: в момент создания новой дочерней записи (с кнопки Создать запись на Рел Листе стандартного лейаута родителя) юзер может редактировать Мастер-Дитейл лукап, и сознательно или случайно переназначить родителя.
Как это избежать стандартными средствами?
сразу скажу, что Мастер-Дитейл лукап:
(1) невозможно сделать рид-онли в настройках стандартного лейаута
(2) невозможно удалить со стандартного лейаута (чтобы заменить формулой, например, чтобы юзер видел имя родителя)
(3)невозможно сделать рид-онли в настройках профайла
(4) Опция Reparenting в настройках самого МД поля не помогает с случае создания новой записи
есть еще идеи?
(то что можно запилить кастомную страницу для создания дочерней записи - это понятно:)
Добавить злую надпись (Help Text) к полю - мол "попробуй только изменить!!!"
Хотя наверное на редактировании не показывается help text
Первое, что в голову пришло для Classic:
Сделать кастомный New для чайлда, в URLFOR передавать в скрытый филд айди родителя,
на сейве через валидацию сравнить айдишки в настоящем филде и скрытом.
Наверное все-таки проще в таком случае не городить костыли и просто сделать кастомную страницу.
А страницу быстрей "сгородить"? ;-)
Как по мне, то у любого опытного программиста должны быть в наличии тонны кода со старых проектов, которые постоянно улучшаются по качеству. Достаточно 1 раз сделать нормальную форму и потом просто использовать её везде.
так изи же: делаешь филдсет, бегаешь по филдсету и выводишь apex:inputField, скриптом/аттрибутом смотришь и блочишь тот филд который надо. Работы минут на 10.
Да просто уже сколько лет есть Classic Salesforce со своими стандартными страницами и все знают что нельзя туда засунуть кастомную логику, тем более на Edit Layout. Понимаю еще такой вопрос может задать новичек который SF только первый месяц видит. Но у опытного программиста просто красный свет должен загораться когда просят кастомизировать стандартные layouts.
Да, раньше были лайзеки для view layout через статик ресурсы и JS повешенный на button или через js в sidebar. Но лавочку прикрыли и сделали это не просто так. Поэтому клиенту надо сразу говорить - либо стандартные страницы, либо кастомные с хардкодными/динамическими формами.
Кстати любителям сделать максимално ала стандарт. SF придумало и запустило UI API.
https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm
Берем, делаем page builder на этой основе один раз и потом удовлетворяем клиентские прихоти практически мгновенно.
Эта хрень не все объекты поддерживает =((
Мне из-за Event и Task объектов пришлось пилить свою форму.
Event и Task вообще своеобразные объекты насколько я помню.
Объекты как объекты)
Не хуже и не лучше остальных.
Как раз и наоборот. Из-за своих WhatId и WhoId есть некоторые особенности в их поведении. Да, в коде с ними проблем нет, бери и делай. Но я припоминаю были какие-то особенности их использования с которыми приходилось бороться.
Мультилукапы в 1й раз всегда долго пилить.
п.с. заюзал strike компоненты в лайтнинге для ускорения разработки, но до чего же они кривые =((
В апексе написано, чтобы всё было хорошо. Если какой-то косяк - сразу падает exception, который даже не показывает на компоненте. А потом думаешь - почему ничего не работает и ничего не падает.
В самой компоненте написано также...
это ты так называешь лукапы, которые могут принимать АйДи разных объектов?
хорошее название, напоминающее об их сущности. а то думаешь, что Owner это только Юзер, а там - бац - и очередь
Это лукапы, которые ведут себя вот так:
https://gyazo.com/332fb072f01ba17bac46298970727243
А те, что могут принимать Id разных объектов - это полиморфные лукапы :)
очень хорошо, что разобрались в названиях.
как такое возможно? или это просто так оформленный список рилетейд записей?
Поле Name на объекте Event 
Можете сами зайти на орг в Lightning и попробовать создать запись.
Правда нужна ещё вот эта опция:
https://gyazo.com/f780e426647957ff4e6ae34865f62c55
Ну вот, а говорил, что объекты как объекты :)
