BeDesk-Express

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.

On ne peut pas supprimer de référence dans le stock.

Cela peut créer un problème de cohérence référentielle dans la base de données (problème lié à l’OCCL).

De plus, la suppression des références supprime également l’historique lié à la référence.

—

Dans les révisions ultérieures, nous ajouterons une méthode qui permet de désactiver et de mieux gérer les références au niveau de l’UI.

Une série de boites de dialogue d’avertissements sont ajoutées pour prévenir les problème de cohérence de données (lorsqu’on modifie des données alors que d’autres données sont déjà en cours d’édition).

Contrairement aux autres types de données, les documents s’éditent directement sans passer par un dialogue modale.

Il faut donc prémunir l’utilisateur contre toute autre modifications alors qu’un document est en cours d’édition.

Sur certains mac, à la fin du chargement de l’UI de l’application principale, le simple fait de cliquer dans le menu principal déclenche des effets de bords.

Il semble que cela soit lié au thread de contrôle de la piste d’audit qui se réalise en tâche de fond.

Il arrive de manière totalement aléatoire que la liste des tâches de la procédure de démarrage ne se lance pas à l’ouverture de l’UI de l’application principale.

Aucune exception n’est envoyée. On ne sait donc pas pourquoi elle ne démarre pas.

Si on utilise une police embarquée avec le logiciel, il n’y a jamais de souci lors de l’impression PDF.

Cependant, il peut arriver qu’une version d’une des polices embarquées soit aussi installée sur le système.

Le système d’impression et de rendu utilise donc la version du système plutôt que celle qui est embarquée avec le programme.

Le souci, c’est que la version de la police qui est installée sur le système n’a peut-être pas la même licence que celle que nous fournissons avec le logiciel.

Si celle-ci dispose d’une licence qui empêche son intégration dans les PDF, elle peut être protégée par DRM.
Celui-ci agit comme une sorte de contre-mesure qui pénalise le processus de rendu qui a essayé de l’utiliser d’une manière inappropriée.

Cela occasionne des erreurs de rendu ici et là.

Aussi, au moment du démarrage, le logiciel BeDesk teste toutes les polices du système, il détermine si une police peut être ou non utilisée.

Il le fait dans un autre processus qui est indépendant du système de rendu et d’impression. Un processus qui est sacrifié de toute façon, donc sans répercussion.

Le souci, c’est que lorsqu’une police est validée, jusqu’ici, c’est son nom qui est la clé.

La version de la police incompatible peut donc passer pour compatible. Ainsi, dès lors que l’on utilise une seule fois cette police (pour un aperçu ou un rendu PDF, par exemple), cela entraîne des erreurs dans l’affichage de l’application et bloque le système d’impression PDF.

—

Il faut donc également comparer le contenu du fichier source de la police.

Si le cache de polices contient des fichiers altérés, on doit les remplacer.

On doit tester non seulement la police, mais aussi son fichier avant de l’utiliser.

Lorsqu’on envoie une facture par e-mail (volet de fonction “Communiquer” à droite du panneau Synthèse), l’évènement IMPRIME n’est pas ajouté au journal.

Lorsqu’on envoie un lot de factures par e-mail via une opération par lot, l’évènement IMPRIME n’est pas enregistré dans le journal.

Lorsqu’un document est exporté en PDF, son état d’impression est modifié vers TRUE.

La méthode effectue bien ce changement. Toutefois, c’est la référence de l’ancienne révision du document qui est enregistré et non la nouvelle.

—

Ce bug a des répercussion sur plus autres signalement et sa résolution les corrige également par effet de bord.

—

Corrigé.

On a constaté que certains problèmes d’OCCL ne proviennent pas d’un conflit de version au moment d’ajouter un nouvel enregistrement. Le leader devrait disposer de toutes les données pour pouvoir enregistrer une nouvelle données supplémentaire. Il a donc forcément contrôlé l’OCCL avant d’enregistrer dans le flux de réplication.

Cependant, on constate que certains utilisateurs rencontre un souci d’OCCL alors qu’ils sont seuls à travailler sur la base de données.

Après vérification, il s’avère que la base du problème n’est pas un souci d’OCCL, mais d’une erreur de CAS.

Pour une raison inconnue, le numéro de ligne de lecture du Track repart à zéro. Ce qui a pour conséquence de faire repartir la lecture du Track à partir du début avec des données qui sont plus récente et donc qui n’ont pas l’OCCL attendu. D’où l’erreur d’OCCL.

Le système fonctionne quant même en protégeant les données locale. Les fichiers locaux restent inchangés.

Cependant, l’erreur annoncée n’est pas correcte.

De plus, on ne sait pas pourquoi le numéro de suivi de la ligne de Track repart à zéro intempestivement.

Il y a peut-être un souci sur le disque de l’utilisateur.

Le problème résulte peut-être du nombre de compaction très fréquent le LogView _Meta qui n’à que très peu d’enregistrements.

—

On peut sans doute remplacer l’enregistrement “replication-agent:follower” de _Meta par un simple fichier mappé qui supportera nettement mieux les ré-écritures.

—

Implémenté sous la forme d’un VMemEngine sur la page “zero” du réplicateur. Nécessite beaucoup moins d’accès disque et est sécurisé par un journal.

Jusqu’à présent la ligne de lecture du Track était post-incrémentée.

Le numéro était donc incrémenté après consume. Cependant, le callback du gestionnaire d’évènement ne peut pas savoir si la dernière ligne est atteinte. S’il relance la resynchronisation, on peut entrer dans une boucle.

En pré-incrémentant la ligne de lecture, on est sûr de ne pas lire plusieurs fois la même ligne de Track lors du following de réplication.