Компоненты, которые могут "втихую" не задеплоится во время успешного деплоя Change set-а

Компоненты, которые могут "втихую" не задеплоится во время успешного деплоя Change set-а

Всем привет,

как я писал в одной теме ранее, был случай не-деплоя Профайлов во время успешного деплоя Чендж сета. Но
Профайлы все же сложные и исключительно ответственные в плане безопасности вещи, и вероятно такое их поведение в каких то случаях можно как то объяснить.

Но не далече чем вчера я столкнулся с похожей проблемой, но с более простым компонентом.
Внезапно не апдатировался во время деплоя "All" List View одного кастомного объекта. Собственно говоря, редко приходится "двигать" этот компонент, но если ты добавил кастомную кнопку на стандартный List View, то именно его и нужно двигать.

Я добавил в Чендж сет кнопку (она задеплоилась нормально), "All" List View (проверил в его метадате что там действительно указана моя кнопка), но он не задеплоился, при этом не показав никаких ошибок. Пришлось добавлять кнопку вручную.

Почему так?

Какие еще компоненты могут вот так "втихую" не задеплоится?

спасибо

Может у тебя галочка на view стоит показывать только мне? За 5 лет ниразу не видел что бы что то не задеплоилось втихую.

Хотя профили я всегда руками переношу.

3ff92449553a511907deb1a8b123b58c?size=200&d=https%3a%2f%2fsalesforce developer.ru%2fwp content%2fuploads%2favatars%2fno avatar

проверил,

Visible to all users

это дефолтный "All" List View, обычно его не рестриктят подобным образом

Den Brown
но если ты добавил кастомную кнопку на стандартный List View, то именно его и нужно двигать.

вот тут я немного ошибался. Оказывается кастомные кнопки для List View прописаны прям на самом Объекте, и чтобы задеплоить такую кнопку нужно двигать сам Объект. Это случайно всплыло, когда стали двигать Объект, а он внезапно захныкал на деплое, что ему мол кнопочки-то не хватает в чендж сете

также всплыла такая проблема:

Двигаем кастомный Объект который Public/Private на OWD.

Но при деплое он внезапно становится Public/Public и вуаля, шеринг таблицы __Share не сущестсвует для публичного объекта, следовательно код, ссылающися на нее не деплоится :)

А разве деплой не ругается когда шаринг модель в объектах разная?
Я помню раньше на одном проекте это была вечная головная боль что приходилось руками поправлять все шаринги на объектах чтобы они совпадали.

Иногда, при деплое Aura bundles, SF показывает что все успешно задеплоилось, но при этом тестишь компонент - а он работает по-старому, со старым кодом. Открываешь код компонента - видишь новый код. Впадаешь в когнитивный диссонанс.
Решение - нужно прямо на продакшене, зайти на контроллер/хелпер компонента, поставить где-нибудь пробел/tab и нажать save, после этого все работает как надо.
Почему так происходит - загадка, но скорее всего SF каким-то образом кэширует лайтнинг код и после деплоя кэш не обновляется.

Я про это недавно упоминал.
Такая же хрень во время разработки происходит.
При сохранении изменений, обновленный компонент можно увидеть в лучшем случае через секунд 15 а то и больше (при условии что страницу перезагружаешь раз 20)

Dmitry Shnyrev
А разве деплой не ругается когда шаринг модель в объектах разная?

двигали объект как совершенно новый...

Interesting information? Help us, post link to social media..