Discussion :

[Zygomatic]

Bonjour,

Dans un classeur Excel disponible en mode partagé sur le réseau interne de mon travail, je souhaiterais pouvoir récupérer via code vba l'attribut lecture seule ou non lié aux droits donnés à chaque utilisateurs sur le réseau et non au propriétés de mon fichier.

Je m'explique:
Le fichier n'a aucun attribut dans ce sens.
Chaque utilisateur de windows, selon son poste va avoir des droits d'accès différents aux différents dossiers du réseau.
Mon fichier se trouve dans un dossier ou le Groupe X n'a que des droits en lecture dans ce répertoire et un groupe Y qui aura les droits en lecture / écriture (dans la réalité Y appartient à X mais pour la facilité de compréhension, on va dire que ces groupes sont différents)

Lorsque qu'un utilisateur du groupe X ouvre le classeur excel du dossier concerné par cette gestion de droits le titre du fichier apparaît ainsi dans la bande du haut :

Titre [Lecture Seule].xlsm

(gestion des droits effectuée via l'Active Directory de Windows et session enregistrées sur un domaine)
L'utilisateur peur consulter le fichier, utiliser les macros, mais ne pourra pas enregistrer les modifications apportées

Lorsqu'un utilisateur du groupe Y ouvre ce même classeur il n'y a plus l'attribut lecture seule entre crochet juste après le titre et l'utilisateur pourra sauvegarder son travail.


Je souhaite mettre en place certaines macros de sauvegarde ou d'enregistrement de certains paramètres et pour éviter d'avoir des erreurs d’exécution ou des popups d'avertissement, je souhaiterai faire un test avant exécution afin de vérifier si le fichier est en lecture seule ou nom.
Les recherches que j'ai fait sur le sujet dans ce forum ou d'autres me renvoi sur l'attribut lecture seule concernant les propriétés du fichier. alors que ce que je recherche, ce sont les droits donnés à l'utilisateur par Windows au moment de l'ouverture.
Peut être que l'attribut est le m^me, mais ne développant pas sur mon lieu de travail, je ne suis pas en mesure de le tester

Par la suite, je créerai une recupération de l'username des ayants droits pour les incrementer dans une partie de ma base de données ce qui me permettra de reconnaître chaque utilisateur du groupe Y pour leur attribuer un profil différent avec des droits aux petits oignons sur des parties spécifiques de mon fichier (ex affichage personnalisé d'une BDD,...)
Bref ça c'est une des nombreuses étapes de mon dev :p

[Pierre Fauconnier]

Salut.

Je ne suis pas un spécialiste de l'Active Directory, mais tu ne trouveras pas ce que tu cherches dans le VBA natif d'Excel, à mon avis. Peut-être que des librairies ou api Windows permettent de se connecter à l'active directory pour récupérer ces données. Encore faudra-t-il que l'utilisateur qui utilise ton fichier ait des droits d'accès en lecture sur l'AD, ce dont je doute fortement.

Au delà de ça, je conseille toujours d'abandonner le partage des classeurs Excel, surtout dans l'usage que tu veux en faire avec une gestion de l'enregistrement des versions de fichier par VBA. C'est à mon avis suicidaire. Si tu as ce genre de besoin de partage de données, tu devrais te tourner vers d'autres solutions plus fiables en terme de partage et de droits sur les données. Excel n'est pas l'outil approprié pour ce genre de traitement.

[Zygomatic]

Merci Pierre.

Oui, je suis bien conscient qu'Excel n'est pas l'outil le plus approprié pour faire ce type de travail, mais je l'ai choisi, comme beaucoup d'amateurs ici, pour son accessibilité.
On commence souvent par un vulgaire tableau, qu'on enrichi au fur et à mesure
On rajoute des formules qui font des supers calculs
Puis des mise en forme conditionnelles, puis un peu de filtre et de Tri...
Puis un jour on est limité et voilà que le VBA vient à notre secours et nous élargit complètement notre univers
Et comme il est (assez) facile d'accès, on arrive tout de suite à faire quelque chose qui fonctionne (parfois voire souvent de façon bancale, mais on y arrive).
Et comme on en veut toujours plus, on finit par avoir un une usine à gaz instable ! C'est une triste réalité dont j'ai parfaitement conscience, mais hélas, je n'ai ni les compétences, ni le temps requis pour m'initier à un langage plus adapté (PhP, MySQL et CSS) j'ai pourtant essayé quelques approches, mais c'est beaucoup trop long avant d'avoir quelque chose d'exploitable surtout en comparaison à l'instantanéité d'EXCEL

Pour en revenir à me requête, je me disais que , dans la mesure où Excel affiche une informations supplémentaire à côté du titre, c'est qu'il est donc en mesure de reconnaître ce paramètre ou cet attribut. Et par conséquent je me dis que cela doit bien être récupérable quelque-part !!!

[Pierre Fauconnier]

Pourquoi une appli Web en php et autre? Un fichier Access serait déjà une approche très intéressante.


Toutefois, je crois mieux comprendre, mais j'ai été égaré par ton passage sur l'AD...

Tu pourrais à mon avis t'inspirer de ceci, qui renvoie TRUE lorsque le dossier est en lecture seule.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Function IsReadOnly(FolderName As String) As Boolean
  Dim fso As Object
  Dim f As Object
 
  Set fso = CreateObject("scripting.filesystemobject")
  Set f = fso.GetFolder(FolderName)
  IsReadOnly = f.Attributes And ReadOnly
  Set fso = Nothing
End Function

Un peu de lecture sur la gestion des disques, dossiers et fichiers...

[Zygomatic]

Effectivement, j'ai hésité à mettre le passage sur l'AD, mais je voulais illustrer le fait que ce n'était pas le fichier ni me^me le dossier qui avait cet attribut intrinsèquement mais que c'était l'utilisateur qui avait ou non des droits sur le classeur.
Pour ce qui est d'Access, il n'est pas déployé à mon travail (ni le logiciel pour créer la BDD, ni le runtime pour utiliser le fichier) de plus, je ne connais pas vraiment ce logiciel, même si, je me doute, il est plus abordable qu'un tout autre langage lorsque connait quelques bribes de VBA.

Si je comprend la fonction que tu me donnes, il faut que j'aille l'appeler dans une sub pour vérifier le chemin du dossier dans lequel est hebergé le fichier et elle me donnera ainsi l'attribut du dossier (lecture seule si VRAI ou lecture/écriture si FAUX) . C'est ça ?

J'avais déjà trouvé ce type de procédure (sans passer par une fonction me semble-t-il) lors de mes recherches avant de poster sauf qu'elles allaient chercher dans les propriétés du fichier au lieu de celles du dossier parent.

Peut-être que ta procédure fonctionne et comme dit dans mon premier poste, je ne peux pas la tester en dehors du réseau interne de mon travail.

Comme souvent, lorsque l'on ne connaît pas une procédure, on imagine quelque chose, et les solutions proposées ne correspondent pas toujours à ce à quoi on s'attendait, bien qu'elles puissent parfaitement convenir.

En y réfléchissant, vu qu'il semble difficile voir impossible de récupérer l'attribut qui provoque l'affichage "[Lecture Seule]" du classeur directement au sein d'Excel (Workbook attribut readonly = true ) sans aller chercher dans les propriétés d'un fichier, je me dis que je pourrais me recentrer sur l'effet à obtenir et non le moyen d'y parvenir !

Y aurait-il une solution qui me permettrait de verifier si l'utilisateur a la possibilité d'enregistrer sans générer de boite de dialogue dans un cas comme dans l'autre (si enreg possible ou non) ?

[Pierre Fauconnier]

Dans la mesure où le fichier est partagé (et donc pas en mode ReadOnly), je ne vois que ma fonction (ou une autre avec ou sans FSO, ce pourrait être via une api) pour déterminer que le dossier contenant le fichier est en lecture seule ou non. Il suffit de passer le chemin du fichier à la fonction pour savoir si le dossier contenant est ReadOnly ou pas. Sauf possibilité très hypothétique de gratter dans l'AD, je ne vois pas d'autre chemin.

L'intérêt de la fonction est que

• tu ne pollues pas le code principal par ce test;
• tu peux la récupérer facilement pour d'autre projets;
• elle travaille en late binging sur la librairie Scripting pour éviter de devoir la référencer dans les projets qui l'utilisent.

[Zygomatic]

Ok Pierre,

Voyons donc si j'ai bien compris :

Je copie ta fonction dans un module,
Je copie le chemin le dossier que je souhaite tester sur une feuille de mon classeur, dans une cellule que je renomme "rgeChemin"
puis je fais une macro du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Sub TestReadOnly() 
 
    MsgBox IsReadOnly(Range("rgeChemin").value)
    'VRAI = Lecture seule et FAUX = Lecture/écriture
 
End Sub

Si ça fonctionne, alors je peux me servir de cette fonction pour l'intégrer dans une procédure If Then.

Mon raisonnement et ma synthaxe sont ils bons ?

[Pierre Fauconnier]

C'est tout à fait cela. C'est pour cela que je privilégie l'utilisation d'une fonction à l'intégration du code au sein de la procédure principale.

Cette fonction, tu peux d'abord la tester, la renforcer au besoin (ici, dans le code donné, je pars du principe que le chemin existe et je n'ai pas mis le code de test de l'existence du dossier, mais on peut peaufiner, à l'intérieur de la fonction, c'est un des avantages de travailler avec une fonction et un couplage faible de la fonction avec le reste du code) puis l'intégrer dans le code fonctionnel de l'appli en testant simplement le retour de la fonction. Tu peux l'améliorer par la suite sans dommages collatéraux, du moment qu'elle reçoive toujours en entrée le chemin du dossier à tester et retourne en sortie une valeur booléenne. C'est, parmi d'autres, un énorme avantage de développer par fonctions.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Sub Main()
    Dim PathName as string
    ...
    ...
    If IsReadOnly(PathName) Then ' Dossier en lecture seule
        ...
        ...
    Else ' Dossier en lecture/Ecriture
        ...
        ...
    End If

De plus, cette fonction pourrait trouver sa place dans un module Tools embarquant plusieurs fonctions génériques non liées spécifiquement à l'application que tu développes. Tu te constitues ainsi un bac à outils que tu embarques systématiquement dans tes développements et tu évites de réinventer la roue à chaque nouveau fichier. Programmer de cette façon va sécuriser tes développements et te faire gagner beaucoup de temps.

[Zygomatic]

Super, merci pour le code et la petite partie de pédagogie. je vais essayer de garder cela à l'esprit.

Je dois retourner au boulot dans la semaine, je testerai entre autre cette partie et reviendrai ici marquer le topic comme résolu,... ou non

[eriiic]

Bonjour,

J'espère ne pas dire de bêtise en disant que c'est une fausse question. On me détrompera au besoin.
Quelque soit la cause (attribut fichier, droit en lecture seule sur répertoire, lecture seule gérée par excel) à partir du moment où tu as read only tu auras des soucis pour enregistrer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

If ThisWorkbook.ReadOnly Then MsgBox "c'est mort"

non ?

A moins que tu désires gérer également des copies auquel cas il faut connaitre les droits sur les répertoires.
Eventuellement pour tes tests tu peux te modifier les droits sur un répertoire, pas besoin de réseau.
eric

[Zygomatic]

Bonsoir,
Les utilisateurs qui sont en lecture seule savent qu'ils ne peuvent pas enregistrer mais justement le fait de faire le test permettra de les cibler et par exemple d'executer un code permettant de simuler à Excel que l'enregistrement a été fait. Ainsi si des modifications ont été faites (modification d'ordre visuelle type classement ou filtre) Excel ne proposera pas d'enregistrement.

Ainversement, pour ceux qui ne sont pas en lecture seule, je compte proposer des fonctions avancées (l'idée serait de proposer l'enregistrement d'un profil visuel permettant si desiré d'avoir un tri/filtre personnalisé à l'ouverture du planning)
C'est un exemple. Je verrai ce qui est faisable sans que ça n'alourdisse de trop le fichier et son fonctionnement.

[eriiic]

Bonjour,

Je ne te parle pas des utilisateurs. Toi, tu ne peux pas utiliser ThisWorkbook.ReadOnly ?
eric

[Pierre Fauconnier]

Eric, je suis comme toi. Actuellement, je n'ai pas encore compris pourquoi thisworkbook.readonly n'est pas suffisant...

[Invité]

Bonjour,
Je rebondi sur les remarques de mes prédécesseurs, Excel dispose de l'information lecture seul!

Si l'idée est d'interdire la sauvegarde en lecture seule pour quelque raisons que ce soit...

Il est possible d'interroger l'active directory en Vba, mais dans le sujet qui nous préoccupe quel en serait l'intérêt?

Autorisé l'affichage de telle ou telle feuille? Exécuter telle ou telle macro?

Détails un peut plus la finalité!

[Zygomatic]

Eric, je suis comme toi. Actuellement, je n'ai pas encore compris pourquoi thisworkbook.readonly n'est pas suffisant...

Merci Pierre et Eric
J'ai pu tester le code à partir de dossiers locaux que j'ai protégé en lecture seule (pour l'un et pas pour l'autre) après y avoir copié le fichier à l’intérieur et ça fonctionne très bien même avec thisworkbook.readonly
En fait j'étais persuadé que cette propriété concernait le fichier intrinsèquement et non pas l'état dans lequel il est à l'ouverture.
Le code pour tester le dossier n'est pas perdu, car il pourra me servir pour des macros de sauvegardes vers d'autres répertoires que celui de travail

Bonjour,
Je rebondi sur les remarques de mes prédécesseurs, Excel dispose de l'information lecture seul!

Si l'idée est d'interdire la sauvegarde en lecture seule pour quelque raisons que ce soit...

Il est possible d'interroger l'active directory en Vba, mais dans le sujet qui nous préoccupe quel en serait l'intérêt?

Autorisé l'affichage de telle ou telle feuille? Exécuter telle ou telle macro?

Détails un peut plus la finalité!

Bonsoir dysorthographie , merci de te pencher aussi sur ma demande.
Pour répondre à ta question sur la finalité de ma requête, je pensais avoir donné assez d'information dans la fin de mon 1er post

Je souhaite mettre en place certaines macros de sauvegarde ou d'enregistrement de certains paramètres et pour éviter d'avoir des erreurs d’exécution ou des popups d'avertissement, je souhaiterai faire un test avant exécution afin de vérifier si le fichier est en lecture seule ou nom.
Les recherches que j'ai fait sur le sujet dans ce forum ou d'autres me renvoi sur l'attribut lecture seule concernant les propriétés du fichier. alors que ce que je recherche, ce sont les droits donnés à l'utilisateur par Windows au moment de l'ouverture.
Peut être que l'attribut est le m^me, mais ne développant pas sur mon lieu de travail, je ne suis pas en mesure de le tester

Par la suite, je créerai une recupération de l'username des ayants droits pour les incrementer dans une partie de ma base de données ce qui me permettra de reconnaître chaque utilisateur du groupe Y pour leur attribuer un profil différent avec des droits aux petits oignons sur des parties spécifiques de mon fichier (ex affichage personnalisé d'une BDD,...)
Bref ça c'est une des nombreuses étapes de mon dev :p

Donc pour être peut être un peu plus précis :
Test si lecture seule pui :
- Si non, alors basta, je ne m'occupe pas d'eux car leur intérêt est juste de consulter les informations dans le fichier, mais il garde quand même l'accès aux fonctionnalités de tri, filtre par macro.
- S'ils ne sont pas en lecture seule, les ayants droits, ceux qui remplissent et mettent donc à jour le fichier, pourront sauvegarder sur proposition (liée à cet attribut lecture seule ou non) certains paramètres sur une feuille de calcul cachée, comme par exemple la configuration visuelle de leur choix (tri-filtre) afin qu'elle soit rappelée à l'ouverture du fichier. De plus ces utilisateurs pourront déclencher des backups du fichiers dans d'autres dossiers dans lesquels il y a encore plus de restriction, donc les 2 procédures (dossier et fichier) qui m'ont été données ici me seront utiles.

Merci encore à tous, je peux maintenant marquer ce Topic [Résolu]