Доброго дня.
Задача такая:
Есть запись у кастомного объекта. Юзер "A" её создал и может что угодно сделать.
Есть юзер "B" у которого профили настроены так, что он ее видеть не может.
Задача, сделать так что бы он мог ее увидеть и изменить.
Знаю что можно заюзать вот это.
Но вот не совсем понимаю как это сделать на деле(
По сути надо зинсертить SharingRecord, в которой будет указано что данный юзер может ее редактировать.
А вот как правильно это сделать,я не совсем догоняю.
может мне кажется, но твоя проблема решается проще.
Видимость записей (а не их полей) определяется:
(1) OWD - организайшн-вайд дефолт - тут как понимаю объект Приватный.
(2) Ролями пользователя - вертикальная видимость - если включена
(4) Шеринг рулсами которые определяет ЛОгику видимости и к какой категории юзеров (по роли, группе, индивидуально)эта логиика применяется (если у записи рек тайп "Восток" - то видят все кто в роли "сотрудники Восток").
есть еще более тонкие настройки, в том числе какие новые настройки Персонал шеринг (что-то вроде того).
на некоторых стандартных объектая есть спец кнопки связынные с шерингом - они описывают типичные ситуации шеринга.
ВОзможно тебе просто нужно настроить Роли и шеринг рулсы? об этом есть и Верхаус и в Рекрутинг ворбуках, плюс тоже самое еще раз в Секюрити воркбкук.
Настройки шаринга и приватности не подойдут((
Надо заюзать именно это "таблицу шаринга". Что бы открыть доступ именно для этой записи, и только для нее.
Опишу цепочку.
Есть Юзер A с ролью Role и профилем Profile
Есть Юзер B с ролью Role2 и профилем Profile2
Юзер А создает запись кастомного обьекта.
Юзер В должен видеть это запись, который создал Юзер A, но не должен видеть другие записи созданные юзерами с таким же ролью Role и профилем Profile.
Тоесть посути надо расшарить определённую запись на определённого юзера.
:):):):):):):):):):):):):)
И опять отвечу сам себе) Все оказалось очень легко!!!
Coaching_Form__Share hiringManagerShare = new Coaching_Form__Share();
hiringManagerShare.ParentId = 'a0mc0000002L6cy'; // ИД записи
hiringManagerShare.UserOrGroupId = '005E0000000dlL3'; // ИД юзера
hiringManagerShare.AccessLevel = 'edit'; // Что он может для этой записи!
Database.insert(hiringManagerShare,false);
ну это что-то новое для меня.
АйДи наверное лучше кверить по какомуто признаку (имя пользователя, название записи) - этот признак, по которому кверится, можно даже вынести в Кастом сеттинг если предполагается, что возможно изменения. Тогда код будет даже "гибчее".
PS: из условия примера выше мне показалось, что речь идет об единичном случае шеринга (поэтому я упомянул, что что АйДи лучшенужно кверить и прочее). Но наверное я ошибаюсь, наверное такой "програмный" шеринг делается для описание какой-то уникальной логики шеринга для всех вновь создаваемых записей, на которые эта логика распространияется.
Тогда такой код пойдет в тригер. Я правильно понял?
Очень распространенная задача:
решается с помощью sharing. Для объекта естественно должно стоять Private.
(отдельный вопрос роль не/подчиненная и шарится ли записать автоматом по иерархии ролей)
если запись не шарится по иерархии, то запись созданная A не будет видна B - чтобы расширить есть 3 пути:
1. кнопка Shanring на Standard layout
2. Sharing Rules
3. code sharing
первые 2 понятны, третий вот пример:
MyObject__Share MyObjectShare = new MyObject__Share ();
MyObjectShare.ParentId = <record.Id>;
MyObjectShare.UserOrGroupId = <user.Id>;
MyObjectShare.AccessLevel = <level>;
insert MyObjectShare;
