Toutes mes réponses sur les forums
-
AuteurMessages
-
2 mai 2014 à 9 h 03 min #5079
Ajoutons que si on utilisait le même compte « générique » pour plusieurs utilisateurs ceux ci utiliseraient les mêmes paniers, export, profils etc… ce qui aboutirait à des aberrations fonctionnelles.
29 avril 2014 à 7 h 18 min #4896Bonjour,
Nous allons noter comme demande d’amélioration (pertinente) l’inactivation automatique des profils rattachés à un utilisateur absent de la table ILS_LEC.
bonne journée8 avril 2014 à 8 h 48 min #5074La valeur « AUTRE » correspond le plus souvent au chargement du fichier home.html d’une vue.
Les autres valeurs ont les significations suivantes :
– LOGIN : entrée en session (pour un anonyme ou un utilisateur identifié). Attention, il faut vérifier aussi les champs LOG_SESSION et LOG_VUE. Si LOG_SESSION contient la valeur « REFUSEE » c’est que l’entrée en session a échouée et dans ce cas le motif de refus est dans le champ LOG_VUE (ex « LOGIN-nom de lecteur inconnu ».– TELECHARGEMENT : correspond à un accès à un document natif. Dans ce cas on aura dans le champ DW_DOCREF_LIT la valeur du DOC_REF de la notice ou à défaut son FT_CID
– RECHERCHE : correspond a l’accès au formulaire de recherche d’une vue. Cela ne correspond pas à un résultat de recherche.
– RESULTAT : correspond à un accès en liste de résultats, après une recherche. Dans ce cas on aura LOG_REQUETE et LOG_CRITERES pour connaitre les critères de recherche utilisés. LOG_MODELE nous indiquera le modèle utilisé.
– NOTICE : correspond au chargement du formulaire de notice, soit après une recherche, soit en création de nouvelle notice. Dans ce dernier cas on aura « QUERY=1″ dans LOG_GET_VARS ou LOG_POST_VARS– ACCES-NOTICE : si on est en version 2013 et qu’on a inséré la balise CADICEXEC suivante dans une vue, alors tout accès de type url simple « /exl-php/vue-consult/mavue/mondocref » déclenchera une écriture de ce type (acces direct à une notice).
[CADICEXEC__PHP_trace_acces_notice@ILS_DOC@[CADIC__REPVUE]@cid=[CADIC__SELECT_FT_CID]|ref=[CADIC__SELECT_DOC_REF__options=ShowMatches( », »)]|libvue=[CADIC__NOMVUE]]
7 avril 2014 à 9 h 32 min #5072Oui c’est bien ça.
7 avril 2014 à 9 h 01 min #5070Bonjour,
La vue « LOGIN » n’existe pas réellement; c’est notre moyen d’identifier dans les données collectées l’événement d’entrée en session. De même vous devez avoir des valeurs « TELECHARGEMENT » qui correspondent à la trace de l’événement « affichage d’un document natif ».
Concernant la différenciation entre les utilisateurs identifiés et les connexions anonymes : techniquement il n’y en a pas. Un utilisateur anonyme (ou PUBLIC) initie un session Cadic Intégrale, comme le fait un utilisateur qui s’identifie réellement. Il est donc normal que nous stockions dans les données statistiques ces événements d’entrée en session, pour un accès anonyme, comme pour un accès identifié.
Pour finir, le nombre d’accès à la page d’accueil doit être recherché dans les statistiques en ciblant la vue utilisée comme page d’accueil sur votre site.
Bonne journée19 mars 2014 à 13 h 25 min #4931Bonjour,
je viens de re-vérifier sur une version 2011 après avoir déposé le fichier js-notice.inc et de mon côté cela fonctionne correctement : mes 3 champs sont bien vidés.
Je pense que vous faites face à un autre problème. Si un des champs indiqués dans la variable CGI DUPLI_RAZCHAMPS n’est pas présent dans le formulaire alors cela doit interrompre la chaîne d’effacement des contenus.A noter aussi qu’il ne faut absolument aucun espace avant ou après un nom de champ dans cette variable, sinon le champ n’est pas considéré comme valide.
Il m’est difficile de répondre plus précisément car je ne peux pas voir en entier le contenu de votre variable.
Je vous conseille donc de modifier votre paramétrage pour , dans un premier temps ne mettre que DOC_REF et les champs de votre premier bloc de synchronisation.
Si cela fonctionne, ajoutez les autres champs petit a petit.Si jamais vous avez tout vérifié ; que les champs sont bien présents dans l’écran (en texte, ou texte caché), que les mnémoniques sont exacts et qu’il n’y a pas d’espaces parasites, alors je vous engage à ouvrir un cas en assistance (en y joignant une archive de la vue); que je suivrai
Cordialement17 mars 2014 à 14 h 50 min #4930Bonjour,
Je pourrai vérifier ce point mercredi; je vous tiens au courant dès que possible.
Bonne journée14 mars 2014 à 11 h 27 min #4928Bonjour,
Lors d’une duplication de notice, par défaut, seul le champ identifié comme « CHAMPCLE » dans la vue est purgé. Le plus souvent ce champ est paramétré avec un compteur incrémental qui s’applique en EXIT_DEFAUT c’est à dire au moment de l’enregistrement.Une nouvelle valeur unique est alors attribuée.
Quand on désire purger d’autres champs au moment de la duplication il suffit d’agir sur le paramètre cgi DUPLI_RAZCHAMPS présent dans la vue et d’y lister les mnémoniques des champs à purger séparés par des virgules.
Dans le cas d’une vue de saisie unimarc, on liste non pas les mnémoniques mais les numéro de zones unimarc.Techniquement, la fonction javascript de duplication est située dans le fichier web/commun/include/js-notice.inc.
Nous avons modifié ce fichier afin de pouvoir prendre en compte des mnémoniques de champs présents dans groupes synchronisés.Par ex, si j’ai un groupe de champs synchronisés contenant les champs DOC_AUTEUR et DOC_AUTEURSEC, il suffira d’ajouter la séquence « ,DOC_AUTEUR,AUTEURSEC » à la variable DUPLI_RAZCHAMPS.
ex : DUPLI_RAZCHAMPS DOC_REF,DOC_DAT_CREAT,DOC_AUTEUR,AUTEURSEC
Cette modification n’a pas encore intégré le patch officiel téléchargeable sur le site du support mais elle est testable avec les deux fichiers ci-joints (version 2011 et version 2013).
Merci d’avance à ceux qui sont intéressés de tester le fonctionnement en environnement de recette / tests et de nous faire un retour.Attention à bien utiliser le fichier correspondant à votre version et n’oubliez pas de le renommer en supprimant « _2011″ ou « _2013″.
Le fichier est à déposer dans web/commun/include après sauvegarde du fichier existant.Si tout est ok fonctionnellement nous intégrerons rapidement le fichier au patch officiel.
cordialement
11 mars 2014 à 14 h 10 min #5059Voici la documentation à jour pour cet utilitaire.
Cordialement11 mars 2014 à 11 h 40 min #5057Bonjour,
il s’agit d’un module relativement ancien dans notre solution.
Il ne remplace pas les tâches d’exploitation courantes et surtout pas les sauvegardes planifiées sur le serveur.
C’est un outil d’appoint pour des sauvegardes ponctuelles et limitées. Il ne doit pas être utilisé pour sauvegarder toutes les tables en ligne (c’est le rôle des sauvegardes planifiées) mais peut servir pour archiver à un instant « t » une table Cadic Intégrale (par exemple pour la transférer à notre assistance).
L’outil est bien adapté pour des tables de petite taille (tables des utilisateurs, tables d’autorités par ex); il est plus délicat de l’utiliser sur la table des documents car celle ci est fortement utilisée en journée et sa taille peut être incompatible avec une sauvegarde « en ligne ».L’outil permet plusieurs types de sauvegardes :
– sous la forme de fichiers xml compressés (un fichier par enregistrement)
– sous la forme de « Dump sql » c’est à dire d’un fichier contenant des requêtes SQL d’insertion.
– sous la forme d’une recopie simple d’une table vers le répertoire « bases/archives ».J’ajoute que cet outil peut être intéressant pour vérifier la taille des tables en espace disque et en nombre d’enregistrements.
Il existe une documentation standard de ce module mais elle a besoin d’être remise à la charte Cadic Services. Nous la remettrons en ligne dès que ce sera fait.
Bonne journée7 mars 2014 à 15 h 15 min #4841Bonjour, merci de cette contribution; nous allons auditer le fichier et il fera peut être partie de notre prochaine distrib.
Merci encore et bonne journée27 février 2014 à 12 h 56 min #4972Bonjour,
Je pense qu’une bonne solution consiste à créer une inclusion cgi à déposer dans web/vues/commun/include avec un nom comme iffstar_google_analytics.inc. Il faudra y mettre le code indiqué avec les marqueurs de début et de fin de javascript.
Ensuite il vous suffit d’utiliser webAdmin pour injecter cette inclusion dans les 3 écrans des vues concernées (y compris dans l’écran de recherche de la page d’accueil).21 février 2014 à 10 h 48 min #4919Bonjour,
Nous pouvons noter cette demande dans la feuille de route de notre prochaine version mais il nous faudra dans ce cas plus de détails sur la demande fonctionnelle.
La planche contact doit elle concerner une liste de résultats et/ou une notice liée à plusieurs images ?
Comment doit elle être construite (taille des vignettes, disposition); doit-il y avoir du texte avec les images (quels champs, nombre de caractères etc…).
Bref, il nous faut une réelle expression de besoin pour pouvoir nous prononcer sur la faisabilité et la planification.21 février 2014 à 10 h 30 min #5033Bonjour,
Vous avez plusieurs possibilités pour réaliser cela :
## Première possibilité :
Faites un duplication de la vue article vers une vue « articles du jour ».
Modifiez la restriction initiale de cette vue en ajoutant la séquence suivante : AND DOC_DAT_CREAT = date ‘[CADIC__DATESS_-0]’## Seconde possibilité :
si vous souhaitez mettre un lien depuis la page d’accueil : ajoutez un objet de type lien hypertexte dans la vue accueil et donnez lui l’url suivante :
/exl-php/cadcgp.php?CMD=CHERCHE&QUERY=1&MODELE=vues/{ma_vue_article}/home.html&VUE=ged_jour&CLE=IS_DOC_DAT_CREAT&CLEVALEUR=[CADIC__DATE_-0]Remplacez {ma_vue_article} par le vrai répertoire de votre vue.
Si vous souhaitez que ce lien soit affiché dans l’écran de recherche de votre vue article alors il faut lui donner la forme suivante :
/exl-php/cadcgp.php?CMD=CHERCHE&MODELE=vues/{ma_vue_article}/tpl-r.html&VUE=ged_jour&WHERE_DOC_DAT_CREAT=[CADIC__DATESS_-0]Ensuite, pour travailler sur la semaine ou le mois utilisez les balises suivantes :
[CADIC__DATESS_-7] ou [CADIC__DATE_-7]
[CADIC__DATESS_-30] ou [CADIC__DATE_-30]21 février 2014 à 9 h 59 min #5038Bonjour,
non, désolé, nous ne pouvons pas filtrer un affichage d’index. Par contre, si le besoin fonctionnel concerne la saisie, il ne devrait pas s’agir d’un index mais d’un réel appel à une liste, qui lui est filtrable (paramétrage de liste dans Webadmin, action sur le paramètre « restriction initiale ».
Si vous êtes déjà dans ce cas alors une solution simple consisterait à marquer les valeurs obsolètes de votre liste avec une séquence fixe (par ex » @SUPPR@) puis de modifier la restriction initiale de la liste dans Webadmin pour ne pas retenir les valeurs contenant « SUPPR ».
-
AuteurMessages
