Всем привет,
начался новый проект, и в нем интересная задача по шерингу для коммунити юзеров (будет партнер лицензия),
я уже имею в голове решение, но решил обсудить со всеми, ибо одна голова хорошо, а две лучше. Кроме того задача вполне может встретится и в другом проекте у каждого из нас, так что лучше все сразу и вместе обсудить.
итак,
коммунити юзеры как известно привязаны к Контакту, который в свою очередь должен иметь Эккаунт (который должен быть создан юзером, который имеет роль в организации, ха-ха-ха), и обычно шеринг всех записей для коммунити юзера идет от его Экаунта, что вполне логично.
в нашей задаче у каждого Эккаунта должен быть два типа юзера: лид и обычный. Лид может открывать доступ к записям (ко всем в пределах Эккаунта, не по одной) для обычных юзеров, и определять уровень их доступа: рид или эдит.
пока все просто
далее появляется особая группа коммунити юзеров, назовем их агенты или брокеры, они формально не принадлежат ни к одному Эккаунта, но могут работать с их записями от их лица. Лид Эккаунта дает брокер-юзеру доступ и уровень к записям организации или отменяет его.
в связи с тем что создать коммутини юзера без Эккаунта не получится, то возможно-не-исключено, что все брокер-юзеры будут создаваться под одним Эккаунтом-плейсхолдером. При этом в пределах этого Эккаунта-плейсхолдера, они, разумеется, должны видеть только свои записи.
Примечание: партнер лицензия дает в полной мере использовать шеринг-функционал
Какие идеи?
Всем привет, начался новый проект, и в нем интересная задача по шерингу для коммунити юзеров (будет партнер лицензия), я уже имею в голове решение, но решил обсудить со всеми, ибо одна голова хорошо, а две лучше. Кроме того задача вполне может встретится и в другом проекте у каждого из нас, так что лучше все сразу и вместе обсудить. итак, коммунити юзеры как известно привязаны к Контакту, который в свою очередь должен иметь Эккаунт (который должен быть создан юзером, который имеет роль в организации, ха-ха-ха), и обычно шеринг всех записей для коммунити юзера идет от его Экаунта, что вполне логично. в нашей задаче у каждого Эккаунта должен быть два типа юзера: лид и обычный. Лид может открывать доступ к записям (ко всем в пределах Эккаунта, не по одной) для обычных юзеров, и определять уровень их доступа: рид или эдит. пока все просто далее появляется особая группа коммунити юзеров, назовем их агенты или брокеры, они формально не принадлежат ни к одному Эккаунта, но могут работать с их записями от их лица. Лид Эккаунта дает брокер-юзеру доступ и уровень к записям организации или отменяет его. в связи с тем что создать коммутини юзера без Эккаунта не получится, то возможно-не-исключено, что все брокер-юзеры будут создаваться под одним Эккаунтом-плейсхолдером. При этом в пределах этого Эккаунта-плейсхолдера, они, разумеется, должны видеть только свои записи. Примечание: партнер лицензия дает в полной мере использовать шеринг-функционал Какие идеи?
Я предполагал решить шеринг для коммунити юзеров через Паблик группы и Шеринг Рулс, но сейчас присмотрелся к настройкам Шеринг Рулс и понял что это не получится.
Каждый Эккаунт мог бы иметь автоматически создаваемую для нее Паблик группу, которую использовать в Шеринг Рулс.
Проблема в том, что я не вижу в настройках Шеринг Рулс возможности для настройки "динамических" условий, например, расшерить запись для всех членов группы, к которой принадлежит владелец записи. Или расшерить запись с группой если название Эккаунта на записи совпадает с название публик групп. Но нет, условия шеринга, в том числе названия групп должны быть прямо "захардкодены" в настройках шеринг рулс.
Это значит, что на каждый Эккаунт-Паблик групп нужно создавать свой собственный Шеринг рул, что абсолютно не возможно, так как количество Шеринг Рулс на объекте очень даже ограничено
Я предполагал решить шеринг для коммунити юзеров через Паблик группы и Шеринг Рулс, но сейчас присмотрелся к настройкам Шеринг Рулс и понял что это не получится. Каждый Эккаунт мог бы иметь автоматически создаваемую для нее Паблик группу, которую использовать в Шеринг Рулс. Проблема в том, что я не вижу в настройках Шеринг Рулс возможности для настройки "динамических" условий, например, расшерить запись для всех членов группы, к которой принадлежит владелец записи. Или расшерить запись с группой если название Эккаунта на записи совпадает с название публик групп. Но нет, условия шеринга, в том числе названия групп должны быть прямо "захардкодены" в настройках шеринг рулс. Это значит, что на каждый Эккаунт-Паблик групп нужно создавать свой собственный Шеринг рул, что абсолютно не возможно, так как количество Шеринг Рулс на объекте очень даже ограничено
пока решение такое (если нужно покрыть все требования):
(1) все объкты для внешних пользователей Приватные и не шерятся по родителю. То есть пользователь может видеть только свои собственные записи.
(2) При создании нового Эккаунта создается две Паблик группы - РидОнли и Эдит.
(3) При создании новой записи, апекс код (видел делали такое и Билдером) создается два шеринг записи, что расшерить запись с двумя соответсвующими Паблик группами.
(4) Далее Лид коммунити юзер имеет свой профайл дающим ему доступ к специальной странице, которая позволяет ему добавить и удалить членов своей Организации (контат-юзерам) а также независимым Брокер-юзеров, в одну из двух групп данной организации.
(5) Эккаунт-плейсхолдер для брокеров не имеет своих групп, запись создаваемая брокером шерится только с группой нужного эккаунта (будет найдено по самой записи)
или более простое решение, если можно сделать уровень доступ для всех одинаковым (Эдит):
(1) записи в пределах Эккаунта традиционно шерятся по Controlled by Parent для членов организации. У всех одинаковый доступ.
(2) При создании нового Эккаунта создается Паблик группа.
(3) При создании новой записи, апекс код шерит запись с соответсвующей паблик группой.
(4) Далее Лид коммунити юзер имеет свой профайл дающим ему доступ к специальной странице, которая позволяет ему добавить и удалить независимым Брокер-юзеров в группу данной организации.
я кстати не вижу в Sharing Settings настройку для кастомных объектов позволяющей убрать Controlled by Parent с Child объектов
пока решение такое (если нужно покрыть все требования): (1) все объкты для внешних пользователей Приватные и не шерятся по родителю. То есть пользователь может видеть только свои собственные записи. (2) При создании нового Эккаунта создается две Паблик группы - РидОнли и Эдит. (3) При создании новой записи, апекс код (видел делали такое и Билдером) создается два шеринг записи, что расшерить запись с двумя соответсвующими Паблик группами. (4) Далее Лид коммунити юзер имеет свой профайл дающим ему доступ к специальной странице, которая позволяет ему добавить и удалить членов своей Организации (контат-юзерам) а также независимым Брокер-юзеров, в одну из двух групп данной организации. (5) Эккаунт-плейсхолдер для брокеров не имеет своих групп, запись создаваемая брокером шерится только с группой нужного эккаунта (будет найдено по самой записи) или более простое решение, если можно сделать уровень доступ для всех одинаковым (Эдит): (1) записи в пределах Эккаунта традиционно шерятся по Controlled by Parent для членов организации. У всех одинаковый доступ. (2) При создании нового Эккаунта создается Паблик группа. (3) При создании новой записи, апекс код шерит запись с соответсвующей паблик группой. (4) Далее Лид коммунити юзер имеет свой профайл дающим ему доступ к специальной странице, которая позволяет ему добавить и удалить независимым Брокер-юзеров в группу данной организации. я кстати не вижу в Sharing Settings настройку для кастомных объектов позволяющей убрать Controlled by Parent с Child объектов
я кстати не вижу в Sharing Settings настройку для кастомных объектов позволяющей убрать Controlled by Parent с Child объектов
- если обьект M-D child то он всегда будет Controlled by Parent
- если обьект кастомный то будет проще потому что ты создашь apex sharing reason и будешь всё делать через него. если обьект стандартный то не повезло - без apex sharing reason через апекс можно создать только manual sharing и он будет слетать при owner change и надо этот момент ловить в триггере и их пересоздавать.
я думаю можно чуть упростить сохранив переключение между read/write (среднее между вариантом 1 и 2) , но я отталкивался от твоего решения а не искал с нуля своё
- Controlled by Parent + Read Only OWD
- 1 группа на аккаунт, которая шарит Edit access
юзер внутри аккаунта получается всегда имеет read access, и, опционально, edit access если помещен в группу lead пользователем. если не нужно чтобы пользователь мог видеть записи, зачем ему вообще портал юзер и такого пользователя надо просто блокировать
- если нужно дать Read access брокеру то ему просто дается read доступ к аккаунту и он увидит чайлдов (если ты попробуешь дать отдельно доступ к чайлду read доступ к парент аккаунту все равно автоматически выдастся). Если edit то дается доступ в группу.
я кстати не вижу в Sharing Settings настройку для кастомных объектов позволяющей убрать Controlled by Parent с Child объектов - если обьект M-D child то он всегда будет Controlled by Parent - если обьект кастомный то будет проще потому что ты создашь apex sharing reason и будешь всё делать через него. если обьект стандартный то не повезло - без apex sharing reason через апекс можно создать только manual sharing и он будет слетать при owner change и надо этот момент ловить в триггере и их пересоздавать. я думаю можно чуть упростить сохранив переключение между read/write (среднее между вариантом 1 и 2) , но я отталкивался от твоего решения а не искал с нуля своё - Controlled by Parent + Read Only OWD - 1 группа на аккаунт, которая шарит Edit access юзер внутри аккаунта получается всегда имеет read access, и, опционально, edit access если помещен в группу lead пользователем. если не нужно чтобы пользователь мог видеть записи, зачем ему вообще портал юзер и такого пользователя надо просто блокировать - если нужно дать Read access брокеру то ему просто дается read доступ к аккаунту и он увидит чайлдов (если ты попробуешь дать отдельно доступ к чайлду read доступ к парент аккаунту все равно автоматически выдастся). Если edit то дается доступ в группу.
спасибо Андрей
OWD Controlled by Parent и OWD Public Read Only - это два варианта одной настройки, и как мы выяснили в ней вообще не будет вариантов при М-Д связи, как их использовать вместе?
или ты имеешь ввиду, что при отсутствии у объекта М-Д связи к Эккаунту используй OWD Public Read Only (что не возможно, так как ни о каком Public не может быть и речи), а при наличии, то OWD Controlled by Parent. Возникает вопрос, как коммунити юзеру выставить Read Only доступ к его Эккаунту? какой доступ вообще дефолтный? предполагаю, что если это сделать, то OWD Controlled by Parent чайлд записи будут иметь только Рид доступ для такого юзера
не подумал об этом, а можно бы. получается что шеринг запись можно создать только между Эккаунтом и соответствующей группой. Но это сработает только если: (1) есть возможность показать брокеру записи во всех чайлдах, иначе прикрывать объекты на спец профайле для брокера, (2) все нужные объекты связаны с Эккаунтом по М-Д и соответсвенно шерятся. Можно подумать
спасибо Андрей [quote="Андрей"]Controlled by Parent + Read Only OWD[/quote] OWD Controlled by Parent и OWD Public Read Only - это два варианта одной настройки, и как мы выяснили в ней вообще не будет вариантов при М-Д связи, как их использовать вместе? или ты имеешь ввиду, что при отсутствии у объекта М-Д связи к Эккаунту используй OWD Public Read Only (что не возможно, так как ни о каком [b]Public[/b] не может быть и речи), а при наличии, то OWD Controlled by Parent. Возникает вопрос, как коммунити юзеру выставить Read Only доступ к его Эккаунту? какой доступ вообще дефолтный? предполагаю, что если это сделать, то OWD Controlled by Parent чайлд записи будут иметь только Рид доступ для такого юзера [quote="Андрей"]ему просто дается read доступ к аккаунту и он увидит чайлдов[/quote] не подумал об этом, а можно бы. получается что шеринг запись можно создать только между Эккаунтом и соответствующей группой. Но это сработает только если: (1) есть возможность показать брокеру записи во всех чайлдах, иначе прикрывать объекты на спец профайле для брокера, (2) все нужные объекты связаны с Эккаунтом по М-Д и соответсвенно шерятся. Можно подумать
по первому пункту я имел ввиду что read к аккаунту пусть дает read к чайлду (можно сделать что дает сразу write - это тебе не подходит)
"есть возможность показать брокеру записи во всех чайлдах, иначе прикрывать объекты на спец профайле для брокера"
я думаю у тебя нет выбора и ты обязан "иначе прикрывать спец обьекты" пока твой обьект Detail, насколько я понимаю когда ты дашь доступ к одному чайлду, юзер автоматически получит read доступ к аккаунту, как только юзер получит доступ к аккаунту, он получит read доступ ко всем чайлдам.
по первому пункту я имел ввиду что read к аккаунту пусть дает read к чайлду (можно сделать что дает сразу write - это тебе не подходит) "есть возможность показать брокеру записи во всех чайлдах, иначе прикрывать объекты на спец профайле для брокера" я думаю у тебя нет выбора и ты обязан "иначе прикрывать спец обьекты" пока твой обьект Detail, насколько я понимаю когда ты дашь доступ к одному чайлду, юзер автоматически получит read доступ к аккаунту, как только юзер получит доступ к аккаунту, он получит read доступ ко всем чайлдам.
Спасибо Андрей,
сразу не мог ответь, был занят с requirements gathering with the client
задача немного упростилась, по крайней мере в моей голове
сейчас создам новую тему
Single-Sign-On и организация пользователей по Эккаунтам в Коммунити
так как вопрос уже вышел за пределы просто проблем шеринга
Спасибо Андрей, сразу не мог ответь, был занят с requirements gathering with the client задача немного упростилась, по крайней мере в моей голове сейчас создам новую тему [url=https://salesforce-developer.ru/forum/topic-single-sign-on-i-organizatsiya-polzovatelei-po-ekkauntam-v-kommuniti][b]Single-Sign-On и организация пользователей по Эккаунтам в Коммунити[/b][/url] так как вопрос уже вышел за пределы просто проблем шеринга