Vous ne pouvez pas affecter directement des autorisations d'accès à un membre partagé. Ce dernier hérite des autorisations d'accès de son membre, parent ou ancêtre de base.
Oracle Hyperion Planning vérifie les autorisations d'accès à chaque niveau, tout d'abord au niveau de l'utilisateur, puis à celui du groupe, en fonction des autorisations d'accès héritées du membre. Si plusieurs autorisations d'accès sont en place, l'autorisation la moins restrictive est appliquée (par exemple, l'accès en écriture est prioritaire sur l'accès en lecture).
Cet exemple indique comment l'accès effectif aux membres de base et à leurs membres partagés est défini si la base de données est actualisée ou créée à l'aide des options Filtres de sécurité et Membres partagés sélectionnées dans la page Actualiser la base de données ou Créer la base de données (voir Création et actualisation des bases de données d'application).
Exemples de membres d'entité
| Entité parent | Entités enfant |
|---|---|
|
Etats-Unis |
|
|
CA (base) |
|
|
NY |
|
|
Ouest |
|
|
CA (partagé) |
|
|
NV |
|
|
Ventes - Région 1 |
|
|
CA (partagé) |
Tableau 3-2 Exemple d'accès hérité aux membres partagés
| Cas | Autorisation d'accès | Accès effectif aux membres partagés et de base CA | Explication |
|---|---|---|---|
|
Cas 1 |
CA (base) = Aucun iDescendants (Ouest) = Lecture |
Lecture |
CA hérite de l'accès en lecture de son parent West, car l'accès en lecture est moins restrictif qu'aucun accès. |
|
Cas 2 |
iDescendants (Etats-Unis) = Aucun iDescendants (Ouest) = Lecture iDescendants (Ventes - Région 1) = Ecriture |
Ecriture |
CA hérite de l'accès de son parent Ventes - Région 1, car l'accès en écriture est moins restrictif que l'accès en lecture ou aucun accès. |
|
Cas 3 |
iDescendants (Etats-Unis) = Ecriture iDescendants (Ouest) = Aucun iDescendants (Ventes - Région 1) = Ecriture |
Ecriture |
CA hérite de l'accès de son parent Etats-Unis, car l'accès en écriture est moins restrictif que l'accès en lecture ou aucun accès. |