Tous les projets

Les obligations qui découlent des changements légaux prévus :

• 2018 : terminé.
• 2019 : terminé.
• 2020 : suivi.

On a constaté que certains utilisateurs se servaient de la fonction de libération des codes présente sur la page d’administration de compte en ligne pour échanger l’activation sur plusieurs bases de données.

Outre le fait que cela n’est pas autorisé par le contrat de licence:

Art.9 ) Chaque code d’activation est unique et ne peut être lié qu’à une seule licence dont l’usage est strictement limité à une seule session d’utilisation de BEDESK-EXPRESS et d’accès à une seule base de données.

Cette pratique entraîne d’autres complications d’ordre légal:

1. La législation impose d’assurer la continuité de la piste d’audit des opérations réalisées. Or, le fait de changer de base de données brise cette continuité et compromet gravement la traçabilité des opérations.
2. L’éditeur du logiciel est tenu par la loi de s’assurer que les données saisies ne peuvent pas être effacées. Ceci inclut également l’effacement par écrasement lors de la restauration d’une sauvegarde de sécurité.
   • Sur ce point, le service “Proactive Customer Care” détecte déjà les situation où il y moins de données enregistrées lors d’une sauvegarde de sécurité que lors de la précédente sauvegarde.
3. Les utilisateurs qui ont recours à la libération de code pour échanger un même code d’activation sur plus d’une seule base de données perturbe le fonctionnement du service VB4B. Ils occasionnent notamment un surcroît de l’utilisation de la bande passante et introduisent des données de plusieurs bases de données différentes dans la même file chronologique des versions des sauvegardes. Cela augmente fortement le besoin d’espace de stockage car plusieurs bases de données sont ainsi sauvegardées dans une même archive.

—

En principe, la fonction de libération n’est pas prévue pour utiliser, avec une seule et même licence, plusieurs bases de données différentes.

Cette fonction est prévue pour faciliter, le cas échéant, le changement d’ordinateur dans le cadre d’une changement définitif du matériel ou à caractère purement exceptionnel dans le cadre d’un dépannage par exemple.

Cette fonction est manifestement abusée. Le souci c’est que cela va plus loin que simplement permettre l’usage d’un même code sur plus qu’une seule base de données. Cela place le logiciel en porta-faut par rapport à la législation.

—

Il faut donc revoir les modalités de la fonction de libération en réduisant sa porté de manière à empêcher le changement de base de données.

—

Modification de la politique de libération réalisée sur l’API de validation.

Adaptation du site https://www.bedesk-express.com nécessaire.

—

Page d’administration de compte sur BeDesk-Express.com adaptée en conséquence.

Le cas échéant, s’il faut absolument libérer l’activation de manière à permettre le changement de base de données associée, l’utilisateur peut prendre contact avec le support technique qui prendra note de l’évènement dans le journal d’opérations techniques du compte à toute fins utiles (conformément aux exigences légales).

Dans la procédure de démarrage, lorsque la boîte de dialogue annonçant la fin imminente d’un contrat apparaît, l’interface graphique de l’application se fige.

Il y a un deadlock entre l’attente de la fin de la procédure de démarrage et l’attente de la boîte de dialogue.

Confirmé.

Idem avec les autres boîtes de dialogue sur Windows.

Tests à réaliser.

Ce phénomène est lié au contexte d’exécution des fonctions d’impression.

Il y a manifestement un conflit entre le processus qui gère l’interface graphique et le rendu des documents en tâche de fond.

Confirmé.

Suppression d’un synchroniseur obsolète.

tests en cours...

Le système de sauvegarde de sécurité local est malheureusement très mal utilisé par certains utilisateurs.

Certains en effet essayent de restaurer une sauvegarde antérieure sans ce soucier de l’impact sur la suppression éventuelle des dernière données saisies.

Le système de sauvegarde ne sert bien entendu pas à supprimer des données. Mais si on n’y prend pas garde, il pourrait permettre une telle suppression par écrasement.

De plus, chaque base de données est signée. Chaque signature est unique et attachée à une seule base de données.

Lorsqu’on effectue une sauvegarde de sécurité, on sauve également la signature. Lorsqu’on restaure une sauvegarde, on restaure donc une version de la même base de données que celle d’origine et non un duplicata.

Le seul système de sauvegarde fiable devrait être le service VB4B car il effectue toutes les vérifications nécessaires.

Seul devrait resté la fonction de restauration pour permettre la restauration de fichiers de sauvegarde fournis par le support technique.

—

Mauvaise utilisation du système de sauvegarde de sécurité local

Le problème de l'activation multi-comptes

Si l’utilisateur effectue une copie à la main des fichiers d’une base de données pour les placer dans un autre dossier, ou forger une nouvelle base de données locale sous un autre nom mais en essayant de conserver la même identité, la signature de la base de données doit être révoquée automatiquement.

Le support technique doit pouvoir forger une identité “indépendantes” de manière à permettre la dissociation d’une base de données de son identité d’origine sans entraîner la suppression du contenu antérieur.

De cette manière la conservation des données d’origine peut être maintenue tout en dissociant le contenu d’une identité d’origine.

Objectif : Aucune perte de données.

La législation impose une modification dans la méthode de saisie des paiements reçus.

Le logiciel semble se désactiver intempestivement à chaque redémarrage ou de manière plus aléatoire au bout d’un certain temps.

Ce problème touche les versions suivantes:

• 16.x
• 17.0
• 17.1
• 17.2

Est résolu avec la révision 17.3.160.

—

Solution confirmée avec 17.3.160.

L’intégration de Java 9 en remplacement de Java 8 est planifiée pour BeDesk-Express v17.

Ce remplacement apportera de nombreuses améliorations et corrections de bugs dans le composant Java nécessaire à l’exécution du programme BeDesk-Express.

—

Nombre de jours avant disponibilité : http://www.java9countdown.xyz/

—

Bien que la sortie officielle de java 9 est prévue le 27/07/2017, nous ne le proposerons pas avant début septembre, pour pouvoir assurer un meilleur support du basculement.

—

Date de sortie repoussée par Oracle au 21 septembre 2017.

Cela va certainement retarder légèrement la sortie de la version 17.9 du logiciel de manière à disposer de cette intégration (si possible avant la fin du mois).

Vérification de la plateforme de gestion des activations (partie TOKEN).

On constate que certains utilisateurs voient leur logiciel se désactiver (selon les utilisateurs “intempestivement”).

De notre coté, en écartant les cas où le contenu d’une base de données à changé entre la dernière session et la nouvelle, il reste quelques cas où le TOKEN ne correspond pas.

Nous étudions donc le problème pour en trouver l’origine.

—

Travaux sur l’infrastructure : Contrairement à ce qui était signalé au départ, certains accès dont le TOKEN était périmé arrivaient à passer. Ceci suite à un bug dans d’anciennes versions du logiciel. Suite à ce constat, nous avons modifier légèrement la procédure de renouvellement du TOKEN de manière à résorber cette faille.

—

TOKEN issu d’une restauration de fichier externe : L’utilisateur peut en effet utiliser un système de sauvegarde externe indépendant du logiciel BeDesk et restaurer des fichiers dans un état antérieur. Bien entendu, le TOKEN ainsi restauré ne correspond pas à celui attendu par le système de vérification. Ceci n’est donc pas un bug, mais la preuve que le système de protection fonctionne correctement.

—

Jusqu’à présent, l’utilisateur pouvait modifier certains paramètres “critiques” comme le nombre de décimales à prendre en compte dans les calculs des totaux.

La loi exige à présent de placer les montants dans une blockchain (liste de hashes chaînés) ce qui impose l’obligation de figer définitivement l’arrondi et les caractéristiques des calculs de l’application en fonction de la monnaie utilisée.

Ainsi, il faut supprimer les paramètres de configuration de la devise, ainsi que les caractéristiques du calcul de l’arrondi.

L’utilisateur choisi le signe de la monnaie ainsi que les caractéristiques du calcul de l’arrondi liée à la monnaie en choisissant sont pays.

Il peut personnaliser le nombre de décimale et les caractéristiques locales une fois pour toute lors du tout premier démarrage de l’application à l’aide de l’assistant de configuration.

Il n’est plus possible de modifier ces paramètres par la suite car cela impliquerait de briser la blockchain des montants (en recalculant ceux-ci, le logiciel doit arriver exactement aux mêmes valeurs que celles archivées dans la blockchain - bien entendu, si l’arrondi est modifié, les résultats sont forcément différents -il n’est donc plus possible de les modifier ultérieurement).

C’est pour accorder le logiciel aux contraintes légales que cette restriction est appliquée.

Jusqu’à présent, bien que la numérotation des documents ne peut être modifiée en interne, il était possible de personnaliser le mode de numérotation via le panneau de configuration de l’application.

Malheureusement, cette possibilité n’est plus conforme aux exigences légales qui impose d’archiver les documents de manière infalsifiables (c-à-d, inaltérables).

Or, en personnalisant le mode de numérotation, on peut changer la forme du numéro (sans toutefois changer de numéro à proprement parlé). Pour rencontrer les exigences légales, la personnalisation du format du numéro de série n’est plus acceptable, ce pour conserver les documents archivés absolument identiques aux originaux.

Le format du numéro de série des documents pourra donc être choisi au moment de la toute première configuration de la base de données, mais ne pourra plus être modifiée par la suite.

Ceci pour conformer le logiciel aux exigences légales.

L’indication du numéro de dossier dans la formule de numérotation de série des documents peut prêter à confusion (il ne fait en effet pas partie du numéro de série à proprement dit - il est purement indicatif).

De plus, cette indication peut varier en fonction du dossier dans lequel on attache le document.

Aussi, pour conformer le logiciel aux nouvelles exigences légales, le numéro de dossier dans la numérotation de série est dépréciée.

Ce numéro peut être inséré dans le corps du document, toutefois, il ne pourra plus figurer dans le numéro de série.

• Le format de numérotation pourra être sélectionné au lancement de l’assistant du premier démarrage, mais plus ensuite.
• Il faut déterminer comment aider les utilisateurs qui ont inséré le numéro de dossier dans le format du numéro de série à le retirer.

On n’est pas obligé de supprimer les numéros de dossiers du format des numéros de série.

Le numéro de dossier est purement indicatif.

Cependant, dès lors qu’un document est validé, on ne devrait plus pouvoir changer son dossier d’origine.

Caractéristiques de validation des documents.

Lorsqu’un document est validé, un certain nombre d’informations ne peuvent plus être modifiées:

• Date
• Client
• Numéro de série
• Montants
• Liste des articles
• Numéro de dossier

cette stratégie n’est pas obligatoire à condition de faire apparaître toutes les modifications apportées à un document dans le journal d’audit sécurisé.

Le cas échéant, une correction tout à fait légitime peut être envisagée à condition de la justifier par une explication.

Le logiciel propose donc automatiquement de fournir un justificatif de toute modification apportée à un document qui a été imprimé ou exporté en Pdf.

Notez que la validation est obligatoire tant que le document n’a pas reçu de numéro. BeDesk valide donc systématiquement les documents dés lors qu’ils sont enregistrés.

La validation est donc implicite lors de l’enregistrement du document.

Mise à jour ‘Upstream’ de keyListDB.

Intégration et implémentation de l’agent de réplication.

Nécessite des modifications importantes dans l’application.

Remplacement de l’ancienne TaskList par un nouveau paquetage interne bedesk.worker.

Le Worker étant un daemon qui tourne en tâche de fond et qui envoie des tâches bloquantes dans le Thread AWT-EventQueue.

Chaque tâche est exécutée une après l’autre.

Un délais peut être fixé avant le lancement d’une tâche, sinon elle est lancée immédiatement après la fin de le précédente.

Le worker permet de découper les tâches longues et d’ordonner l’enfilade des tâches de manière à pouvoir exécuter chacune dans le contexte du même thread AWT-EventQueue.

De cette manière, on évite les problèmes de concurrence et on permet à l’interface de s’actualiser durant les processus longs.

CARACTERISTIQUES:

Le nouveau Worker dispose de 5 niveau de priorité et permet donc l’insertion de tâches prioritaires dans la file d’attente.

On peut travailler ne libérant un peu de temps entre les tâches de manière à permettre le rafraîchissement de l’interface.

Combat les dead-locks en ordonnant les tâches successives par priorité.

Dans l’implémentation initiale, chaque tâche reçoit un délai d’attente en dehors de l’AWT-EventQueue.

Cela permet de libérer l’AWT-EventQueue pour d’autres tâches.

Cependant, si une tâche lance un délai d’attente, cette tâche bloque l’ensemble de la file d’attente.

Il faut donc ordonnancer les tâches en fonction de la priorité (une file d’attente par niveau de priorité).

Ensuite, en fonction de la file, on prévoit un délai d’attente hors EventQueue pour libérer l’UI.

Sur Windows l’URI des propriétés est héritée du système de fichier avec des ‘\’ au lieu de ‘/’ pour définir l’arborescence.

Un garde-fou a du être implémenté pour uniformiser cette stratégie en la fixant définitivement avec des séparateurs ‘/’.

Lorsqu’on a sélectionné une base de données et qu’on la lance sur un ordinateur lent, le BeDesk-Starter réitère le lancement si le précédent lancement a échoué (ou n’a pas répondu dans un temps imparti).

Or, sur un ordinateur plus lent, le délai de réponse peut être beaucoup plus long que prévu étant donné la nécessité de réaligner l’agent de réplication.

Un garde-fou est donc nécessaire pour interdire le redémarrage dès lors que l’application principale a été lancée sur une base de données.

De temps à autres, les requêtes REST peuvent recevoir une réponse du type 5xx :

• 500 Internal Server Error : Erreur interne du serveur.
• 501 Not Implemented : Fonctionnalité réclamée non supportée par le serveur.
• 502 Bad Gateway ou Proxy Error : Mauvaise réponse envoyée à un serveur intermédiaire par un autre serveur.
• 503 Service Unavailable : Service temporairement indisponible ou en maintenance.
• 504 Gateway Time-out : Temps d’attente d’une réponse d’un serveur à un serveur intermédiaire écoulé.
• 509 Bandwidth Limit Exceeded : Utilisé par de nombreux serveurs pour indiquer un dépassement de quota.
• 510 Not extended (RFC 277415) : la requête ne respecte pas la politique d’accès aux ressources HTTP étendues.
• 511 Network authentication required (RFC 65859) : Le client doit s’authentifier pour accéder au réseau. Utilisé par les portails captifs pour rediriger les clients vers la page d’authentification.

Une meilleur prise ne charge de ce type d’erreur doit être mis en place.

Une correction du client HTTPS lui permet à présent de valider le code de réponse HTTP.

Jusqu’à présent, tant qu’il y avait une réponse, même avec un code différent de “200 Ok”, celle-ci était prise ne considération comme une réponse valide.

A présent, on peut filtrer les réponses en fonction du code retourné. Ainsi, en cas d’erreur 504 par exemple, un autre chemin est testé. Ce qui n’était pas le cas (car une réponse http était quand même fournie).

Les nouveaux essais sont répété avec une adaptation automatique du délai entre chaque essai. Plus il y a d’erreurs et plus le délai s’allonge. S’il n’y a pas d’erreur le délai est réduit automatiquement.

De cette manière, si la connexion est de mauvaise qualité ou instable, le délai entre les essais sera plus long et s’adaptera aux besoins du poste local en fonction de la qualité de la connexion disponible.

L’utilisateur est informé des erreurs HTTP et peut suivre les nouvelles tentatives dans la barre de titre de l’application principale.

Prise en charge distincte de l’erreur 511 qui signale la nécessité de s’authentifier via le portail captif du fournisseur d’accès internet.

Les messages d’erreur affichés par le client TRK4B contiennent à présent le dernier code de réponse HTTP et le message associé pour faciliter le dépannage.

Lorsqu’on recherche un rapport mensuel, il calcule les dates sur le 1/01/1970.

Par contre lorsqu’on lance le même rapport entre 2 dates et qu’on fixe les dates correctement, il n’y absolument aucun problème.

Il s’agit d’un effet de bord lié au problème  FS#1259 .

On a donc carrément éliminé et remplacé des fonctions les quelques occurrences où DateFormat.getDateInstance(DateFormat.SHORT, LOCALE) était utilisé.

On utilise à présent Calendar.getInstance() à la place en l’associant à un parser maison pour traiter directement le format de date EU/FR : dd/mm/yy, dd/mm/yyyy ; mm/yy, mm/yyyy et tt/yy, tt/yyyy.

En cas de problème, le système est résiliant et retourne la date par défaut 1/01/1970, si la date ne peut être interprétée. Il accepte cependant les ‘-’ et les ‘.’ comme séparateurs alternatifs (qui seront normalisés en ‘/’).

La structure Java TreeMap permet de trouver facilement la première ou la dernière clé.

Cependant, contrairement aux autres méthodes du même genre dans la classe, au lieu de retourner null en cas d’absence d’enregistrement, ces méthodes (firstKey et lastKey) retournent une exception “NoSuchElementException”.

On a donc créé une nouvelle classe qui surcharge TreeMap pour intercepter ces exceptions et retourner null à la place.

Ce problème est un effet de bord du problème  FS#1259 .

La date d’échéance des abonnements est mal interprétée.

Adaptations nécessaires.

Mauvaise interprétation de la date d’échéance. Tous les documents avec abonnement sont inclus dans la liste.

Le backend TRK4B rencontre un problème avec les interrogations REST via CURL.

Curl ajoute l’en-tête “Expect: 100-continue” dés lors que le corps de la requête est plus volumineux.

Curl s’arrête d’envoyer les données tant que le serveur ne retourne pas “HTTP/1.1 100-continue\n\r\n\r”.

L’interface REST du serveur Track prend donc en considération cette en-tête et retourne “HTTP/1.1 100-continue” tant que la lecture du corps (basé sur la taille content-length prévue) n’est pas terminée.

Lorsqu’on essaye d’exporter certains rapports en PDF, une erreur interne se produit et bloque la procédure.

Il est toutefois possible de quitter le logiciel proprement.

L’erreur ne se produit pas systématiquement, mais seulement à quelques reprise, pour finir par fonctionner correctement.

Détails de la fenêtre de débogage:

HTMLDOC *** AutoCheckFontSize patching font size 10 -> 11 ***
HTMLDOC *** AutoCheckFontSize patching font size 6 -> 7 ***
CREATE PageClassicHeaderImage : javax.swing.ImageIcon@1efe5d6a
Exception in thread "Thread-20" java.lang.NullPointerException
        at javax.swing.text.FlowView$FlowStrategy.layoutRow(FlowView.java:563)
        at javax.swing.text.TextLayoutStrategy.layoutRow(TextLayoutStrategy.java:127)
        at javax.swing.text.FlowView$FlowStrategy.layout(FlowView.java:477)
        at javax.swing.text.TextLayoutStrategy.layout(TextLayoutStrategy.java:110)
        at javax.swing.text.FlowView.layout(FlowView.java:201)
        at javax.swing.text.BoxView.setSize(BoxView.java:397)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:366)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:348)
        at javax.swing.text.BoxView.layout(BoxView.java:708)
        at javax.swing.text.BoxView.setSize(BoxView.java:397)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:366)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:348)
        at javax.swing.text.BoxView.layout(BoxView.java:708)
        at javax.swing.text.BoxView.setSize(BoxView.java:397)
        at javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:1722)
        at javax.swing.plaf.basic.BasicTextUI.modelToView(BasicTextUI.java:1046)
        at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
        at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
        at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
        at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
        at bedesk.pageeditor.PrintableEditorPane.getNumberOfPages(Unknown Source)
        at bedesk.pageeditor.PrintableEditorPane.b(Unknown Source)
        at bedesk.printing.Imprimer$MetaContext.getBook(Unknown Source)
        at bedesk.printing.Imprimer$MetaContext.c(Unknown Source)
        at bedesk.printing.Imprimer.a(Unknown Source)
        at bedesk.RepportSet$MyPrivatePDFThread.run(Unknown Source)

L’impression est lancée à partir d’un Thread indépendant et non à partir de l’AWTEventQueue:

WARNING : Task.invoke from Thread[Thread-11,6,main](bedesk.RepportSet$MyPrivatePDFThread)

Certaines données ne sont donc pas nécessairement disponibles au moment où le processus se poursuit (d’où l’erreur null pointer).

Solution : Remplacer le thread MyPrivatePDFThread par une structure Runnable que l’on exécute via le Worker.

Les méthodes compilToPrintableObject() et getBook() de Imprimer.MetaContext ont été également patchées pour s’exécuter uniquement dans le contexte de l’AWTEvenQueue.

Le paquetage sun.misc.unsafe n’est plus accessible à partir de Java 9.

Or, le paquetage Abstrasy utilise ce paquet pour les types array-of-*.

Il faut trouver une solution.

Pour le type array, on peut utiliser AtomicReferenceArray.
Pour les types array-of-ints et array-of-longs, on peut utiliser AtomicIntegerArray et AtomicLongArray.

Le souci c’est pour les autres types. Il n’existe pas de classe Atomic[*]Array correspondante.

Ce référer à VarHandle du java 9 : http://openjdk.java.net/jeps/193

La vérification du type “Registrable” échoue lorsque l’on ouvre à nouveau la boîte d’activation des licences.

La requête est mal formatée et n’est donc pas acceptée pour revalidation.

La requête en cas de revalidation n’est pas traitée de la même manière qu’en cas de validation.

Ainsi, depuis la version 16.4, lorsqu’on ouvrait la boîte d’activation et qu’on avait un code Logistique déjà validé, la requête échouait.

Ce problème est résolu.

Dans certains cas, l’exécution des tâches de resynchronisation de la réplication s’exécute dans le processus EventQueue.

Cela pose un problème car lorsqu’on ouvre une boîte de dialogue modale, celle-ci bloque l’EventQueue.

Pour essayer de résoudre ce problème, on peut par exemple utiliser le Worker et lancer la tâche en arrière plan mais avec une forte priorité. Cela laisse l’EventQueue terminer la tâche en cours sans bloquer l’UI.

Nécessite plus de retour de la part des utilisateurs concernés.

Mise à jour “upstream” KeyListDB:

Ajout d’une structure PseudoMerkleTrieSHA256 (voir:https://en.wikipedia.org/wiki/Merkle_tree) capable de calculer très rapidement la clé de hashage SHA-256 de l’ensemble du contenu d’une base de données.

Ceci permet d’améliorer l’agent de réplication qui ne teste plus la somme d’auto-contrôle de chaque bucket indépendamment les uns des autres, mais bien l’ensemble du contenu répliqué de la base de données.

De plus, la méthode utilisant un crypto-hash fiable, cela rend extrêmement difficile toute falsification des données du poste client sans que celle-ci ne puisse être décelée.

Pour pouvoir fournir des paquet Java 9, il faut attendre la mise à niveau des outils de développement.

Mac OS X 10.13 “High Sierra” sera disponible normalement dès ce 25 septembre 2017.

Le profil de compatibilité du logiciel doit être adapté en conséquence.

La compatibilité sera assurée en même temps que la migration vers Java 9.

L’intégration est toujours en cours suite aux retards accumulés à la sortie du Java 9 par Oracle et la disponibilité des outils pour cette nouvelle version.

Cette tâche est en attente de la fin d’intégration Java 9.

Prise en charge à partir de macOS X10.10 minimum.

Lorsqu’on valide la saisie dans la fenêtre d’activation de la licence, on reçoit un message selon lequel aucun code d’activation n’a été saisi, puis la procédure semble se terminer correctement avec une activation.

Avec Java 9, lorsqu’une boîte de dialogue modale est masquée, elle perd la modalité et l’application reçoit la main alors que la fenêtre de dialogue n’a pas encore été détruite.

On utilise donc le worker pour effectuer les opérations différées dans le bon ordre et gérer la main.

Nécessite un correctif de Java 9 et/ou du pilote d'impression

Contournement du problème

Descriptif du problème

Liste des modèles d'imprimante affectés par le souci que nous avons répertorié:

Journal de débogage

AUTO-CONFIGURATION> RECHERCHE DE LA FILE D'IMPRESSION PAR DEFAUT... PATIENTEZ...
AUTO-CONFIGURATION> FILE D'IMPRESSION TROUVEE : Java Printing sur Brother MFC-8520DN Printer ACCUEIL1...
Before Attributes:
   media-printable-area = (25.4,25.4)->(159.102,246.238)mm[javax.print.attribute.standard.MediaPrintableArea]
   media = iso-a4[javax.print.attribute.standard.MediaSizeName]
Utilisation de l'ancien systeme d'impression... [ignorer le selecteur]
Service non trouve ... Tentative du 2ieme type... Avons-nous de la chance?...
MainWindow Activated...
Service d'impression disponible Brother MFC-8520DN Printer ACCUEIL1
setPrintService...
Print to:Brother MFC-8520DN Printer ACCUEIL1
Attributes:
   media-printable-area = (25.4,25.4)->(159.102,246.238)mm[javax.print.attribute.standard.MediaPrintableArea]
   media = iso-a4[javax.print.attribute.standard.MediaSizeName]
MyPrintServiceUI.getPaper - PrintableArea :(25.4,25.4)->(159.102,246.238)mm
                                     :X,Y = (72.0,72.0) lpi
                                     :W,H = (450.997802734375,697.9974975585938) lpi
MyPrintServiceUI.getPaper - Media Size    :iso-a4
                                     :210.0x297.0 mm
                                     :595.2755737304688x841.8897705078125 lpi
MyPrintServiceUI.getPaper - PrintableArea :(25.4,25.4)->(159.102,246.238)mm
                                     :X,Y = (72.0,72.0) lpi
                                     :W,H = (450.997802734375,697.9974975585938) lpi
MyPrintServiceUI.getPaper - Media Size    :iso-a4
                                     :210.0x297.0 mm
                                     :595.2755737304688x841.8897705078125 lpi
HTMLDOC *** AutoCheckFontSize patching font size 6 -> 7 ***
<#> Report length : 5130
<#> Report created in 292ms...
HTMLDOC *** AutoCheckFontSize patching font size 10 -> 11 ***
HTMLDOC *** AutoCheckFontSize patching font size 6 -> 7 ***
CREATE PageClassicHeaderImage : javax.swing.ImageIcon@74d65d9e
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at java.desktop/sun.print.RasterPrinterJob.setAttributes(Unknown Source)
        at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(Unknown Source)
        at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
        at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)
        at bedesk.AppAction.printDocument(AppAction.java:264)
        at bedesk.ui.iconsbar.document.DocumentsIconsBar$3.actionPerformed(DocumentsIconsBar.java:106)
        at java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
        at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
        at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
        at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
        at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.Component.processEvent(Unknown Source)
        at java.desktop/java.awt.Container.processEvent(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.EventQueue.access$500(Unknown Source)
        at java.desktop/java.awt.EventQueue$3.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$3.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)

java.lang.NullPointerException
        at java.desktop/sun.print.RasterPrinterJob.setAttributes(Unknown Source)
        at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(Unknown Source)
        at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
        at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)

CREATE PageClassicHeaderImage : javax.swing.ImageIcon@730a4a8c
         log> PatchedPrintService.getDefaultAttributeValue(javax.print.attribute.standard.JobSheets)
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at java.desktop/sun.print.RasterPrinterJob.setAttributes(Unknown Source)
        at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(Unknown Source)
        at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
        at java.desktop/sun.print.Win32PrintJob.pageableJob(Unknown Source)
        at java.desktop/sun.print.Win32PrintJob.print(Unknown Source)
        at java.desktop/sun.print.RasterPrinterJob.spoolToService(Unknown Source)
        at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
        at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)

         log> PatchedPrintService.getDefaultAttributeValue(javax.print.attribute.standard.PrinterResolution)
PatchedPrintService : NULL javax.print.attribute.standard.PrinterResolution
PatchedPrintService : PATCHING javax.print.attribute.standard.PrinterResolution = 30000x30000 dphi
       - printer-resolution = 30000x30000 dphi [javax.print.attribute.standard.PrinterResolution]

CREATE PageClassicHeaderImage : javax.swing.ImageIcon@2ca36e49
         log> PatchedPrintService.getDefaultAttributeValue(javax.print.attribute.standard.JobSheets)
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at java.desktop/sun.print.RasterPrinterJob.setAttributes(RasterPrinterJob.java:1240)
        at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(WPrinterJob.java:696)
        at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1510)
        at java.desktop/sun.print.Win32PrintJob.pageableJob(Win32PrintJob.java:573)
        at java.desktop/sun.print.Win32PrintJob.print(Win32PrintJob.java:390)
        at java.desktop/sun.print.RasterPrinterJob.spoolToService(RasterPrinterJob.java:1428)
        at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1516)
        at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)
        at bedesk.AppAction.printDocument(AppAction.java:264)
        at bedesk.ui.iconsbar.document.DocumentsIconsBar$3.actionPerformed(DocumentsIconsBar.java:106)
        at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
        at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
        at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
        at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
        at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:269)
        at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
        at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
        at java.desktop/java.awt.Component.processMouseEvent(Component.java:6578)
        at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3343)
        at java.desktop/java.awt.Component.processEvent(Component.java:6343)
        at java.desktop/java.awt.Container.processEvent(Container.java:2259)
        at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4961)
        at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2317)
        at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
        at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
        at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4539)
        at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4480)
        at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2303)
        at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2758)
        at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:766)
        at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717)
        at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:99)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:739)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:737)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89)
        at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:736)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Java 9, révision 9+181, introduit une régression qui empêche l’impression normale des documents.

Le problème se situe dans les attributs d’impression par défaut fournis par le PrintService de Windows pour certains modèles d’imprimantes où la recherche des données PrinterResolution par défaut retourne null alors que l’attribut est marqué comme supporté.

Dans ce cas, nous avons créé une classe de PrintService qui enveloppe le PrintService fourni par le système.

Lorsque le problème se manifeste, le wrapper corrige l’attribut manquant par une valeur par défaut qui devrait être supportée par la plupart des imprimantes.

ATTENTION!

Selon le mode de recherche du service d’impression, le PatchedPrintService initial peut être écrasé par le PrintService original défaillant.

Il faut donc s’assurer que c’est bien un PatchedPrintService qui est utiliser en finalité.

KeyChain 0 incompatible entre la version 17.9.213 et la version 17.10.219.

On passe à la KeyChain 1 avec la version 17.10.220.

—

Ok.résolu.

Lorsqu’on fait une recherche d’article et que la liste des propositions s’affiche la hauteur des lignes est trop petite.

—

Confirmé!...

—

Recherche en cours.

—

Rectifié.

Lorsqu’on crée une nouvelle base de données, l’assistant de configuration initial peut perdre le focus. Les actions de l’utilisateur sont ensuite ignorées.

—

Le souci provient de la délégation vers des objets externalisés notamment le composant bedesk.exthtml.ObjectizedRoundButton.

Ce composant peut être facilement et avantageusement remplace par un élément de style “button”. ceci ne requière aucune liaison et l’interaction en est même améliorée.

—

ok. Fonctionne pour moi.

Les utilisateurs auront besoin d’une attestation conforme à partir de la version 18.

Celle-ci sera disponible en téléchargement PDF à partir de leur page d’administration de compte sur BeDesk-Express.com.

LogMapEngine fourni le nécessaire pour produire et gérer facilement un ensemble de fichiers Log mappés.

Le mappage permet de retrouver facilement une ligne du flux de logs sans devoir lire l’ensemble des fichiers.

L’ensemble de logs est constitué de fichiers ordonnés dont la taille limite est spécifiée. Lorsque qu’un fichier de l’ensemble a atteint cette taille, le flux est orienter vers un nouveau fichier. Les blocs d’écriture ne sont toutefois pas coupé à la limite indiqué. L’écriture commencée dans un fichier est finalisée avant le passage au fichier suivant.

L’index de mappage contient donc le numéro du fichier log, la position relative et la taille de la ligne.

Les fichiers logs peuvent être enregistrés en texte clair (éventuellement en format ouvert comme csv, txt ou tsv).

Produire des fichiers logs dans un format ouvert facilement récupérable même sans avoir besoin du logiciel :

Nous avons choisi le format TSV (Tab-Separated Value : https://en.wikipedia.org/wiki/Tab-separated_values) extrêmement facile à consulter dans n’importe quel tableur où a importer dans une base de donnée tabulaire.

Archivage en temps réels : L’administration fiscale demande qu’une archive soit fournie à la clôture journalière, mensuelle et annuelle (en fonction de l’exercice). Cette clôture permet de connaître le CA de la période, de disposer des totaux perpétuels et de toutes les informations qui permettent de réaliser un audit des données comptables.

Le logiciel générera les fichiers d’archivage en temps réels au fur et à mesure de son utilisation. Ainsi, ces fichiers sont disponibles à tous moments même sans avoir besoin de lancer le programme BeDesk.

Ces fichiers sont également inclus lors de la sauvegarde à distance. Cela garanti la disponibilité d’une sauvegarde pérenne sur un support non modifiable par l’utilisateur lui-même.

Il est également possible d’exporter un période dans un fichier unique répondant aux exigences de l’administration.

Les opérations enregistrées concernent la traçabilité des paiements et la facturation.

Répondre aux exigences d’inaltérabilité et de sécurisation : Comme dans le cas d’autres éditeurs, nous avons choisi le chaînage de bloc pour assurer l’inaltérabilité du journal d’audit.

Chaque nouvelle ligne comporte une signature fiable (un hash d’ordre cryptographique) correspondant au hashage du contenu de la ligne précédente ajouté du contenu de la nouvelle ligne proprement dite.

Ainsi, il devient extrêmement difficile de modifier (”altérer”) une ligne qui précède. Plus de nouvelles lignes sont ajoutées et plus cela renforce l’inaltérabilité et la sécurité des données précédentes.

Le chaînage étant continu, on peut facilement extraire les lignes correspondant à une période données. Le contrôle peut être assez facilment réalisé simplement en fournissant le hash précédent comme clé de certification de l’ensemble de la chaîne.

Ce journal est enregistré à la base au format TSV et est donc par conséquent parfaitement lisible avec n’importe quel programme de tableur, base d données ou même un simple bloc-note.

Pour optimiser l’espace de stockage, on utilise un flux Gzip pour compresser les ajouts séquentiels. GZip a en effet la particularité de permettre l’ajout de contenu supplémentaire à la fin d’un fichier existant. Le taux de compression réduit considérablement l’espace nécessaire tout en restant lisible sans nécessiter un logiciel spécifique.

Le journal constitue la source de la piste d’audit ainsi que l’archive sécurisée. Sa structure garanti son inaltérabilité. De plus, il n’est pas nécessaire de créer des fichiers distincts pour archive. En effet, le principe de sécurisation utilisé (blockchain) impose l’obligation de conserver toutes les transactions enregistrées depuis le point de départ de la chaine.

Le journal contient un grand nombres de données de traitement dont la cohérence peut être aisément contrôlées avec n’importe quel tableur ou logiciel de base de données capable d’importer le format TSV ou CSV.

Les clôtures annuelles, mensuelles et journalière sont également incluses et horodatées.

Ainsi, même dans le cas où il ne serait pas possible d’utiliser le logiciel BeDesk, il suffit d’accéder aux fichiers du journal disponibles en clair et format ouvert dans le dossier de travail du logiciel.

Pour ce qui est de la conservation, le système de sauvegarde à distance VB4B inclut également le journal dans son processus de conservation des données. Celles ci étant récupérable facilement à partir de la page d’administration du client.

Les champs enregistrés sont les suivants:

Il est plus judicieux de disposer d’un journal distinct pour chaque partie à archiver et sécuriser.

Un journal distinct pour les paiements reçus est donc approprié.

Ce journal est enregistré au format TSV et est donc par conséquent parfaitement lisible avec n’importe quel programme de tableur, base d données ou même un simple bloc-note.

—

FINALEMENT, LES PAIEMENTS SERONT INTEGRES DANS LE JOURNAL DES FACTURE.

Ceci est plus logique. Impossible d’encoder un paiement reçu sans avoir préalablement créé une facture.

Le journal des paiements indépendant des factures ne sera pas implémenté donc.

Pour être conforme à la loi, exporter une facture vers un fichier PDF, revient à l’imprimer.

Aussi, lorsqu’on exporte un document, celui-ci est dorénavant marqué comme imprimé.

Un service ce cachet ou de tampon serveur permet d’appliquer une signature numérique cryptée par un certificat vérifiable.

Cette signature est l’équivalent numérique d’un cachets horodatée pour permettre de situer dans le temps l’heure à laquelle la signature a été générée.

Ce cachet numérique certifie donc l’authenticité des données dont la signature a été fournie et l’heure à laquelle il a été généré.

Pour vérifier un cachet, il faut calculer la signature des données d’origine, ajouté horodatage retourné par le service. Calculer une nouvelle clé de hash à partie de cet assemblage et comparer avec la clé de hash obtenue par décryptage à l’aide de la clé publique du certificat.

Ce procédé empêche toute modification des données d’origine. Il empêche aussi la production de fausses preuves ultérieures car la nécessité d’obtenir un nouveau cachet implique une nouvelle date et heure de création.

On a constaté qu’une différence d’un centime pouvait apparaître après recalcule des montant des documents importés.

Cette erreur se remarque plus précisément avec les documents où les prix sont introduits TTC.

Lorsque certains montants sont enregistrés et qu’on revient sur l’UI, le montant change suite à un souci d’arrondi.

Le souci provient de la compression double (64 bits) vers floats (32 bits) de l’OpenDDN (composant de KeylistDB).

Ce souci est apparu avec Java 9. Le retrait temporaire de cette compression (50%) permet d’éviter des soucis avec de certains montants de 8 chiffres.

Lorsqu’une session redémarre et que de nombreuses modification ont été réalisées sur d’autres postes, il y un grand risque de contrôler une piste d’audit non finalisée.

En outre, pour pouvoir contrôler une piste d’audit, il faut s’assurer que la file d’attente des blocs en cours de minage est vide.

On ne peut pas insérer de nouveaux blocs dans la chaîne et en même temps la contrôler. Le contrôle doit donc s’effectuer hors-ligne avec une file d’attente vide.