| Печать Открыть версию интерактивной справки в формате PDF

#### Пример 1. Использование уровня доступа "Просмотр" В этом разделе рассматривается один пример вычисления в Oracle CRM On Demand прав доступа пользователей. В этом примере Аманда Якобсен имеет роль продавца. Аманда может создавать новые организации и видеть все другие записи организаций. Ей разрешено создавать возможности, но она может видеть только возможности, владельцем которых она является или на просмотр которых у нее есть соответствующее разрешение. В следующей таблице показаны параметры настройки типа записи в роли продавца.
Тип основной записи | Имеет доступ | Можно создать | Можно прочитать все записи
--- | --- | --- | ---
Субъект | Да | Да | Да
Возможность | Да | Да | Нет
Роль продавца обеспечивает Аманде полный контроль над создаваемыми ею организациями и возможностями и ограничивает ее права на работу с записями, владельцем которых она не является. Для роли продавца требуются два профиля доступа: профиль доступа владельца и профиль доступа по умолчанию. В следующей таблице показаны параметры настройки профиля доступа владельца для продавца.
Тип основной записи | Уровень доступа | Тип связанной записи | Уровень доступа
--- | --- | --- | ---
Субъект | Чтение/Изменение/Удаление | Возможности | Просмотр
Возможность | Чтение/Изменение/Удаление | Не применимо | Не применимо
В следующей таблице показаны параметры настройки профиля доступа по умолчанию для продавца.
Тип основной записи | Уровень доступа | Тип связанной записи | Уровень доступа
--- | --- | --- | ---
Субъект | Только чтение | Возможности | Просмотр
Возможность | Только чтение | Не применимо | Не применимо
В данном примере расчета прав доступа предполагается, что наследование команды для типа записи "Возможность" не включено, т. е. флажок "Включить наследование родительской команды для возможности" на странице профиля компании снят. Дополнительные сведения о функции наследования родительской команды см. в разделе Распространение доступа с помощью наследования команд. Дэвид Блум также имеет в компании роль продавца и те же права доступа, что и Аманда. и те же права доступа, что и Аманда. Аманда является владельцем возможности X, связанной с организацией 1. Дэвид создает возможность Y и также связывает ее с организацией 1. Аманда не является участником команды для возможности. Когда Аманда просматривает список организаций в ее компании, она может видеть все организации, поскольку ее роль обеспечивает ей возможность видеть все организации, в том числе те, владельцем которых она не является. В следующей таблице показаны записи, которые увидит Аманда, если щелкнет имя "Организация 1" для детализации записи. В этом примере показаны только значимые поля и столбцы.
Сведения об организации: организация 1
Сведения об организации
Имя организации: | Организация 1
Владелец: | Джонатан Хоуп
Возможности
Имя возможности | Владелец
Возможность Х | Аманда Якобсен
Возможность Y | Дэвид Блум
Команда субъекта
Фамилия | Имя | Доступ к субъекту
Хоуп | Джонатан | Владелец
#### Просмотр связанной записи в примере 1 Чтобы определить, какие связанные записи возможности для организации сможет увидеть Аманда в этом примере, Oracle CRM On Demand проверяет права доступа Аманды следующим образом: В Oracle CRM On Demand все применимые уровни доступа для типа связанной записи для возможности в этой записи родительской организации проверяются следующим образом: ПРИМЕЧАНИЕ. Если в разных компонентах управления доступом обнаруживается несколько уровней доступа, все они учитываются при вычислении прав доступа. Определяется, является ли Аманда владельцем родительской организации. В данном примере – нет Определяется, позволяет ли роль Аманды читать все записи организаций. В этом примере – да. Роль Аманды позволяет ей читать все записи организаций, поэтому Аманда может просматривать организацию. Поскольку Аманда не является владельцем родительской организации, используется ее профиль доступа по умолчанию. В профиле доступа по умолчанию для Аманды задан уровень доступа для типа связанной записи возможности "Просмотр". Определяется, относится ли родительская запись к книге, участником которой является Аманда. В данном примере – нет Определяется, является ли Аманда участником команды для организации. В данном примере – нет Определяется, является ли кто-то из подчиненных Аманды (прямых или косвенных) участником команды организации. В данном примере – нет Если ответ на этот вопрос – "да"·(то есть один или несколько подчиненных Аманды является участником команды организации), Oracle CRM On Demand извлекает уровень доступа для типа связанной записи возможности для каждого из этих подчиненных из соответствующего профиля организации. В этом случае используется поле "Доступ к организации" из участия в команде подчиненного (не профиль доступа, назначенный в поле "Доступ к возможности"). Определяется, имеет ли Аманда доступ к записи организации через делегирование. В данном примере – нет Затем в Oracle CRM On Demand происходит следующее: Определяется, обеспечивает ли роль Аманды базовый доступ к записям возможностей. В этом примере – да, поскольку в роли пользователя для типа записи "Возможность" установлен флажок "Имеет доступ". Определяется, дает ли роль Аманды полномочия для типа записи возможности. Полномочия не позволяют управлять возможностями, поэтому в этом примере полномочия не влияют на вычисление прав доступа Аманды. Определяется, не задан ли в каком-либо профиле доступа, включенном в вычисление, уровень доступа "Наследование основного объекта" или одна из его комбинаций. В данном примере – нет Затем в Oracle CRM On Demand проверяются все найденные уровни доступа и определяется наиболее разрешительный уровень. В данном случае наиболее разрешительный уровень доступа из найденных "Просмотр". Уровень доступа "Наследование основного объекта" отсутствует, поэтому отображаются все дочерние записи возможностей, включая те, для которых у пользователя нет разрешения на просмотр. #### Действия со связанными записями в примере 1 Когда пользователь пытается выполнить действие со связанной записью, Oracle CRM On Demand должен определить, имеет ли пользователь соответствующие права доступа для этого действия. В этом примере Аманда может попытаться прочесть сведения о записи, изменить или удалить запись. Рассмотрим два случая. В случае 1 Аманда пытается выполнить действие с возможностью X. В случае 2 Аманда пытается выполнить действие с возможностью Y. Случай 1. Аманда пытается выполнить действие с возможностью X, владельцем которой она является. Права доступа Аманды проверяются в Oracle CRM On Demand следующим образом: В Oracle CRM On Demand все применимые уровни доступа для типа связанной записи для возможности в этой записи родительской организации проверяются следующим образом: ПРИМЕЧАНИЕ. Если в разных компонентах управления доступом обнаруживается несколько уровней доступа, все они учитываются при вычислении прав доступа. Определяется, является ли Аманда владельцем родительской организации. В данном примере – нет Определяется, позволяет ли роль Аманды читать все записи возможностей. В этом примере – нет. Хотя Аманда может просматривать запись родительской организации, поскольку используется ее профиль доступа по умолчанию, для записи возможности ее профиль по умолчанию не используется. Определяется, относится ли запись возможности к книге, участником которой является Аманда. В данном примере – нет Определяется, является ли Аманда участником команды ля возможности. В этом примере – да. Аманда является владельцем возможности и, соответственно, участником команды для возможности. Уровень доступа для типа основной записи возможности из профиля доступа Аманды по умолчанию (профиль доступа по умолчанию для продавца) имеет значение "Чтение/Изменение/Удаление". Определяется, является ли кто-то из подчиненных Аманды (прямых или косвенных) участником команды для возможности. В данном примере – нет Определяется, имеет ли Аманда доступ к записи организации через делегирование. В данном примере – нет Затем в Oracle CRM On Demand происходит следующее: Определяется, обеспечивает ли роль Аманды базовый доступ к записям возможностей. В этом примере – да, поскольку в роли Аманды для типа записи "Возможность" установлен флажок "Имеет доступ". Определяется, дает ли роль Аманды полномочия для типа записи "Возможность". Полномочия не позволяют управлять записями с типом "Возможность". Поэтому в этом примере полномочия не влияют на вычисление прав доступа Аманды. Определяется, не задан ли в каком-либо профиле доступа, включенном в вычисление, уровень доступа "Наследование основного объекта" или одна из его комбинаций. В данном примере – нет Затем в Oracle CRM On Demand проверяются все найденные уровни доступа и определяется наиболее разрешительный уровень. В данном случае наиболее разрешительным является уровень доступа "Чтение/Изменение/Удаление". Случай 2. Аманда пытается выполнить действие с возможностью Y, владельцем которой является Дэвид Блум. Права доступа Аманды проверяются в Oracle CRM On Demand следующим образом: В Oracle CRM On Demand все применимые уровни доступа для типа связанной записи для возможности в этой записи родительской организации проверяются следующим образом: ПРИМЕЧАНИЕ. Если в разных компонентах управления доступом обнаруживается несколько уровней доступа, все они учитываются при вычислении прав доступа. Определяется, является ли Аманда владельцем родительской организации. В данном примере – нет Определяется, позволяет ли роль Аманды читать все записи возможностей. В этом примере – нет. Хотя Аманда может просматривать запись родительской организации, поскольку используется ее профиль доступа по умолчанию, для записи возможности ее профиль по умолчанию не используется. Определяется, относится ли запись возможности к книге, участником которой является Аманда. В данном примере – нет Определяется, является ли Аманда участником команды ля возможности. В данном примере – нет Определяется, является ли кто-то из подчиненных Аманды (прямых или косвенных) участником команды для возможности. В данном примере – нет Определяется, имеет ли Аманда доступ к записи организации через делегирование. В данном примере – нет Затем в Oracle CRM On Demand происходит следующее: Определяется, обеспечивает ли роль Аманды базовый доступ к записям возможностей. В этом примере – да, поскольку в роли Аманды для типа записи "Возможность" установлен флажок "Имеет доступ". Определяется, дает ли роль Аманды полномочия для типа записи "Возможность". Полномочия не позволяют управлять записями с типом "Возможность", поэтому в этом примере полномочия не влияют на вычисление прав доступа Аманды. Определяется, не задан ли в каком-либо профиле доступа, включенном в вычисление, уровень доступа "Наследование основного объекта" или одна из его комбинаций. В данном примере – нет Затем в Oracle CRM On Demand проверяются все найденные уровни доступа и определяется наиболее разрешительный уровень. В данном случае окончательным уровнем доступа будет уровень "Чтение/Изменение/Удаление". #### Связанные темы Дополнительные примеры см. в следующих разделах. Пример 2. Использование уровня доступа "Наследование основного объекта" Пример 3. Защита данных с помощью книг

Опубликовано в Август 2022 | Copyright © Oracle и/или ее дочерние компании, 2005, 2022. Legal Notices.