[Résolu]Accès aux documents importés depuis le poste client.

[Dr Thierry FOURNEL]

Bonjour,

Je suis nouvel utilisateur ALMAPRO et j'ai des soucis... Je travaille avec deux postes, le secrétariat qui est serveur et mon bureau qui est client. Si un document externe est importé, tant document existant que passé au scanner, je peux l'ouvrir sans problème sur le poste serveur, mais pas depuis le poste client. Si j'importe un document ou le scanne depuis mon poste client, je ne peux l'ouvrir ni d'un côté ni de l'autre, je n'en trouve trace dans aucun des répertoires imageexterne. J'ai pourtant bien levé les sécurités abusives de Windows, et je peux ouvrir les documents d'un ordinateur à l'autre si je passe tout bêtement par l'Explorateur Windows, ce n'est donc pas un refus d'accès.
J'ai aperçu dans le forum un message pour difficulté similaire de la part d'un autre utilisateur, à qui on a répondu "Je n'ai pas pu reproduire cette panne". Moi j'ai pu sans effort et j'en suis désolé...

[TChatenet]

bonjour ,

peux tu nous publier le contenu de medicalproject.ini ( il se trouve dans le répertoire windows ) des deux machines ?

Bonne soirée

[Cruanes]

Vérifiez que le repertoire almapro du serveur est bien accessible à partir du poste client (partage)

[Dr Thierry FOURNEL]

Bonjour et merci pour les réponses.
D'abord pour le répertoire AlmaPro du serveur, oui il est bien partagé et j'y accède depuis le poste client sans difficulté.
Pour ce qui est des fichiers MedicalProject.ini, les voici :
Poste serveur :
[ALMAPRO]
VERSION=3.0.7
[Sauvegarde]
Path=C:\SVG_FOURNEL\SVG_FOURNEL
[PREFERENCE_CONSULTATION]
FILTRE_ATCD=3
[ACCES_DISTANT]
RECONNEXION_AUTOMATIQUE=FALSE
Poste client :
[ALMAPRO]
VERSION=3.0.5
Sans connaitre le détail de cette configuration je me demande si ça ne mériterait pas de tenter le coup de changer FALSE en TRUE pour la reconnexion automatique... une expérience qui ne devrait pas faire de dégâts...

[TChatenet]

Bonjour et merci pour les réponses.
D'abord pour le répertoire AlmaPro du serveur, oui il est bien partagé et j'y accède depuis le poste client sans difficulté.
Pour ce qui est des fichiers MedicalProject.ini, les voici :
Poste serveur :
[ALMAPRO]
VERSION=3.0.7
[Sauvegarde]
Path=C:\SVG_FOURNEL\SVG_FOURNEL
[PREFERENCE_CONSULTATION]
FILTRE_ATCD=3
[ACCES_DISTANT]
RECONNEXION_AUTOMATIQUE=FALSE

Poste client :
[ALMAPRO]
VERSION=3.0.5
Sans connaitre le détail de cette configuration je me demande si ça ne mériterait pas de tenter le coup de changer FALSE en TRUE pour la reconnexion automatique... une expérience qui ne devrait pas faire de dégâts...

Oui mais non , ne touches pas à la reconnexion automatique
Par contre peux tu nous confirmer en regardant la page d'accueil de Almapro sur le poste client que tu es en version 3.05 sur ce poste ?
( c'est précisé en noir en bas de l'écran juste sous le bouton ' quitter ' )

[Dr Thierry FOURNEL]

Non, je ne suis pas en 3.0.5 mais bien en 3.0.7 sur les deux postes.
J'avais effectivement remarqué cette curiosité sur mon MedicalProject du poste client...
.

[TChatenet]

J'essaierais la chose suivante :
1) désactiver la protection de compte utilisateur ou lancer almapro en mode administrateur ( clic droit mais c'est moins certain comme méthode )
2) par l'interface almapro refaire les paramètres réseau
3) regarder si le medicalproject.ini a été convenablement tenu à jour

la protection de compte utilisateur empêche almapro de tenir à jour le fichier ini placé dans windows .
Selon les versions de windows une copie de dépannage est placée en
C:\Users\TonNomdUtilisateur\AppData\Local\VirtualStore\Windows

Idéalement si tu ne veux pas d'ennui et que tu souhaites rétablir la protection de compte utilisateur il faut faire tous les paramétrages LUA désactivée puis , quand tout fonctionne la rétablir.
J'avais fait quelques essais et remarqué que le comportement et la lecture des ini était différente selon les trois possibilités ( LUA off , LUA on , LUA on et almapro en mode administrateur ) . Je n'ai pas plus approfondi , j'ai fait comme dit plus haut puis recopié le ini à jour dans les deux emplacements .
Je te propose d'en faire autant en espérant que cela résolve ton problème ; Je suppose que le medical project .ini du virtual store est plus à jour que celui de windows dans ton cas car il manque quelques lignes dans celui que tu nous as montré .
Tiens nous au courant du résultat des courses
bonne soirée TC

[Dr Thierry FOURNEL]

Voila, j'ai procédé par ordre. La protection de l'utilisateur était déjà désactivée. J'ai voulu lancer AlmaPro en mode Administrateur, mais je n'ai accès alors qu'à la version d'évaluation avec mot de passe 123... je ne sais pourquoi.
J'ai reparamétré les options réseau, sans les changer mais en les réenregistrant. Mon MédicalProject s'est modifié en affichant la bonne version de logiciel, 3.0.7. C'est tout.
Je suis allé voir comme tu 'as indiqué la version de dépannage dans les profondeurs de la hiérarchie des sous-répertoires, qui est effectivement plus complète, elle indique le chemin du serveur. Je me suis hasardé donc à remplacer le fichier trop court d'origine par celui de dépannage. J'ai relancé AlmaPro, mais hélas rien n'a changé.
Le nouveau MedicalProject.ini :
[ALMAPRO]
VERSION=3.0.7
[CHEMIN]
SERVERNAME=192.168.1.21
CHEMIN_RESEAU=\\192.168.1.21\C\almapro
NOM_PARTAGE_DISQUE_SERVEUR=C
REP_ALMAPRO_PARTAGE=FALSE
REP_BDMED_PARTAGE=FALSE
[PREFERENCE_CONSULTATION]
FILTRE_ATCD=3
[PREFERENCE_PRESCRIPTION]
IMPRIMER=2
[CONFIG]
USERNAME=false
Est-il plus efficace de partager directement les répertoires ALMAPRO et BDMED plutôt que le répertoire racine ? Car ce dernier est davantage protégé lors des partages. Si je veux envoyer un fichier dans le répertoire racine du serveur, on me le refuse, alors je ruse en le copiant dans un sous-répertoire, et je le déplace ensuite dans le répertoire racine. Dans ce cas, les partages faits (celui d'AlmaPro a été fait depuis le début, mais pas celui de BDMED) je pourrais modifier à la main le chemin réseau et transformer deux FALSE en TRUE. Osé, hein ?

[TChatenet]

Effectivement : je pense que l'étape suivante est de partager les répertoires almapro et bdmed plutôt que la racine , je te rappelle qu'il te faut vérifier que ces répertoires soient partagés avec tout le monde en lecture et écriture
Par principe je changerais tous les choix de la configuration réseau avant d'y revenir puis de valider , de la sorte almapro réenregistrera tout car il aura détecté que les valeurs auront été modifiées

[EDIT]
PS : comment as tu désactivé la protection de compte utilisateur ?
Si vraiment elle était désactivée le fichier ini aurait été tenu à jour dans windows et non dans virtual store et tu n'aurais pas pu lancer almapro en mode administrateur car l'option ne t'aurait pas été proposée . Quelle version de windows utilises tu ?

[TChatenet]

Voila, j'ai procédé par ordre. La protection de l'utilisateur était déjà désactivée. J'ai voulu lancer AlmaPro en mode Administrateur, mais je n'ai accès alors qu'à la version d'évaluation avec mot de passe 123... je ne sais pourquoi.

probablement parce que je fais fausse route . Le fait que tu repasses sur le fichier démo avec passe 123 prouve que en mode administrateur almapro a lu le fichier ini incomplet dans windows et se croyant en poste isolé a s'est connecté sur le fichier démo présent sur ta machine client . A contrario cela prouve que almapro utilisait pleinement la version de medical project.ini présente dans le virtual store .

,
J'ai reparamétré les options réseau, sans les changer mais en les réenregistrant. Mon MédicalProject s'est modifié en affichant la bonne version de logiciel, 3.0.7. C'est tout.

Comme dit dans la réponse précédente il faut que tu modifies toutes les valeurs avant de les réafficher sinon il est possible que almapro ne les considère pas comme modifiés et ne les réenregistre pas

Je suis allé voir comme tu 'as indiqué la version de dépannage dans les profondeurs de la hiérarchie des sous-répertoires, qui est effectivement plus complète, elle indique le chemin du serveur. Je me suis hasardé donc à remplacer le fichier trop court d'origine par celui de dépannage. J'ai relancé AlmaPro, mais hélas rien n'a changé.
Le nouveau MedicalProject.ini :
[ALMAPRO]
VERSION=3.0.7
[CHEMIN]
SERVERNAME=192.168.1.21
CHEMIN_RESEAU=\\192.168.1.21\C\almapro
NOM_PARTAGE_DISQUE_SERVEUR=C
REP_ALMAPRO_PARTAGE=FALSE
REP_BDMED_PARTAGE=FALSE
[PREFERENCE_CONSULTATION]
FILTRE_ATCD=3
[PREFERENCE_PRESCRIPTION]
IMPRIMER=2
[CONFIG]
USERNAME=false
Est-il plus efficace de partager directement les répertoires ALMAPRO et BDMED plutôt que le répertoire racine ? Car ce dernier est davantage protégé lors des partages. Si je veux envoyer un fichier dans le répertoire racine du serveur, on me le refuse, alors je ruse en le copiant dans un sous-répertoire, et je le déplace ensuite dans le répertoire racine. Dans ce cas, les partages faits (celui d'AlmaPro a été fait depuis le début, mais pas celui de BDMED) je pourrais modifier à la main le chemin réseau et transformer deux FALSE en TRUE. Osé, hein ?

Surtout insuffisant car cela change aussi le chemin réseau ( le /C n'a plus de raison d'être ) . Il vaut mieux faire ces modification par l'interface de almapro

[Dr Thierry FOURNEL]

Quand j'ai dit sans les changer, en fait j'avais fait des aller-retours de modifications pour forcer l'enregistrement, et ça s'était fait.
J'ai modifié la config comme prévu, partagé les répertoires AlmaPro et bdmed (trouvé comme sous-répertoire dans bcb), les ai déprotégés, ai déverrouillé les limitations d'écriture par utilisateur. Passage dans le service config réseau d'AlmaPro, et le MedicalProject du sous-répertoire de secours a été mis à jour comme prévu, pas celui du répertoire Windows. Je me suis fait un plaisir d'écraser l'ancien sous le nouveau... et tout marche comme avant, pas mieux.
Je répond aux questions annexes : mon serveur est Windows 7, le client est Windows 8. J'ai modifié les protections d'utilisateurs en passant par le panneau de configuration, tout bêtement. J'ai mis les curseurs tout en bas... Mais il a aussi fallu passer par l'explorateur, ouvrir les propriétés des répertoires et fichiers pour supprimer quelques relicats de protection, d'interdiction d'écriture...

[Dr Thierry FOURNEL]

Maintenant le nouveau MedicalProject est :
[ALMAPRO]
VERSION=3.0.7
[CHEMIN]
SERVERNAME=192.168.1.21
CHEMIN_RESEAU=\\192.168.1.21\almapro
NOM_PARTAGE_DISQUE_SERVEUR=C
REP_ALMAPRO_PARTAGE=TRUE
REP_BDMED_PARTAGE=TRUE
[PREFERENCE_CONSULTATION]
FILTRE_ATCD=3
[PREFERENCE_PRESCRIPTION]
IMPRIMER=2
[CONFIG]
USERNAME=false

[TChatenet]

Le mieux est de tout refaire complètement dans les clous .
pour commencer je te conseille de désactiver la protection de compte utilisateur complètement en utilisant la méthode préconisée par les développeurs puisque manifestement elle n'est pas désactivée par la manipulation du curseur du panneau de config
http://www.almapro.org/infotheque/faq/D ... ateurs.pdf

Vérifies aussi la configuration du serveur
http://www.almapro.org/infotheque/faq/P ... rt3306.pdf

Je pense que ton poste client ne 'sait' pas où stocker les documents externes et que c'est pour cela que tu ne les retrouves nulle part quand tu en crées sur ton client, c'est aussi pour cela qu'il ne va pas les chercher sur le serveur .

Je pense donc qu'il faut reprendre la configuration à la base mais en appliquant strictement la procédure décrite par le développeur.
Il n'y a pas de raison que ça ne fonctionne pas .
Tu auras probablement intérêt à redémarrer les deux machines quand tu auras tout paramétré

Fais nous savoir le résultat des courses , j'espère que ce coup ce ce sera bon !

[EDIT]
PS bien évidemment tu commences par le contrôle du serveur .

[Dr Thierry FOURNEL]

J'ai tout fait, désactiver le contrôle des comptes utilisateurs en passant par la base des registres sur le client. Pour le serveur j'ai vérifié, mais j'avais procédé comme l'avait indiqué le programmeur. J'ai relancé, mais sans changement toujours. Désespérant...

[Dr Thierry FOURNEL]

Victoire !
Voila, tout marche maintenant bien et dans les deux sens !
J'ai continué de fouiner dans les propriétés, sécurités et partages, et j'ai fait sans trop y croire la manoeuvre salvatrice.
Pour tous les répertoires concernés sur le serveur, donc AlmaPro et Imagesexternes, je suis allé dans les propriétés du répertoire, onglet Sécurité, Modifier les autorisations, Ajouter, et j'ai entré "Tout le monde" dans la zone de saisie de l'objet à ajouter. Et j'ai attribué à ce "Tout le monde" tous les droits de lecture/écriture. Et comme par magie tout marche depuis.
Je vous remercie pour la patience dont vous avez fait preuve à mon égard dans mes tâtonnements et j'espère que ça aidera d'autres personnes, je pense notamment à celui ou celle qui avait exposé le même problème antérieurement, sans réponse utile dans le forum.
Bonne soirée à tous !

[Dr Thierry FOURNEL]

Comment procède-t-on pour signaler le sujet de discussion comme "résolu" ?

[TChatenet]

Victoire !
Voila, tout marche maintenant bien et dans les deux sens !
J'ai continué de fouiner dans les propriétés, sécurités et partages, et j'ai fait sans trop y croire la manoeuvre salvatrice.
Pour tous les répertoires concernés sur le serveur, donc AlmaPro et Imagesexternes, je suis allé dans les propriétés du répertoire, onglet Sécurité, Modifier les autorisations, Ajouter, et j'ai entré "Tout le monde" dans la zone de saisie de l'objet à ajouter. Et j'ai attribué à ce "Tout le monde" tous les droits de lecture/écriture. Et comme par magie tout marche depuis.

Il s'agissait donc en définitive d'un problème de droits sur les répertoires partagés du serveur et non d'un problème d'enregistrement de la configuration sur le client
Ton expérience démontre s'il en était besoin que lors du contrôle de la configuration il ne faut pas hésiter à répéter chaque étape de la procédure même si on a l'impression de l'avoir déjà faite

Je vous remercie pour la patience dont vous avez fait preuve à mon égard dans mes tâtonnements et j'espère que ça aidera d'autres personnes, je pense notamment à celui ou celle qui avait exposé le même problème antérieurement, sans réponse utile dans le forum.
Bonne soirée à tous !

Toi aussi , tu peux maintenant profiter pleinement de cet excellent outil qu'est Almapro !

Comment procède-t-on pour signaler le sujet de discussion comme "résolu" ?

C'est fait !