Вот такая ситуация:
пользователь должен иметь Read only доступ на определенные записи, но при этом иметь возможность редактировать те из них, у которых значениеТакогоТоПоля = такоеТоЗначение.
Object level security мы настраиваем в профайле или Пермишен сете, но это не возможно поменять "условно", в зависимости от какого то значения на поле.
Т.е. для данного профайла или Пермишен сета нужно открывать READ/WRITE access на тот объект (т.е. на все его записи, доступные данному пользователю), а потом уже как-то кастомно ограничивать возможность Редактирования некоторых записей. Please correct me if I am wrong
Но как это организовать? я не вижу стандартного поинт-энд-клик способа это решить, только кастомизация...
я пока вижу только такой вариант: пишем страницу-коммутатор, назначаем ее на стандарные view/edit лейауты, пользователь попадающий на эту страницу проверяется на профайл, если это какой-то другой профайл, то ему делается редирект на стандарный view/edit лейаут (здесь нужно добавить тот атрибут в URL иначе уйдем в петлю), а если это нужный профайл - то редирект на ВФ страницу, где проверяется значение поля на записи и в зависимости от этого рендерится сама страница, давая или не давая юзеру возможность редактирвоать запись
Не очень частый случай, но у меня обычно задачи этим не ограничиваются (много полей, зависящих от ролей/профайлов)и я пишу кастомные лайауты.
Если пойти по пути наименьшего сопротивления, то я бы сделал это в Validation Rules. Типа, если этот профиль И такое-то значение такого-то поля -> выдать ошибку о том, что у него нет прав редактировать этот объект. В VR перечислить все профили и значения полей, при которых нельзя редактировать запись.
пользователь должен иметь Read only доступ на определенные записи, но при этом иметь возможность редактировать те из них, у которых значениеТакогоТоПоля = такоеТоЗначение.
Object level security мы настраиваем в профайле или Пермишен сете, но это не возможно поменять "условно", в зависимости от какого то значения на поле.
Т.е. для данного профайла или Пермишен сета нужно открывать READ/WRITE access на тот объект (т.е. на все его записи, доступные данному пользователю), а потом уже как-то кастомно ограничивать возможность Редактирования некоторых записей. Please correct me if I am wrong
Но как это организовать? я не вижу стандартного поинт-энд-клик способа это решить, только кастомизация...
я пока вижу только такой вариант: пишем страницу-коммутатор, назначаем ее на стандарные view/edit лейауты, пользователь попадающий на эту страницу проверяется на профайл, если это какой-то другой профайл, то ему делается редирект на стандарный view/edit лейаут (здесь нужно добавить тот атрибут в URL иначе уйдем в петлю), а если это нужный профайл - то редирект на ВФ страницу, где проверяется значение поля на записи и в зависимости от этого рендерится сама страница, давая или не давая юзеру возможность редактирвоать запись
Фактически Object level security не имеет никакого отношения к записям, собственно поэтому он и называется object. Задача должна решиться с помощью sharing settings. OWD для объекта выставляется в private и дальше за счет sharing settings расширяется по определенному условию. Есть только один нюанс owners смогут редактировать все свои записи, вне зависимости от sharing settings.
здесь задача не в "Record level security" - может ли он видеть запись или нет.
Он может. Но некоторые из них он может редактировать, а другие нет.
Сценарий может быть и немного другим: вот моя собственная запись, вначале я ее могу редактировать, а с какого момента, т.е. значения в поле Статус - я уже не могу, только рид онли.
вот эта идея вначале мне показалась слишком жестокой к юзерам. Но она подкупает своей простотой (не нужны никакие кастомные лейуаты, или замены станадартных лейаутов через замены Рекорд Тайпов). Всего один станадртный лейаут и Вал рулы с вежливыми сообщениями. И для удосбвта на дитейл лайаут добавляем в топ ВФ секцию, которая "горит зеленым" если юзер может редактировать эту запись, и "красным" если запись в положении "Рид онли" для текущего юзера. Так пользователю будет понятно, что жать кнопку Эдит в данном случае бессмысленно. Что скажите?
Кто нибудь помнит есть ли criteria-based sharing rules для Комьюнити юзеров? как там расшерить запись по критерию на ней?
здесь задача не в "Record level security" - может ли он видеть запись или нет.
Он может. Но некоторые из них он может редактировать, а другие нет.
Сценарий может быть и немного другим: вот моя собственная запись, вначале я ее могу редактировать, а с какого момента, т.е. значения в поле Статус - я уже не могу, только рид онли.
вот эта идея вначале мне показалась слишком жестокой к юзерам. Но она подкупает своей простотой (не нужны никакие кастомные лейуаты, или замены станадартных лейаутов через замены Рекорд Тайпов). Всего один станадртный лейаут и Вал рулы с вежливыми сообщениями. И для удосбвта на дитейл лайаут добавляем в топ ВФ секцию, которая "горит зеленым" если юзер может редактировать эту запись, и "красным" если запись в положении "Рид онли" для текущего юзера. Так пользователю будет понятно, что жать кнопку Эдит в данном случае бессмысленно. Что скажите?
Кто нибудь помнит есть ли criteria-based sharing rules для Комьюнити юзеров? как там расшерить запись по критерию на ней?
Record level security - это не только "могу видеть/не могу видеть", это - как раз таки возможность/невозможность редактировать записи. Если пользователь должен видеть все записи - это значит, что OWD для этого объекта должен быть "public read only", а для тех записей, которым вы хотите дать ему редактировать должен отработать sharing rule c доступом - "Public Read/Write". Ситуацию с owner описал изначально выше. Так что я до сих пор думаю, что задача про "record level security" 
Это все решается через Dynamic sharing.
А какое именно преимущество даст Dynamic sharing для решения этой задачи, кроме того, что реализация займет пару дней и, навскидку, не будет работать с customer community users?
а вот это то я и забыл! у sharing rule же есть Access Level! (то есть своего рода Object level security)
тогда все выглядит просто: объект приватный, один sharing rule c доступом - "Read only" дает доступ на чтение для определнной выборки записей, а второй sharing rule c доступом - "Read\Write" - открывается редактирование более узкой группы записей внутри нашей выборки.
спасибо
а вот это то я и забыл! у sharing rule же есть Access Level! (то есть своего рода Object level security)
тогда все выглядит просто: объект приватный, один sharing rule c доступом - "Read only" дает доступ на чтение для определнной выборки записей, а второй sharing rule c доступом - "Read\Write" - открывается редактирование более узкой группы записей внутри нашей выборки.
спасибо
Не обязательно делать два рула, можете сделать объект не приватным а сразу read only (OWD) и один рул c доступом - "Read\Write". Единственный нюанс это owners - вы никак не сможете закрыть редактирование для него.
так, наверное не получится, там есть другие действующие лица\профайлы, через OWD я могу открыть им видимость записей на read only , а вот как-то ограничить видимость каких-то записей для их профайла я уже не могу
так, наверное не получится, там есть другие действующие лица\профайлы, через OWD я могу открыть им видимость записей на read only , а вот как-то ограничить видимость каких-то записей для их профайла я уже не могу
Через OWD вы ничего не откроете, тем более для профилей. Object level security и Record level security кардинально разные вещи. На профиле вы указываете CRUD для конкретного объекта (не записей).
Видимость вы можете открыть и нарушить что-то если у вас сейчас owd стоит в privateб тогда да, но повторюсь - это никак не относится к профилям.
Дмитрий, my bad, это была опечатка, имеются ввиду не профайлы, а Группы юзеров. большинство групп имеют право видеть записи только по какому-то признаку на записи, то есть нельзя открыть OWD на Паблик.
И это верно, что ты обратил внимание на:
есть именно такая ситуация: owner создал запись, и в какой-то момент жизненного цикла записи (Статус - В обработке, например), у него должен быть только Read Only доступ к своей собственной записи. как это организовать?
и еще ситуация, на FLS: есть два юзера с одним профайлом. Один из них создал запись и видит 10 полей и дочерние записи, а второй юзер тоже имеет право видеть саму запись, но только 5 полей на ней и без дочерних записей. мы не можем назначить им разные профайлы или Пермишен сеты. как это организовать?
