Gestion des accès concurrents aux rapports sous Deski ?

[Demangef]

Bonjour à tous,

petit problème :
Soit un rapport BO nommé XY exporté sur le référentiel.
Soit 2 utilisateurs A et B.

A importe le rapport XY dans Deski, le modifie. 1 minute après B importe le même rapport et le modifie. B exporte sur le référentiel, puis A fait de même.

Ben là B s'enerve parce que ses modifications n'ont servi à rien.

Voilà c'est tout bête est-ce qu'il y a un moyen d'empêcher un accès simultané de 2 utilisateurs à un rapport sous Deski ??
Ou au moins de prévenir l'utilisateur B qu'il est déjà ouvert par l'utilisateur A ?

Merci !!

[eryk71]

Bonsoir,

Il suffit de dire aux utilisateurs lorsqu'ils importent l'univers, de doulbe sur celui-ci lors de l'import. Il y aura un cadenas dessus qui verouilleras l'univers.
Après l'exportation, il suffit de faire la même manipulation pour déverouiller.

Par contre, si un utilisateur oublie de dévérouiller, l'univers restera verouiller même après l'exportation. Un utilisateur appartenant au groupe administrateur peut bien sur le déverouiller.

[Demangef]

Il me semble que tu me parles de Designer là nan ?

Mon problème se situe au niveau de Desktop intelligence, il faudrait le même mécanisme, mais pour un document.

C'est possible ?

Merci

[eryk71]

Oui, je parlais sur le Designer.

Pour DESKI, c'est en cours de reflexion

[Demangef]

Comme on dirait chez nous
Merchi

[mbarka]

Bonjour,

Sous BOXIR2 sp2, je viens de faire l'essai et je constate qu'il n'existe pas de moyen dans Desktop Intelligence de verrouiller, à l'instar de Designer, un objet importé. Le verrouillage se fait pas l'intermédiaire des droits en écriture dans les dossiers. Toutefois, il faut peut-être penser à une organisation dans les développements afin d'éviter le problème énoncé.

Ce que j'ai pu voir :
- posséder un portail de développement, identique à celui de production, et dans lequel les utilisateurs publient leur modification. Un spécialiste de l'équipe informatique vérifie si les modifications et développements sont conformes aux normes en vigueur et envoi lui-même le rapport en production. En général, les modifications sont effectuées par l'utilisateur qui demande ensuite la publication sur le portail de production et, le cas échéant, la planification de son exécution. Par comparaison entre la production et la dév., le spécialiste est à même de voir si les modifications peuvent impacter fortement la destination du document.
- Chaque modification est validée par un "administrateur" fonctionnel, ayant des droits avancés sur le dossier de son service, et qui est le seul à pouvoir écrire dans le dossier cible. Le portail de développement n'est alors plus nécessaire. On s'en remet à une personne de confiance.

Bref, ce sont les autorisations sur les dossiers qui peuvent éviter le pire.

J'en ai pas d'autre en tête mais on peut en imaginer pas mal.

Ce sont des cas classiques rencontrés en clientèle. Je suggère l'utilisation d'un outil qui canalise toutes ces demandes de modifications et ne pas autoriser n'importe qui à publier des documents (BO ou autres).

J'ai un peu brodé mais c'était pour la bonne cause.

Bien à vous.
Mehdi

[eryk71]

Merci Mehdi pour ta réponse

Il est vrai que la gestion des droits sur le dossier peut être une solution.

On peu envisager par exemple un système qui permettra que lorsque un utilisateur ouvre un rapport, celui-ci se met en lecture seule.
Ainsi si un autre utilisateur se connecte sur le rapport, il ne pourra pas enregistrer.

En manuel, clic droit sur le rapport.rep, propriété, onglet général, coché "lecture seule".

Bien sur si un malin le décoche ben ça casse tout. Mais bon c'est pour donner un idée de départ

[Bruno2r]

Mehdi, c'est toujour un vrai bonheur de te lire

Je trouve que vous vous compliquez la chose avec la gestion des dossiers en réponse au problème posé :
Ecrasement de la modif de A lors de l'envoi au référentiel par B.
Mehdi a parfaitement raison de proposer une validation par un Administrateur seul habilité à insérer dans le Référentiel.
Mais pour obtenir cela ne suffit il pas dans la CMC
Accueil > Applications BusinessObjects Enterprise > Desktop Intelligence >

Droits détenus par le groupe "Tout le monde" pour l'objet "Desktop Intelligence" :
Envoyer des documents au référentiel : Refusé

et de réserver ce droit aux administrateurs ?

[eryk71]

Droits détenus par le groupe "Tout le monde" pour l'objet "Desktop Intelligence" :
Envoyer des documents au référentiel : Refusé
et de réserver ce droit aux administrateurs ?

D'après la question initale, j'avais compris qu'il ne devait pas avoir une tierce personne (l'administrateur) et que les 2 utilisateurs voulaient rendre accessible leur rapport.

[Bruno2r]

Envoyé par eryk71

D'après la question initale, j'avais compris qu'il ne devait pas avoir une tierce personne (l'administrateur) et que les 2 utilisateurs voulaient rendre accessible leur rapport.

Certes mais il faut faire des choix ...
L'organisation préconisée par Mehdi est professionnelle.
Nous savons très bien par expérience que les rapports enregistrés par les utilisateurs sur leur disque représente une masse énorme (inavouable) de documents à migrer le moment venu.
Donc liberté totale en local, mais procédure de validation avant intégration dans le référentiel par un Admin. Cerise sur le gateau ça permet aussi de vérifier les droits d'accès aux infos et les catégories.