Регистрация  |  Вход

Как вам такая проверка в триггере

Триггер

Item.OwnerId != userInfo.getUserId()


до этого в коде никаких изменений OwnerId нет.

Триггер 

Item.OwnerId != userInfo.getUserId()


до этого в коде никаких изменений OwnerId нет.

Смысл вопроса не понял, но жду развития темы.

Смысл вопроса не понял, но жду развития темы. :D 

Dmitry Shnyrev
Смысл вопроса не понял, но жду развития темы. :D

Ответь просто это истинное утверждение или нет.

[quote="Dmitry Shnyrev"]Смысл вопроса не понял, но жду развития темы. :D[/quote]

Ответь просто это истинное утверждение или нет.

Тоже не понимаю смысла. Обычная проверка является ли залогиненый юзер овнером записи.

Тоже не понимаю смысла. Обычная проверка является ли залогиненый юзер овнером записи.

Еще кто что скажет ?

Еще кто что скажет ?

wilder
Ответь просто это истинное утверждение или нет.

не совсем истинное.

во первых тригер понятие растяжимое, и никакого owner там может и не быть.

во вторых, и более важно, owner тоже понятие растяжимое, и владельцем внезапно может быть не-юзер, а... и тогда код может слегка упасть...

[quote="wilder"]Ответь просто это истинное утверждение или нет.[/quote]

не совсем истинное.

во первых тригер понятие растяжимое, и никакого owner там может и не быть.

во вторых, и более важно, owner тоже  понятие растяжимое, и владельцем внезапно может быть не-юзер, а... и тогда код может слегка упасть...


Согласен с Деном.

Согласен с Деном.

Den Brown
и тогда код может слегка упасть...

Как?

[quote="Den Brown"]и тогда код может слегка упасть...[/quote]
Как?

Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет?

Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет? 

DevNull
Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет?

именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)

[quote="DevNull"]Овнером может быть и Очередь кстати) Но все равно оно содержит id. Но как он упадет?[/quote]
именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)

Den Brown
именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)

Да тоже встречался) Но если ты ожидаешь очередь, то ты сделаешь так как надо.
Но по сути, даже если в овнере очередь, то данная проверка не упадет. Просто даст false.

[quote="Den Brown"]именно об Очереди и идет речь, в данном случае может и не упадет, но вот если ты не ожидаешь что там может быть очередь и без проверок попытаешься кверить юзера по ownerID, то тогда упадет... уже бывало... :)[/quote]
Да тоже встречался) Но если ты ожидаешь очередь, то ты сделаешь так как надо. 
Но по сути, даже если в овнере очередь, то данная проверка не упадет. Просто даст false. 

DevNull
то данная проверка не упадет. Просто даст false.

ладно, ждем wilder-а, не понятно, ответили ли мы на вопрос или нет

[quote="DevNull"]то данная проверка не упадет. Просто даст false.[/quote]

ладно, ждем wilder-а, не понятно, ответили ли мы на вопрос или нет

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, а из этого следует что он всегда овнер этой записи.

Это просто в очередной раз отсылка к вопросу о бесполезности сертификатов.

Один очень умный американец (как он сам про себя думает) в тихаря изменил мой триггер, и мне просто стало интересно что он там изменил :)

Sergey Prichepo
сорри Истенное походу.

наоборот

[quote="Sergey Prichepo"]сорри Истенное походу.[/quote]

наоборот

wilder
Код триггера простейший и Owner не меняеся. Этот код отрабатывает на before insert

О! Вот наконец-то ты упомянул основной момент - триггер before insert! До этого это был просто триггер и в before update эта проверка очень даже имеет смысл. А в твоем случае точно не имеет. Может твой американский коллега недопонял смысл триггера?

[quote="wilder"]Код триггера простейший и Owner не меняеся. Этот код отрабатывает на before insert[/quote]
О! Вот наконец-то ты упомянул основной момент - триггер before insert! До этого это был просто триггер и в before update эта проверка очень даже имеет смысл. А в твоем случае точно не имеет. Может твой американский коллега недопонял смысл триггера?

wilder
Этот код отрабатывает на before insert

Так вот эта проверка 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-а, что там вообще сравнивать...

wilder
Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.

Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId().Согласен с Den что там должно быть null.

[quote="wilder"]Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.[/quote]
Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId().Согласен с Den что там должно быть null.

Sergey Prichepo
Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId()

wilder
Это просто в очередной раз отсылка к вопросу о бесполезности сертификатов.

=)

[quote="Sergey Prichepo"]Я когда отвечал думал что триггеры выполняются в систем контексте.userInfo.getUserId()[/quote]
[quote="wilder"]Это просто в очередной раз отсылка к вопросу о бесполезности сертификатов.[/quote]
=)

кстати, а куда "ilya leshchuk" делся?

кстати, а куда "ilya leshchuk" делся? 

Gres
=)

=) =)

[quote="Gres"]
=)[/quote]
=) =)

Gres
=)

Gres юморист
:)))))))))))))))))

[quote="Gres"]=)[/quote]
Gres юморист
:)))))))))))))))))

Den Brown
на before insert в том поле вообще должен быть null... я думал, что оно заполняется в момент insert-а, что там вообще сравнивать...

Однозначно зачет !

[quote="Den Brown"]на before insert в том поле вообще должен быть null... я думал, что оно заполняется в момент insert-а, что там вообще сравнивать...[/quote]

Однозначно зачет !

wilder
Так вот эта проверка Item.OwnerId != userInfo.getUserId() не имеет никакого смысла, так как триггер выполняется в контексте текущего User'a, а из этого следует что он всегда овнер этой записи.

Как мне кажется не совсем корректно говорить что 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() скорее можно посмотреть какой юзер его вызвал.    

Sergey Prichepo
выполняется в контексте какого то юзер

Покажи плиз как я могу запустить код не от текущего юзера(тесты не в счет).

[quote="Sergey Prichepo"] выполняется в контексте какого то юзер[/quote]

Покажи плиз как я могу запустить код не от текущего юзера(тесты не в счет).

Думаю что никак,(либо эмулировать АPI в апекс для разных юзеров) ну или я про это не знаю.Я счас не про это, я про то что контекст выполнения кода определяется местом и окружением где он выполняется, а не тем кто его вызвал. Раньше я думал что контекст определяется через профиле, но как оказалось apex dml ничего не знает о профайле. userInfo.getUserId() возвращает Id, я так понимаю что бы определить точку входа кто вызвал этот код, где то видел даже таблицу какие пермишены на какой контекст влияют.

Думаю что никак,(либо эмулировать АPI в апекс для разных юзеров) ну или я про это не знаю.Я счас не про это, я про то что контекст выполнения кода определяется местом и окружением где он выполняется, а не тем кто его вызвал. Раньше я думал что контекст определяется через профиле, но как оказалось apex dml ничего не знает о профайле. userInfo.getUserId() возвращает Id, я так понимаю что бы определить точку входа кто вызвал этот код, где то видел даже таблицу какие пермишены на какой контекст влияют.    

Den Brown
кстати, а куда "ilya leshchuk" делся?

Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого

Если я не ошибаюсь, ситуация когда

Item.OwnerId != userInfo.getUserId()
истинно может быть при загрузке записей извне, например через Data Loader.

[quote="Den Brown"]кстати, а куда "ilya leshchuk" делся?[/quote]
Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого :(

Если я не ошибаюсь, ситуация когда [code]Item.OwnerId != userInfo.getUserId()[/code] истинно может быть при загрузке записей извне, например через Data Loader. 

ilya leshchuk
Den Brown
кстати, а куда "ilya leshchuk" делся?

Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого

Если я не ошибаюсь, ситуация когда

Item.OwnerId != userInfo.getUserId()
истинно может быть при загрузке записей извне, например через Data Loader.

Собственно истину глаголишь, есть такой редкий кейс. Но это был не этот случай.

[quote="ilya leshchuk"][quote="Den Brown"]кстати, а куда "ilya leshchuk" делся?[/quote]
Редко захожу, тяжело отследить что я уже читал, т.к. внезапно пропала подсветка красным непрочтённого :(

Если я не ошибаюсь, ситуация когда [code]Item.OwnerId != userInfo.getUserId()[/code] истинно может быть при загрузке записей извне, например через Data Loader.[/quote]

Собственно истину глаголишь, есть такой редкий кейс. Но это был не этот случай.

А у меня не такой уж и редкий.

А у меня не такой уж и редкий. 

ilya leshchuk
т.к. внезапно пропала подсветка красным непрочтённого

Сорри, есть косяк - лечится так - надо зайти и выйти с форума. Для экономии места и ресурсов оповещения по новым темам создаются по last login at не больше месяца.

[quote="ilya leshchuk"]т.к. внезапно пропала подсветка красным непрочтённого[/quote]
Сорри, есть косяк - лечится так - надо зайти и выйти с форума. Для экономии места и ресурсов оповещения по новым темам создаются по last login at не больше месяца. 

ilya leshchuk
Если я не ошибаюсь, ситуация когда

Item.OwnerId != userInfo.getUserId()
истинно может быть при загрузке записей извне, например через Data Loader.

не зря я спрашивал, где этот Илья!!!

получается что в данном случае даже на Before Insert это поле НЕ пустое

[quote="ilya leshchuk"]Если я не ошибаюсь, ситуация когда

Item.OwnerId != userInfo.getUserId()
истинно может быть при загрузке записей извне, например через Data Loader.[/quote]

не зря я спрашивал, где этот Илья!!!

получается что в данном случае даже на Before Insert это поле НЕ пустое