Comment faire un test avant un FieldByName().value = ... ?

Bonjour à tous,

J'ai une appli avec une vingtaine de tables, quelques centaines de champs, et des FieldByName([champ]).value = éparpillés dans tout le code.

Problème : les utilisateurs veulent à présent des droits d'accès restreints sur certains champs de certaines tables, définis pour différents groupes. Donc je mets les champs interdits en "readonly" à l'ouverture de l'appli en fonction du groupe courant.

Mais beaucoup de fonctions communes (BeforeInsert entre autres) plantent à présent parce que des champs sont "readonly".

La solution de base consisterait à faire manuellement un test avant chaque FieldByName pour savoir si le groupe courant a droit ou non de modifier ce champ, mais ça me prendrait des jours.

Alors je cherche une fonction qui serait appelée automatiquement au moment où l'on exécute un FieldByName et qui me permettrait de tester si le champ de la table est "readonly", et de rejeter l'affectation de valeur dans ce cas.

J'ai essayé avec
TTable.BeforeEdit
TDatasource.OnDataChange
TDatasource.OnUpdateData
TField.OnChange
TField.OnSetText
TField.OnValidate

et ça ne fonctionne pas, car toutes ces fonctions sont appelées après l'affectation de la valeur au champs.

Auriez-vous une idée pour résoudre ce problème ??

Pour info : D7 enterprise avec SQL Serveur 2k et ODBC

(je ne dois pas être le seul à galérer pour gérer des droits d'accès !?!)

Merci.

Ne serait il pas plus simple de mettre en readonly les champs au niveau de l'affichage dans les grids/composants d'editions plutot que de mettre le champ lui même en readonly ?

Non, vu qu'une même table peut-être affichée de diverses manières dans différents écran, mettre les champs, voire les tables complètes, en read-only, est beaucoup plus simple à gérer.

Je ne défini les accès qu'une seule fois à l'ouverture du programme, au lieu de le faire à chaque fois sur la quarantaine de fenêtres que compte le programme (certaines fenêtres ayant jusqu'à 4 grilles).

Si tu utilises les composants ADO, il y a le OnWillChangeField sur les AdoTAble et AdoQuery qui te permettrais de faire ça.

J'utilise les composants BDE, et je me vois mal rebasculer tout sous ADO, surtout avec les problèmes que j'ai eu par le passé avec ces composants.

N'y a t'il pas un équivalent à ce OnWillChangeField avec les composants BDE ?

A ce niveau la :f1: est ton ami ^^, regarde chaque fonction de tes composants.

Pour ma part concernant BDE et Ado, j'ai eu enormement de problèmes de compatibilité avec BDE et SQL Serveur 2k qu'avec Ado. Enfin bon, ca c'est un autre sujet ^^

Je pense que bloquer les champs en readonly directement au niveau des composants de base de données n'est pas la solution la plus simple à mettre en place.

Citation:

---

Envoyé par Malatar

Je pense que bloquer les champs en readonly directement au niveau des composants de base de données n'est pas la solution la plus simple à mettre en place.

---

et pourtant si.
si je dois bloquer les accès au niveau des composants, il y a certaines tables pour lesquelles je vais devoir faire 4 ou 5 fois le travail, multiplié par le nombre de champs, le calcul du temps perdu est vite fait !

Pour ma part je vois pas de solutions à ton problème.

Je pense que de toute manière tu vas devoir aller dans toutes les forms de ton application pour faire des modifications, même avec la méthode que tu utilises.

Je te propose la solution suivante :

Tu crées un Type Utilisateur global avec les differents droit d'accès possible (de préférence des droits d'accès commun).
Lors de la saisie du login/mdp ou config pres défini par un paramètre ou autres solutions.
Tu mets à jours l'utilisateur selon le type de droit possible.
Après il te reste qu'à mettre dans les oncreate/onshow (tout depend si tu fait de la creation dynamique des forms ouou non) des forms les vérouillages nécessaires selon les droits.



Mais dans tous les cas tu auras des modifications à faire dans toutes tes forms avec ta solution comme avec la mienne.

A moins qu'un autre forumeur te sorte la solution miracle ;)

Citation:

---

Envoyé par Malatar

Pour ma part je vois pas de solutions à ton problème.
Tu crées un Type Utilisateur global avec les differents droit d'accès possible (de préférence des droits d'accès commun).
Lors de la saisie du login/mdp ou config pres défini par un paramètre ou autres solutions.
Tu mets à jours l'utilisateur selon le type de droit possible.

---

C'est déjà ce que je fais.

J'ai un utilisateur ADMIN qui a tous les droits, et les autres groupes découlent de ce groupe, avec quelques tables et quelques champs en read-only en fonction des droits définis.

Les read-only sont faits à l'ouverture de l'appli uniquement.

Ensuite, la solution que j'ai mis en place actuellement, c'est de faire un test avant chaque FBN du DataModule, ex :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

procedure TDM.TPieceAfterInsert(DataSet: TDataSet); begin // Champs par défaut with TPiece do begin FieldByName('Famille').Value:=1; FieldByName('Date_Cree').Value:=date;   // Test des champs bloqués pour certains groupes - 15.09.05 if not FieldByName('Devise').ReadOnly then FieldByName('Devise').Value:='EUR'; if not FieldByName('Calcul_Cout').ReadOnly then FieldByName('Calcul_Cout').Value:=1; end;   end;

---

Pour l'instant je peux ecarter les FBN propres aux FORM, car les accès aux fenêtres dépendent également des droits. Mais rien ne me dit que ça va durer.

Le problème, c'est le risque d'oublier un jour de mettre un test sur un champs et que ça plante les utilisateurs, d'où le besoin d'une fonction commune globale et transparente.

Passe par une requete update, plus de problème pour après, vu que la requete sera independant de l'etat de tes champs.

De plus il te manque un Tpiece.Post; a la fin pour valider completement tes modifications.

Citation:

---

Envoyé par Malatar

Passe par une requete update, plus de problème pour après, vu que la requete sera independant de l'etat de tes champs.

---

Et donc des utilisateurs pourraient modifier des champs auxquels ils ne sont pas censés avoir accès. L'un des (nombreux) intêrets à mettre les champs en read-only dans les tables, c'est que les composants associées sont automatiquements interdits en modif, et je n'ai pas à m'occuper de ça.

Avec une requête, il faudrait que je bloque l'accès à tous les composants des champs interdits.

Citation:

---

Envoyé par Malatar

De plus il te manque un Tpiece.Post; a la fin pour valider completement tes modifications.

---

C'est l'utilisateur qui valide manuellement la création des enregistrements avec un DBNavigator.

Citation:

---

Envoyé par fredfred

Citation:

---

Envoyé par Malatar

Passe par une requete update, plus de problème pour après, vu que la requete sera independant de l'etat de tes champs.

---

Et donc des utilisateurs pourraient modifier des champs auxquels ils ne sont pas censés avoir accès. L'un des (nombreux) intêrets à mettre les champs en read-only dans les tables, c'est que les composants associées sont automatiquements interdits en modif, et je n'ai pas à m'occuper de ça.

Avec une requête, il faudrait que je bloque l'accès à tous les composants des champs interdits.

---

Non tu as mal compris. Dans le AfterInsert que tu montres, au lieu de mettre des FieldByName tu remplaces par une requete update.

Genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Database.BeginTrans; With QPiece do begin Close; Clear; SQL.Add('Update [LA TABLE] set'); SQL.Add('Famille = 1,'); SQL.Add('Date_Cree =' + FormatDateTime('mm/dd/yyyy hh:nn:ss',date) + ','), SQL.Add('Devise =''EUR'',' ); SQL.Add('Calcul_cout = 1'); SQL.Add('Where [LE NECESSAIRE] = [LA VALEUR]'); ExecSQL; <--- pas sur de la commande avec les TQuery end;

---

Apres te reste plus qu'a faire un Database.CommitTrans; au moment de la validation.
Enfin faire une modification dans ce style (Code pas tester donc il peut y avoir des erreurs).

Non, j'avais très bien compris, car d'après ton exemple, tous les utilisateurs peuvent ajouter un nouvel enregistrement avec toutes les valeurs pas défaut.

Or, d'après l'exemple que j'avais cité, certains champs sont interdits à certains groupes (devise, calcul_cout) ET DOIVENT IMPERATIVEMENT LE RESTER, quelle que soit la manière d'ajouter des champs dans les tables.

Désoler, je vois pas d'autres solutions à ton problème.