Триггер
Item.OwnerId != userInfo.getUserId()
до этого в коде никаких изменений OwnerId нет.
Триггер Item.OwnerId != userInfo.getUserId() до этого в коде никаких изменений OwnerId нет.
Смысл вопроса не понял, но жду развития темы.
Смысл вопроса не понял, но жду развития темы. :D
Ответь просто это истинное утверждение или нет.
[quote="Dmitry Shnyrev"]Смысл вопроса не понял, но жду развития темы. :D[/quote] Ответь просто это истинное утверждение или нет.
Тоже не понимаю смысла. Обычная проверка является ли залогиненый юзер овнером записи.
Тоже не понимаю смысла. Обычная проверка является ли залогиненый юзер овнером записи.
Еще кто что скажет ?
Еще кто что скажет ?
не совсем истинное.
во первых тригер понятие растяжимое, и никакого owner там может и не быть.
во вторых, и более важно, owner тоже понятие растяжимое, и владельцем внезапно может быть не-юзер, а... и тогда код может слегка упасть...
[quote="wilder"]Ответь просто это истинное утверждение или нет.[/quote] не совсем истинное. во первых тригер понятие растяжимое, и никакого owner там может и не быть. во вторых, и более важно, owner тоже понятие растяжимое, и владельцем внезапно может быть не-юзер, а... и тогда код может слегка упасть...
Согласен с Деном.
Согласен с Деном.
Как?
[quote="Den Brown"]и тогда код может слегка упасть...[/quote] Как?
Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет?
Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет?
именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)
[quote="DevNull"]Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет?[/quote] именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)
Да тоже встречался) Но если ты ожидаешь очередь, то ты сделаешь так как надо.
Но по сути, даже если в овнере очередь, то данная проверка не упадет. Просто даст false.
[quote="Den Brown"]именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)[/quote] Да тоже встречался) Но если ты ожидаешь очередь, то ты сделаешь так как надо. Но по сути, даже если в овнере очередь, то данная проверка не упадет. Просто даст false.
ладно, ждем wilder-а, не понятно, ответили ли мы на вопрос или нет
[quote="DevNull"]то данная проверка не упадет. Просто даст false.[/quote] ладно, ждем wilder-а, не понятно, ответили ли мы на вопрос или нет
Item.OwnerId != userInfo.getUserId()
до этого в коде никаких изменений OwnerId нет.
сорри Истенное походу.
[quote="wilder"]Триггер Item.OwnerId != userInfo.getUserId() до этого в коде никаких изменений OwnerId нет.[/quote] сорри Истенное походу.
Пару уточнений.
В данном конкретном обьекте это всегда User
Код триггера простейший и Owner не меняеся. Этот код отрабатывает на before insert
Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.
Это просто в очередной раз отсылка к вопросу о бесполезности сертификатов.
Один очень умный американец (как он сам про себя думает) в тихаря изменил мой триггер, и мне просто стало интересно что он там изменил :)
Пару уточнений. В данном конкретном обьекте это всегда User Код триггера простейший и Owner не меняеся. Этот код отрабатывает на before insert Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи. Это просто в очередной раз отсылка к вопросу о бесполезности сертификатов. Один очень умный американец (как он сам про себя думает) в тихаря изменил мой триггер, и мне просто стало интересно что он там изменил :)
наоборот
[quote="Sergey Prichepo"]сорри Истенное походу.[/quote] наоборот
О! Вот наконец-то ты упомянул основной момент - триггер before insert! До этого это был просто триггер и в before update эта проверка очень даже имеет смысл. А в твоем случае точно не имеет. Может твой американский коллега недопонял смысл триггера?
[quote="wilder"]Код триггера простейший и Owner не меняеся. Этот код отрабатывает на before insert[/quote] О! Вот наконец-то ты упомянул основной момент - триггер before insert! До этого это был просто триггер и в before update эта проверка очень даже имеет смысл. А в твоем случае точно не имеет. Может твой американский коллега недопонял смысл триггера?
Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.
на before insert в том поле вообще должен быть null... я думал, что оно заполняется в момент insert-а, что там вообще сравнивать...
[quote="wilder"]Этот код отрабатывает на before insert Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.[/quote] на [b]before[/b] insert в том поле вообще должен быть null... я думал, что оно заполняется в момент insert-а, что там вообще сравнивать...
Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId().Согласен с Den что там должно быть null.
[quote="wilder"]Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.[/quote] Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId().Согласен с Den что там должно быть null.
=)
[quote="Sergey Prichepo"]Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId()[/quote] [quote="wilder"]Это просто в очередной раз отсылка к вопросу о бесполезности сертификатов.[/quote] =)
кстати, а куда "ilya leshchuk" делся?
кстати, а куда "ilya leshchuk" делся?
=) =)
[quote="Gres"] =)[/quote] =) =)
Gres юморист
:)))))))))))))))))
[quote="Gres"]=)[/quote] Gres юморист :)))))))))))))))))
Однозначно зачет !
[quote="Den Brown"]на before insert в том поле вообще должен быть null... я думал, что оно заполняется в момент insert-а, что там вообще сравнивать...[/quote] Однозначно зачет !
Как мне кажется не совсем корректно говорить что Apex код выполняется в контексте какого то юзера,ты можешь запустить код от имени юзера так что бы отработали sharing rules,например Apex код ничего не знает о профайлах и ему все равно какие пермишенны там стоят в профайле когда он делает DML операции. Насколько я понимаю триггер отрабатывает в сустем контексте,поэтому обычно везде вызываются классы with sharing что бы можно было применить sharing rules в триггере.userInfo.getUserId() скорее можно посмотреть какой юзер его вызвал.
[quote="wilder"]Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.[/quote] Как мне кажется не совсем корректно говорить что Apex код выполняется в контексте какого то юзера,ты можешь запустить код от имени юзера так что бы отработали sharing rules,например Apex код ничего не знает о профайлах и ему все равно какие пермишенны там стоят в профайле когда он делает DML операции. Насколько я понимаю триггер отрабатывает в сустем контексте,поэтому обычно везде вызываются классы with sharing что бы можно было применить sharing rules в триггере.userInfo.getUserId() скорее можно посмотреть какой юзер его вызвал.
Покажи плиз как я могу запустить код не от текущего юзера(тесты не в счет).
[quote="Sergey Prichepo"] выполняется в контексте какого то юзер[/quote] Покажи плиз как я могу запустить код не от текущего юзера(тесты не в счет).
Думаю что никак,(либо эмулировать АPI в апекс для разных юзеров) ну или я про это не знаю.Я счас не про это, я про то что контекст выполнения кода определяется местом и окружением где он выполняется, а не тем кто его вызвал. Раньше я думал что контекст определяется через профиле, но как оказалось apex dml ничего не знает о профайле. userInfo.getUserId() возвращает Id, я так понимаю что бы определить точку входа кто вызвал этот код, где то видел даже таблицу какие пермишены на какой контекст влияют.
Думаю что никак,(либо эмулировать АPI в апекс для разных юзеров) ну или я про это не знаю.Я счас не про это, я про то что контекст выполнения кода определяется местом и окружением где он выполняется, а не тем кто его вызвал. Раньше я думал что контекст определяется через профиле, но как оказалось apex dml ничего не знает о профайле. userInfo.getUserId() возвращает Id, я так понимаю что бы определить точку входа кто вызвал этот код, где то видел даже таблицу какие пермишены на какой контекст влияют.
Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого
Если я не ошибаюсь, ситуация когда
Item.OwnerId != userInfo.getUserId()истинно может быть при загрузке записей извне, например через Data Loader.
[quote="Den Brown"]кстати, а куда "ilya leshchuk" делся?[/quote] Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого :( Если я не ошибаюсь, ситуация когда [code]Item.OwnerId != userInfo.getUserId()[/code] истинно может быть при загрузке записей извне, например через Data Loader.
Если я не ошибаюсь, ситуация когда
Item.OwnerId != userInfo.getUserId()истинно может быть при загрузке записей извне, например через Data Loader.
Собственно истину глаголишь, есть такой редкий кейс. Но это был не этот случай.
[quote="ilya leshchuk"][quote="Den Brown"]кстати, а куда "ilya leshchuk" делся?[/quote] Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого :( Если я не ошибаюсь, ситуация когда [code]Item.OwnerId != userInfo.getUserId()[/code] истинно может быть при загрузке записей извне, например через Data Loader.[/quote] Собственно истину глаголишь, есть такой редкий кейс. Но это был не этот случай.
А у меня не такой уж и редкий.
А у меня не такой уж и редкий.
т.к. внезапно пропала подсветка красным непрочтённого
Сорри, есть косяк - лечится так - надо зайти и выйти с форума. Для экономии места и ресурсов оповещения по новым темам создаются по last login at не больше месяца.
[quote="ilya leshchuk"]т.к. внезапно пропала подсветка красным непрочтённого[/quote] Сорри, есть косяк - лечится так - надо зайти и выйти с форума. Для экономии места и ресурсов оповещения по новым темам создаются по last login at не больше месяца.
Если я не ошибаюсь, ситуация когда
Item.OwnerId != userInfo.getUserId()
истинно может быть при загрузке записей извне, например через Data Loader.
не зря я спрашивал, где этот Илья!!!
получается что в данном случае даже на Before Insert это поле НЕ пустое
[quote="ilya leshchuk"]Если я не ошибаюсь, ситуация когда Item.OwnerId != userInfo.getUserId() истинно может быть при загрузке записей извне, например через Data Loader.[/quote] не зря я спрашивал, где этот Илья!!! получается что в данном случае даже на Before Insert это поле НЕ пустое