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???
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gloops
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 :
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.
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 :
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.
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 :
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
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 à dautres et vice-versa. « Dupont » peut éditer certaines données que « Durand » ne peut que consulter, et en partie seulement. Ce dernier peut aussi éditer dautres données que le premier ne pourra consulter, etc. La gestion de sécurité intégrée dAccess ne répond pas à ces besoins.
Mauvaise idée
Écrire dans des tables qui peut faire quoi, ou quoi peut être fait par qui nest pas une sinécure, est source derreurs et est lourd à g érer lors de la venue dun nouvel utilisateur, par exemple.
La bonne idée
est, lors dun login, de munir lutilisateur dun trousseau de cl és (en fait un entier long) lui permettant daccéder ou pas aux fonctionnalités barrées par une porte. Il faut comprendre que cest la clef qui ouvre et pas lutilisateur. Cela permet de cloisonner par clé et non pas par utilisateur et donc davoir une programmation souple : il suffit dindiquer la clé pour chaque action.
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 à
dautres et vice-versa.
« Dupont » peut éditer certaines données que « Durand » ne peut que
consulter, et en partie seulement. Ce dernier peut aussi éditer
dautres données que le premier ne pourra consulter, etc.
La gestion de sécurité intégrée dAccess ne répond pas à ces besoins.
Mauvaise idée
Écrire dans des tables qui peut faire quoi, ou quoi peut être fait par
qui nest pas une sinécure, est source derreurs et est lourd à g érer
lors de la venue dun nouvel utilisateur, par exemple.
La bonne idée
est, lors dun login, de munir lutilisateur dun trousseau de cl és
(en fait un entier long) lui permettant daccéder ou pas aux
fonctionnalités barrées par une porte.
Il faut comprendre que cest la clef qui ouvre et pas lutilisateur.
Cela permet de cloisonner par clé et non pas par utilisateur et donc
davoir une programmation souple : il suffit dindiquer la clé pour
chaque action.
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 à dautres et vice-versa. « Dupont » peut éditer certaines données que « Durand » ne peut que consulter, et en partie seulement. Ce dernier peut aussi éditer dautres données que le premier ne pourra consulter, etc. La gestion de sécurité intégrée dAccess ne répond pas à ces besoins.
Mauvaise idée
Écrire dans des tables qui peut faire quoi, ou quoi peut être fait par qui nest pas une sinécure, est source derreurs et est lourd à g érer lors de la venue dun nouvel utilisateur, par exemple.
La bonne idée
est, lors dun login, de munir lutilisateur dun trousseau de cl és (en fait un entier long) lui permettant daccéder ou pas aux fonctionnalités barrées par une porte. Il faut comprendre que cest la clef qui ouvre et pas lutilisateur. Cela permet de cloisonner par clé et non pas par utilisateur et donc davoir une programmation souple : il suffit dindiquer la clé pour chaque action.
Gloops
pascal58 a écrit, le 16/03/2012 15:18 > est, lors dun login, de munir lutilisateur dun trousseau de clés
(en fait un entier long) lui permettant daccéder ou pas aux fonctionnalités barrées par une porte. Il faut comprendre que cest la clef qui ouvre et pas lutilisateur . Cela permet de cloisonner par clé et non pas par utilisateur et donc davoir une programmation souple : il suffit dindiquer 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 .
pascal58 a écrit, le 16/03/2012 15:18 > est, lors dun login, de munir
lutilisateur dun trousseau de clés
(en fait un entier long) lui permettant daccéder ou pas aux
fonctionnalités barrées par une porte.
Il faut comprendre que cest la clef qui ouvre et pas lutilisateur .
Cela permet de cloisonner par clé et non pas par utilisateur et donc
davoir une programmation souple : il suffit dindiquer 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 .
pascal58 a écrit, le 16/03/2012 15:18 > est, lors dun login, de munir lutilisateur dun trousseau de clés
(en fait un entier long) lui permettant daccéder ou pas aux fonctionnalités barrées par une porte. Il faut comprendre que cest la clef qui ouvre et pas lutilisateur . Cela permet de cloisonner par clé et non pas par utilisateur et donc davoir une programmation souple : il suffit dindiquer 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 .
