Получил новое задание, и в начале оно показалось мне "параноидальным" и не имеющим значительного business value, но при обсуждении выяснилось, что оно вполне резонно, и более того может быть обязательным во многих ситуациях.
и так есть СФ Орг, который обслуживает несколько коммунити. И коммунити - это не индиферентные персональные юзеры, и сотрудники организаций-парнеров. И эти организации хотят иметь средтва для мониторинга всего что происходит с их записями. Это можно как-то организовать стандартными средствами.
Но как быть если СФ юзер идет на Контакт и там через специальную кнопку-опции логиться как Community user? как обеспечить мониторинг подобного процесса?
нашелся вот такой новый и диковинный системный объект:
[ SELECT Id,
Action,
CreatedDate,
Display,
Section,
DelegateUser (здесь пусто в нашем случае)
FROM SetupAuditTrail where action = 'suNetworkAdminLogin'];
это квери вернет записи логов как Community user, это все поля что есть на объкте, и самые главные вопросы (под каким юзером залогились? какой у него профайл и коммунити? что было сделано?) здесь не отвечены, так как все что мы имеем, это стринг в поле Display вроде "Logged in using Login-As access for Den Brown" и это все. нет никаких лук-апов на юзера или хотя бы на контакт.
есть идеи как получить больше ответов в данном случае?
-под каким именно юзером залогились (имя-фимилия может быть одинаковыми у разных юзеров)?
-какой у него профайл и коммунити?
-что было сделано?
спасибо
ситуация осложняется,
оказывается что при Login-As (Community user) в LoginHistory не создается записи этого "лога" (захода Коммунитит юзера), но если этот "как бы залогившийся юзер" апдатирует запись, то это идет под именем этого "как бы залогившегося юзера"... т.е. юзер что-то делает, но при этом не залогился.
может именно эту ситуацию и ловить, пытаясь мониторить то, что было сделано/изменено в Login-As (Community user) режиме? но опять таки, не возможно достоверно определить статус Юзера: залогился он или нет? если бы это можно было бы сделать, то тогда вешаем тригер на важные объекты, который проверяет кто создает\апдатирут и залогился ли он в настоящий момент, и если ДМЛ выполняется незалогившимся юзером (т.е. под Login-As access), то создавать какую-то запись....
по существу можно изменить задачу.
никого не волнует если кто-то логился Login-As (Community user)
волнует, что он сделал (создал или поменял) что-то
таким образом вопрос в том, можно ли во время ДМЛ операции определить, что юзер действует под Login-As (Community user) доступом?!
никого не волнует если кто-то логился Login-As (Community user)
волнует, что он сделал (создал или поменял) что-то
таким образом вопрос в том, можно ли во время ДМЛ операции определить, что юзер действует под Login-As (Community user) доступом?!
А что Tracking History уже не справляется ?
а как это нам может помочь? ведь нам нужно словить ДМЛ в Login-As (Community user) ситуациия, а не все подряд ДМЛ события
продолжу про SetupAuditTrail
в UI это вещь доступна через Set up -> Security Controls -> View Setup Audit Trail
так вот, в той таблице четко указано (уникальное) ПользовательскоеИмя, под который был сделан вход через Login-As (Community user). Его можно было бы использовать, чтоб найти того юзера и его параметры. Но при доступе к SetupAuditTrail через АПИ этой инфы просто нет.
Хорошо, в Set up -> Security Controls -> View Setup Audit Trail есть линк чтобы выгрузить CSV файл, который содержит ПользовательскоеИмя, можно было бы выгрузить програмно, отпарсить и найти все что нужно. Но тот линк содержит параметр _CONFIRMATIONTOKEN, который вовсе не $Api.Session_Id как можно было бы подумать...
куда ни кинь - всюду клин
SELECT Id, Action, Section, CreatedDate, CreatedById, Display, DelegateUser
FROM SetupAuditTrail
LIMIT 1000
CreatedById, DelegateUser - 2 поля, которые нужны
wilder, ну разумеется я уже все покверил.
на LogInAs event CreateId содержит юзера который выполнил заход, а Delegate User вообще пустое
вот на LogOutAs event CreateId, вроде, содержало юзера под которым был выполнен заход, но явного LogOutAs event-а может и не случится, ловить и надеется на него нет смысла.
странно что так много мороки с этим. бизнес-ситуация, когда со стороны партнерской организации, участвующей как коммунити юзер, приходит аудит, и спрашивает головную организацию, есть ли у вас способы логиться под нашими юзерами, и если они есть, как мы можем их мониторить - это нельзя назвать необычной ситуацией, вполне законное требование.
Ну вот например у меня оно не всегда пустое и как раз содержит ид узера кто делал этот самый loginas но похоже это работает только для user's с нормальной лицензией.
wilder,
в случае suNetworkAdminLogout там действительно есть прямая ссылка на того коммунити юзера, под который был сделан вход.
но только suNetworkAdminLogout может никогда не случится: залогся с контакта на Коммунити юзера, затем просто нажми на кнопну "Назад" браузера и ты снова обычный юзер. человек может залогиться с контакта на Коммунити юзер и вообще закрыть браузер.
нужно ловить suNetworkAdminLogin и там нет прямой ссылки на Коммунити юзера (хотя в Setup Audit Trail таблице есть его уникальное логинИмя, а вот выкверить эту инфу не получается из SetupAuditTrail).
MPORTANT NOTE: The only gap i can see so far is the Delegate User (found in the Setup UI and CSV download) appears to be missing from the API at the moment. Yet it is documented as follows… ‘The Login-As user who executed the action in Setup. If a Login-As user didn’t perform the action, this field is blank.’
