Практическая задача по шерингу для внешних юзеров

Практическая задача по шерингу для внешних юзеров

Всем привет,

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

я уже имею в голове решение, но решил обсудить со всеми, ибо одна голова хорошо, а две лучше. Кроме того задача вполне может встретится и в другом проекте у каждого из нас, так что лучше все сразу и вместе обсудить.

итак,

коммунити юзеры как известно привязаны к Контакту, который в свою очередь должен иметь Эккаунт (который должен быть создан юзером, который имеет роль в организации, ха-ха-ха), и обычно шеринг всех записей для коммунити юзера идет от его Экаунта, что вполне логично.

в нашей задаче у каждого Эккаунта должен быть два типа юзера: лид и обычный. Лид может открывать доступ к записям (ко всем в пределах Эккаунта, не по одной) для обычных юзеров, и определять уровень их доступа: рид или эдит.

пока все просто

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

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

Примечание: партнер лицензия дает в полной мере использовать шеринг-функционал

Какие идеи?

Я предполагал решить шеринг для коммунити юзеров через Паблик группы и Шеринг Рулс, но сейчас присмотрелся к настройкам Шеринг Рулс и понял что это не получится.

Каждый Эккаунт мог бы иметь автоматически создаваемую для нее Паблик группу, которую использовать в Шеринг Рулс.

Проблема в том, что я не вижу в настройках Шеринг Рулс возможности для настройки "динамических" условий, например, расшерить запись для всех членов группы, к которой принадлежит владелец записи. Или расшерить запись с группой если название Эккаунта на записи совпадает с название публик групп. Но нет, условия шеринга, в том числе названия групп должны быть прямо "захардкодены" в настройках шеринг рулс.

Это значит, что на каждый Эккаунт-Паблик групп нужно создавать свой собственный Шеринг рул, что абсолютно не возможно, так как количество Шеринг Рулс на объекте очень даже ограничено

пока решение такое (если нужно покрыть все требования):

(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 то дается доступ в группу.

спасибо Андрей

Андрей
Controlled by Parent + Read Only OWD

OWD Controlled by Parent и OWD Public Read Only - это два варианта одной настройки, и как мы выяснили в ней вообще не будет вариантов при М-Д связи, как их использовать вместе?

или ты имеешь ввиду, что при отсутствии у объекта М-Д связи к Эккаунту используй OWD Public Read Only (что не возможно, так как ни о каком Public не может быть и речи), а при наличии, то OWD Controlled by Parent. Возникает вопрос, как коммунити юзеру выставить Read Only доступ к его Эккаунту? какой доступ вообще дефолтный? предполагаю, что если это сделать, то OWD Controlled by Parent чайлд записи будут иметь только Рид доступ для такого юзера

Андрей
ему просто дается read доступ к аккаунту и он увидит чайлдов

не подумал об этом, а можно бы. получается что шеринг запись можно создать только между Эккаунтом и соответствующей группой. Но это сработает только если: (1) есть возможность показать брокеру записи во всех чайлдах, иначе прикрывать объекты на спец профайле для брокера, (2) все нужные объекты связаны с Эккаунтом по М-Д и соответсвенно шерятся. Можно подумать

по первому пункту я имел ввиду что read к аккаунту пусть дает read к чайлду (можно сделать что дает сразу write - это тебе не подходит)

"есть возможность показать брокеру записи во всех чайлдах, иначе прикрывать объекты на спец профайле для брокера"
я думаю у тебя нет выбора и ты обязан "иначе прикрывать спец обьекты" пока твой обьект Detail, насколько я понимаю когда ты дашь доступ к одному чайлду, юзер автоматически получит read доступ к аккаунту, как только юзер получит доступ к аккаунту, он получит read доступ ко всем чайлдам.

Спасибо Андрей,

сразу не мог ответь, был занят с requirements gathering with the client

задача немного упростилась, по крайней мере в моей голове

сейчас создам новую тему

Single-Sign-On и организация пользователей по Эккаунтам в Коммунити

так как вопрос уже вышел за пределы просто проблем шеринга

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