Всем снова привет!
Работая разработчиком и глядя на Орг с правами сис админа я часто не осознаю, что финальный юзер не будет видеть все записи, а будет видеть только свои записи или то, что с ним расшерино. И конечно RLS - это долгая история.
Но в руки попало небольшое приложение, которое заставило меня вновь обратиться к этой теме.
Главное действующее лицо в приложение - запись Запрос, с приватным wide-org defaults.
Она может создаваться как внутри-орговым юзером, так и портальным.
Суть в том, что Запрос ни секунды не принадлежит изначальному создателю - сразу после создания владельцем записи становится Очередь, откуда запись цепляется конкурентным исполнителем и с тех пор принадлежит ему.
Довольно типичная бизнес-схема.
Так вот о RLS.
В тот период когда Запрос принадлежит конкретному исполнителю - запись доступна для него и вверх по ролевой иерархии.
В тот период когда Запрос принадлежит Очереди она расшерина с соответствующей группой через sharing rules.
Но что делать с начальным создателем записи, который тоже должен ее видеть?
Для портального заявителя это решено через специальные портальные настройки sharing sets, которые дают доступ к записям по какому-то признаку. Очень просто.
Но как быть с внути-Орговым создателем записи? было применено программное создание шеринг-записи с API name
Запрос_share, как я понял - это вариант "мануального" шеринга.
Вот так это работает. Но я не знаю - это оптимальное решение? или есть еще какие-то удобные варианты зашерить запись с создателем, если запись меняет владельца по ходу своего жизненного цикла.
спасибо
Record Level Security?)
Млин, чего у нас тогда это называли просто Sharing (типа CRUD, FLS и Sharing) если есть такое замечательное сокращение? Беру на вооружение.
Да, я так привык называть, думал, что это уже устоявшийся термин...
Расскажите про ваши случаи, бизнес-логические ситуации, когда вам приходиломь применять Объект_share запись для шеринга конкретной записи, или с другой стороны можно, например, програмно добавить Юзера в Группу которая включена в sharing rules и т.о. програмно расшерить запис(и).
Честно, не приходилось ни разу в реальности использовать.
Хотя как-то странно удивляться тому, что запись не принадлежит (со всеми вытекающими) создавшему при такой логике.
Использование Queue - частый и логичный кейс для больших бизнес приложений. И тут то и начинается party with RLS...
я не про странность использования Queue (сами делаем так в последнем проекте), я про удивление от такого поведения.
Если честно не понятно, почему создатель записи вообще должен иметь доступ?
по требованию обработчика заказа исходный заявитель может добавлять инфу в запись или аттачменты к ней.
для этого делается какой-нибудь статус "Saved as Draft" и в этом случае Owner не меняется)
А кто этот статус будет присваивать? Пользователь? Ты ему доверяешь?
Интересно, с какой целью была задействована queue. Чтобы обозначить открытый реквест?
Если в приоритете для создателя реквеста иметь к нему доступ на протяжении всего цикла, то почему бы не оставлять реквест на нем, а исполнителя прописывать в отдельное поле? Далее шарить запись среди исполнителей по критерию, упаковав их в группу.
Это так, мысли в слух. Кроме упомянутого написания кода с манул шэрингом сейчас ничего в голову не приходит, но не факт, что это будет супер оптимально в рамках развития приложения.
