Limiter accès utilisateurs

Le
toggy Hors ligne
Bonjour,
J'ai créé une base donnée sur ACCESS 2007,
afin de pouvoir gérer des comptes utilisateurs j'ai enregistrer en version 2003.

Cette BDD consiste à regrouper l'ensemble des commandes en cours. Afin de permettre un suivi interne, j'ai créé des champs dans lesquels figure le nombre de pièce pour chaque pièce dans chacun des ateliers (ex: 3 pièces en atelier 1, 5 en atelier 2 etc)
Je souhaiterais que chaque responsable d'atelier entre le nombre de pièce pour chacune des commande.
Ainsi, j'ai créer un formulaire correspondant à chacun des ateliers.
Afin de limiter les risques d'erreur (qu'un responsable remplisse une case qui ne lui est pas destiné) je souhaiter que chaque responsable ait seulement accès au formulaire qui lui est dédié.

Or, si je lui bloque l'accès à la table, il ne peut pas modifié son formulaire, et au contraire si je lui donne l'accès à la table il peut alors modifié à la fois la table et les formulaires des autres responsables.

Auriez vous une alternative? Ou une solution à mon problème???

Merci d'avance
Toggy
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gloops
Le #24326061
toggy a écrit, le 15/03/2012 10:49 :
Or, si je lui bloque l'accès à la table, il ne peut pas modifié s on formulaire,
et au contraire si je lui donne l'accès à la table il peut alors mo difié à la
fois la table et les formulaires des autres responsables.



Bonjour,

(j'ai élagué dans la citation car le serveur que j'utilise est écon ome ...)

Il s'agit donc de connaître le nom de l'utilisateur, pour, dans
Form_Open, initialiser correctement la propriété Locked des zones de
saisie voulues en fonction de l'utilisateur qui s'est connecté.

La dernière fois que j'ai eu ça à faire j'ai appelé une API, mais en
cherchant je vois que le sieur Inisan s'en remet tout simplement aux
variables d'environnement, ce qui effectivement a l'intérêt d'être plus
simple à appeler :

http://grenier.self-access.com/?post/2008/05/08/Nom-dutilisateur-et-autre s-informations-utiles

La solution que j'ai évoquée en premier est là :

http://access.mvps.org/accessfr/apis/api0008.htm

Si jamais on vise un parc hétérogène, on peut se méfier qu'une ma chine
n'ait pas son environnement initialisé proprement de la manière à
laquelle on s'attend. C'est là qu'on trouve intéressant de recourir à l'API.
pascal58
Le #24327231
Bonjour,

vous trouverez une solution ici :
http://www.cambier.eu/pascal/codes/access-trousseau/gestion-itinerante-de-d roits-la-methode-du-trousseau-de-cles.html

Cdt, Pascal

Extrait : « Dans une application multi utilisateurs, les droits ne
sont pas nécessairement identiques pour tout le monde.
Certains utilisateurs ont accès à des fonctionnalités mais pas à
d’autres et vice-versa.
« Dupont » peut éditer certaines données que « Durand » ne peut que
consulter, et en partie seulement. Ce dernier peut aussi éditer
d’autres données que le premier ne pourra consulter, etc.
La gestion de sécurité intégrée d’Access ne répond pas à ces besoins.

Mauvaise idée

Écrire dans des tables qui peut faire quoi, ou quoi peut être fait par
qui n’est pas une sinécure, est source d’erreurs et est lourd à g érer
lors de la venue d’un nouvel utilisateur, par exemple.

La bonne idée…

… est, lors d’un login, de munir l’utilisateur d’un trousseau de cl és
(en fait un entier long) lui permettant d’accéder ou pas aux
fonctionnalités barrées par une porte.
Il faut comprendre que c’est la clef qui ouvre et pas l’utilisateur.
Cela permet de cloisonner par clé et non pas par utilisateur et donc
d’avoir une programmation souple : il suffit d’indiquer la clé pour
chaque action.
Gloops
Le #24327801
pascal58 a écrit, le 16/03/2012 15:18 > … est, lors d’un login, de munir
l’utilisateur d’un trousseau de clés
(en fait un entier long) lui permettant d’accéder ou pas aux
fonctionnalités barrées par une porte.
Il faut comprendre que c’est la clef qui ouvre et pas l’utilisateur .
Cela permet de cloisonner par clé et non pas par utilisateur et donc
d’avoir une programmation souple : il suffit d’indiquer la clé po ur
chaque action.



Ah oui c'est vrai que ce que j'ai répondu ça va pour quatre ou cinq
contrôles à gérer, quand il y en a plus, ce que je me rappelle du
trousseau de clef, par les droits codés dans les bits d'un nombre,
permet quelque chose de plus avancé, et plus facile à mettre à jour .
Publicité
Poster une réponse
Anonyme