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

Всем привет,

как вы знаете, коммунити юзера можно создать только с Контакта, который имеет Эккаунт.

Эккаунт - это фактически какая-то внешняя организация, и через Эккаунт идет шеринг ее записей для сотрудников организации, представленных в виде ее Контактов.

Таким образом привязка Контакта под определенный Эккаунт имеет ключевое значение, так как дает доступ к записям.

Ну и вопрос, каким же образом создаются подобные контакты и из них создаются коммунити юзеры?

Пока все делается вручную внутренним юзером, то все под контролем, он знает что делает.

Но если речь идет о саморегистрации коммунти юзеров? Как привязать пользователя к Эккаунту и при этом не наделать проблем? Да, пользователь может указать, к какой Организации он принадлежит, но мы не можем ему так просто верить, и взять и привязать (и дать доступ к записям). Как это все решается? Как весь этот процесс организовать БЕЗ участия внутренних пользователей (им понятно не хочется с этим возится).

У меня есть вариант решения для создания коммунити юзера через Single-Sign-On (что по логике очень похоже на саморегистрацию). Но это еще теоретический вариант, поэтому [b]выношу на обсуждение[/b].


Во момент захода в систему через Single-Sign-On нового коммунити юзера, мы не знаем к какой организации он принадлежит, и даже если он нам это скажет - мы ни за что не поверим, поэтому:

SSO JIT handler налету создает:
(1) Новый Эккаунт (рек тайп Individual, к примеру);
(2) К нему создается новый Контакт;
(3) Коммунити Юзер (Коммунити Плас лицензия);

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

Пользователь видит сообщение на домашней странице:
"Для начала работы, пожалуйста завершите оформление своего эккаунта"

Далее два варианта действий:

[b](1) Создать новую Организацию и стать ее Лид юзером.[/b]
Пользователь вводит primary key организации (номер налогоплатильщика, к примеру)и другую информацию о ней, и если такая организацию еще не создана, то его Эккаунт апдатируется новой информацией, рекорд тайп меняется на "Organization", Контакт пользователя помечается как Лид, и все: новая организация с Лид юзером создана, можно работать.

Если такая организацию уже оформлена в системе, то пользователю предлагается следующее (это и есть второй вариант действий).

[b](2) Присоединится к существующей организации как ее член или независимый брокер[/b] (опять используется primary key организации для ее безошибочного поиска. Если такая организацию внезапно еще не создана, то предлагается вариант 1).

В таком случае пользователь создает запрос (запись кастомного объекта), в котором просит присоединиться к организации. Система шлет уведомление Лид пользователю указанной организации. Лид пользователь имеет доступ ко всем запросам на присоединение к его организации, и если он с ним согласен, то:
(2-1) для нового члена организации происходит re-parenting его Контакта, Контакт привязывается к Эккаунту организации, старый удаляется, все: welcome aboard.
(2-2) для временного брокера происходит шеринг/аншеринг Эккаунта организации, брокер (оставаясь на своем Individual Эккаунт), получает доступ к записям организации и, возможно, не одной.

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