Il s’agit d’un petite evolution de ces modules. Le module DOIT renvoyer le type de donnée qu’il traitent. C’est cette indication qui est utilisé dans les boucles associées au modules.

Pour corriger ce probleme, ajouter dans les function  » in_obj_xxx », dans la boucle de traitement des donnée , l’informations comme suit:
Avant

 while ($listing_version_products = $res->fetchAssoc()){

 $pd=product::get_item($listing_version_products['products_id']);

 $pd->aca=$aca_listing->return_db_min($listing_version_products['products_id']);

 $p[]=$pd;

 }

 return new objectInfo(array('title'=>__('table heading version products') , 'content'=>$p));

Apres

while ($listing_version_products = $res->fetchAssoc()){
 $pd=product::get_item($listing_version_products['products_id']);
 $pd->aca=$aca_listing->return_db_min($listing_version_products['products_id']);
 $pd->type='product';
 $p[]=$pd;
 }

return new objectInfo(array('title'=>__('table heading version products') , 'content'=>$p ,'type'=>'product'));

$current=$page->new_class(’customer’);

- Utilisation du moteur interne
La génération du pdf à lieu exclusivement par le back-office.
- Utilisation d’un moteur externe
Pas de génération de pdf disponible dans le back-office.

- Conclusion

Aussi, pour que le client dans sont espace (cf module account/history) le pdf soit disponible, il doit être présent.

La lecture ou téléchargement de ce fichier est assuré par l’appel à la page documents.php

L’exemple concerne la gestion des commandes, et les statut, en attente, en preparation, livré et annulé.

La nouvelle nomenclature sera ainsi
- en attente id 1
- payé id 2
- en preparation id 3
- expedié id 4
- livré id 5
- cloturé id 6
- annulé id -1

D’autre part, il est maintenant possible, et recommandé, que les module qui ajoute des statut, soit des statut enfant de ceux cité au dessus

C’est a dire, que un statut « payé par CB « , sera un statut avec l’id 21.
Il appartiendra a la section des statut payé, et precisera par cb.

Pour attribbuer un statut à sont pére, il faut respecter l’ecriture ci dessous:
pere + num
21 Pour pere payé
12 Pour pere en attente

L’etat des commande et du comportement de la boutique, sera donc basé sur le pere du statut courant.
Toutefois cette nuance permet au module de genere leur propre statut, et ainsi de suivre en interne du module la progression.

Enfin les liste de commande ne contiendront que les statut > 0. C’est a dire que les listing ne publierons pas les commande annulé, ou avec un statut negatif

Ce tag ne demande aucun arguement, il ne fait qu’initier la mise en oeuvre de la lecture du dossier /sql de la contrib courante.

L’arborescence du dossier sql, respecte les même contrainte que les fichiers d’installations.

• /sql
  • /mysql
    • install
      • tables
        • xxxx.sql
        • xxxx.key.sql
      • data
        • xxx.sql
    • remove
      • tables
      • data
  • postgresql/

Les fichiers sql, key.sql respecte le format courant des fichier sql.  les commentaires sont composé de « – ».

Chaque commande doit ce terminer par un « ; »

Un petit point sur l’extension ecommere pour dolibarr, basé sur la version de tiaris. Afin de réponse a mes besoin, j’ai re-developpé ma propre version. Enf effet, la version original n’ayant absolument pas les capacité dont j’avais besoin .

Petit recap des fonctionnalités nécessaires :

• import des archives (6 ans +/- 15 000 Clients pour un site)
• gestion lors de l’import de la clôture des commande, de la génération de BL , de la clôture (si payé) des factures
• gestion des import produit et catégories
• utilisation des attribut de produits venant de ecommerce , et non implémenté dans dolibarr (creation d’un produit par couple produit + attribut), avec un référence unique
• création de numéro de commande, facture , client personnalisé, indiquant à la fois les ref de dolibarr, celle du site ecommerce , et l’id du site ecommerce (plusieurs site couplé avec 1 seul dolibarr)
• traitement automatisé des imports , et recherche d’existant (un même client inscrit sur 2 sites ecommerce, un produit en vente sur 2 sites.. ), et si l’automatisation échoue, ajout d’une action manuelle permettant de terminer l’import apres un choix manuel
• Gestion de correspondance de statuts ecommerce vs dolibarr et les variante de document. (commande + bon de livraison + facture + paiement )
• UTilisation d’un module de module pour le tratiement specifique par type de moteur ecommrece, liée à dolibarr
• Suivi du stock

Afin de faire tous ca, il à quand même fallu ce retorusser les manches, et attaquer fort. Le mdoule utlise des table ecom_ temporaire pour assurer la liaison entre le site ecom et dolibarr. Il à dabord fallut restructurer un peu les tables, et ajouter des contrainte unique afin de garantir coherance de l’ensemble.

Base de données

Pour toutes les tables de liaison entre ecom est dolibarr, j’ai ajouté quelques colonne, afin de traiter la gestion des echange entre l’ecom et dolibarr apres import. Ces collone assure aussi un etat de l’import.

Les colonnes event_xxx

Les 3 colonnes supplementaire ajouté

event_type int(2) NOT null comment ‘0: init / 1 import ,11 import ok, 12 import attente, 13 import apres association manuelle , 14 import not Ok / 2 export, 21 export ok, 22 export attente / 3 no touch ‘,
event_update datetime NOT null,
event_check int(1) NOT null default ‘0′ comment ‘ -9 error , -1 error reload / 0 default / 1 ok / 2 check and no touch ok/ 3 Abandon  ‘,

Pour toutes les table, j’ai ajouté des clek unique sur les coupe doli_id, ecom_id, site_id afin de garantir l’unicité des données, et bloqué les doublon eventuel en plus des control php.

Colonne event_type:

Cette colonne prend comme valeur uun entier, et precise le type d’evenement concerné

Colonne event_update:

Elle prend comme valeur la date et heur lors de l’enregsitrement. C’est cette colonne qui determinera le sens du flux entre dolibarr et l’ecommerce lors du prochain control. Si la date de mise a jour est plus recente que celle de l’ecommerce, dolibarr poussera les donnée vers le moteur d’ecommerece. Si par contre c’est celle de l’ecommerce qui est plus recente, dolibarr assura une mise a jour de sa version locale.

Colonne event_check:

Cette colonne qui prend comme valeur un entiers, precise dans quel etat c’est terminé le processus precendent, et permet de desactiver certaine ligne (comptabilisé et ne seront plus jamais modifié, facture classé).  En outre cette colonne determine si le processus entre dolibarr et ecommerce et montant ou descandant, elle est couplé àla colonne precedent.

Ex:

• dernier mouvement de type import, et date ecom update identique ou plus ancienne que date sur table local >> aucune action
• dernier mouvement type import et date ecom update plus recente , nouvel import (synhro)
• dernier mouvement type export et date ecom update plus recente ,  nouvel import (synhro)
• dernier mouvement type export et date ecom update identique ou plus ancienne que date sur table local >> aucune action

Les modules enfants de l’extension ecommerce

Le module enfants, prend en charge, l’affichage des champs d’import / export lors de la configuration, et le traitement des donnée lors de l’import ou l’export, afin d’assurer la transition.

Il doit être defini lors de l’ajout d’un site ecommerce dans dolibarr, et ne peut être modifié par la suite. Pour chaque changement de moteur d’ecommerce couplé a dolibarr, il peut être necessaire d’ajouter et ajusté ce module ;

Fonctionnement

Ordre des imports , logique fonctionnelle

La gestion des import, et l’inter-dependance entre les données importés, impose une logique dans l’ordre des imports, Afin de préserver la coherance.

ex : les produit appartiennent à une categorie, les commande depende d’un client.

Aussi la logique d’import fonctionne comme suit:

1. Parametres (1 fois, à la config)
2. Clients et carnet d’adresse
3. Categories
4. Produits
5. Commandes

Notez que la gestion via cron, impose cette logique. Mais lors d’un import contenant de gros volume d’archive (la boutique fonctionne depuis un certain temps déjà), il est important de n’initier les import de commande qu’une fois les synchro des autres données effectués

Specificités des categories

Les categories sont intement liées au produits. Toutefois, dolibarr intégrant ces propres categories, de même que chaque site connecté.

Aussi , pour chaque site, il est possible (et necessaire) de creer une categorie, et d’y associcé l’ensemble des categories creer pour le site courant.

Usage : Il est ensuite possible de creer la base du produits dans un second site, on lui precisant que celui ci appartient à une categorie d’un second site.

Les actions Différées (mécanisme de rattrapage)

Ces mécanismes de rattrapage assure la cohrerance du syteme est de sa gestion des données. En  effet, il peut être logique de synchroniser les stock pour un produit, sans pour autant modifié une adresse client plutot quand creer une nouvelle.

Lorsque le choix n’est pas possible de manière automatiser, une question reste en supsend afin que l’utilisateur l’ajuste manuellement (A terme, cet usage devrait permettre de choisir pour chaque type de data, le mode d’ajustement automatqiue possible , oui pour les stock et non pour la description).

Les action différées, sont les import ou export n’ayant pu être traiter automatqiuement. Elle necessite l’intervention humaine, et reste donc en attente. Elle peuvent concerner tous les type de données importées et sont souvent issue de l’incapacité de choisir , lorsque par exe, 2 contacts sotn presque identiques, mais avec quelques variances, ou lors de la detection de client en doublon.

Les class php , fonctionnement et usage

Cette extension contient plusieures class organisées comme suit:

• les class Ecom_xxx , sont les class gerant la manipulation des données des table specifique à cet extension, et assurant la liaison entre le site ecommerce et dolibarr
• Les class E_xxx , sont les class public, utilisé dans les pages, et assurant les process de manipulations de donnée, et qui ce charges des appels sur les class dolibarr, et sur les class d’exension
• Les class ECS_xxx, sont des alias des class E_xxx, mais avec un singeltown, assurant une instanciation unique

Les class Ecom_xxx

A chacunes de ces class correspond une table dans la base de donnée nomme llx_ecom_xxx. Elle manipulent les données temporaire, et herite d’une class mêre, Ecom_Master. Ces class sont normalisé, et contiennent les methodes suivante:

• create
• fetch
• update
• UpdateCheck
• delete

Les class E_xxx et ECS_xxx

Ces classes assurent la manipulation centralisé des données, les import et modification. Elle prennent en compte le site courant, et charge le module enfant pour ce type de site.

Les methodes public, l’ensmeble des class est orienté vers un type de donnée (client, carnet d’adresse, commande), mais peuvent être amené à manipuler les données d’autre type.

• ActionDiffLoad
• WsFetch
• ecom2dolibarr convertion du retour de webservice en un object dolibarr
• ImportAll import des nouveautées, et control recursif des donnée precendente
• ImportOne import d’une ligne de donnée specifique
• AdjustOne control et ou mise a niveau de donnée
• CheckExactly control pour chercher une modification dans les synchro
• findInSite (Obsolete)

Class ECS_xxx

Seul 2 class appartiennent à cette categorie, les class ECS_site, et ECS_log.

Ces class sotn appelé dans toutes les autre class de type E_xxx. Elle sont Obligatoire. Elle utilise le mecanisme de singeltown, aussi , pour obtenir l’occurence courante, il s’uffit d’utiliser la forme:

ECS_site::getInstance();

Class ECS_site

Cette class Assure le chargement de la configuration du site courant, Elle charge le connecteur du site, ainsi que sa configuration. Elle Assure aussi la liaison, pour les appel de methode  apparteant au connecteur, dans les synchronisation des clefs des données entre dolibarr et ecommerce.

Vous avez installé et mis en place l’extension ecommerce pour dolibarr. Vous allez donc mainetanant gerer votre boutique en partie avec dolibarr. Cet article à pour but d’expliquer et definir les régles de foncitonnement et pocédure, dans l’exploitation de cette solution.

Les Tiers Société et Contact

Les produits

La gestion des produits, couplé avec un ecommerce, vous permet de gérer dans dolibarr, à la fois les produits en ligne, et les porduit specifique créer dans dolibarr et qui ne sont pas en ligne. Le mecanisme d’import via crond, vous assure une synchronisation perpetuelle avec le(s) moeteur(s) ecommerce. Aussi tous nouveaux produit ajouté sur l’ecommerce sera importer dans dolibarr. Il en est de même pour les modification du produit, les mise à jour seront importées (depend de la configuration, et des données à mettre à jours)

Import/ Re-import

Les données de prix, taxe, poids, code barre, stock, description sont inseré dans dolibarr.

Dans le cas d’un produit deja present (plusieurs ecomm)

Update Ecommerce

Update Dolibarr

Un onglet specifique ecommerce et ajouté dans la fiche produit.

Les commandes, factures, expeditions

osCSS 2.1.0 avait pour but la mise en oeuvre avec une refonte fondamentale du code, et la conservation d’un reto-compatibilité avec les version anterieur.

La version 2.1.1 apportera une reorganisation partielle des fichier afin de clarifier leur fonctionements, et mieux structurer l’api public comme privé.

Dans cette idée , le core public va donc voire les modification suivantes (il s’agit d’une liste de travail amené à être modifié ).

• le dossier classes/driver va ainsi voir apparaitre un dossier data.

Ce dossier rassemble les class (anciennement driver.xxx.php) qui manipule des types de donnée (produit, categorie, article…). Ces type etant geré de maniere dynamique, il sera donc possible d’ajouter de nouveau type de données.

• Apparition d’une factory pour traiter les type de donnée, sans pour autant creer une class driver specialisé
• le dossier classes/ va ainsi voir apparaitre un dossier core_page (class extends class page.php)

Il accepte tous les fichiers (anciennement page.xxx.php), les fichiers y sont regroupés et reonnmés sans le ‘page.’

• suivit de  core_page/overlay.

Ce dossier conteint les class de surcouche , element du constructeur principale. Ils prennent en charges lors du charement du template de page de l’appel des plugins, des boxes et des modules (generic)

• Les vues sql vont disparaitre, et n’être proposé que lors de l’install pour simplifier une retro compatibilité, en offrant en vue les table modifiés.
• Une petite optimisation de quelques tables va avoir lieux (produit/client), et quelques colonnes ajouté

Depuis quelques temps déjà, je me frottais avec les factorys, dont je n’avais pas travaillé l’usage; Ben c’est choses faites :!

La structure typé des contenu etant parfaitement adaptés à cet usage, une class factory vient normalisé les appels d’extension de type aca .

Généralités

Je m’explique, prenons comme exemple, une boutique qui nécessite la mise en oeuvre d’un contenu de type fournisseur. Dans l’absolu, on pourrait juste duplisquer une page comme les fabricants (admin).  Toutefois, il faut intégres des a present, que le besoin de ce contenu devra s’adapter a travers le temps, afin d’affiner et/ou developper les informations qui y sont contenu.

Donc pour une facilité de maintenance, on creer un contenu de type fournisseurs, puis on y greffe les elements modulaire dans un repertorie fournisseur.

Il serotn charge, comme pour les autres contenu. Nous pourrons donc ajuster les interface de control , et ou modifier les elements stocké, voir faire evoluer les foonctionnalité.

Dans cette demarche , la class AcaFactory est prevu pour ca.

Dans un premier temps, on ajoute uen variable de configuration portant le nom de la constante avec le type de contenu inseré dans celui ci.

ex:

• Pour le front office MODULE_FOURNISSEUR_INSTALLED
• Pour le backoffice MODULE_FOURNISSEUR_INSTALLED_BO

Puis , on creer un repertoire fournisseur, dans lesquel nous y stockerons les modules specifiques de ce contenu.

Note:  il n’est pas encore possible d’administrer les status  dans le backoffice, il faut donc definir manuellement le contenu de la constante des module actif.

Récaptitulatif

Backoffice

Pour activer les modules associé à un nouveau contenu , un repertoire du nom du nouveau type doit être present dans modules,

par ex :

modules/fournisseurs/

Les modules aca destinée a cette donnée seront alors utilisé

Une varibale de configuration , stocké dans la base configuration doit être nommé comme suit:

MODULE_FOURNISSEUR_INSTALLED_BO, ou fournisseur represnete le nom de la ressource

Un module de page doit chapeauter l’enssemble pour assurer les enregsitrement et gestion de base de cette ressource. Celui ci sera en general nommé fournisseur (dans notre exemple); il prendra en charge l’ensregsitrement de base de cette ressource,

• table fournisseurs
• table frounissseurs_info (table complementaire à l’horizontale)
• table fournisseurs_description (table suppl pour la gestion mutli langue)
• table fournisseurs_extra (table supll pour l’utlisation des champs extra de cette ressource)

Frontoffice

Dans l’usage d’une ressource qui doit aussi être implementé dans le frontoffice en tant que ressource , et non pas complement d’une ressource existante:! je m’explique; si il s’agit d’un fournisseurs, et que vous souhiaitier rendre public la lisaison entre les deux, sans pour autant mettre en oeuvre une recherche, page (comme les produits), mais juste une information complementaire au produit; Dans ce cas, preferé un module de type product, qui ne sera donc chargé que dans le chargement des element associé à un produit.

Dans le cas de la creation d’une nouvelle ressource, qui nécessite la mise en place, la gestion specifique de ce produits, et dans ce cas seulement, suivez les insctructions suivantes:

Utilisations

L’utilisation des factory, vous permet d’ajouter des ressources specifiques, et donc dans d’ajuster le fonctionement du moteur à vos ressource. L’interet de ces modules et l’utilisarion des ressource elle même de manières modulaire. Vous ajouter donc un type de ressource, qui lui même contiendra des modules externe pour sont usage, exploitation et affichage.

Backoffice

L’appel dans une class de de ressource s’utilise dans le module de gestion de la ressource elle même. Cette class, qui compose le module de type page, prend en charge la gestion de la ressource elle même.

Ce module de page prend donc en charge le listing complet, et la recherche de la ressource, ainsi que les action d’edition, de suppression de modification. Il assure de plus le chargement des sous modules composant cette ressource (repertoire du nom de la ressource dans dossier module).

Ex d’arborescence (pour ressource fournisseurs)

• modules
  • pages
    • fournisseurs.php
  • fournisseurs
    • header_tags.php
    • etc ..;

Note: l’ensemble des factory, public et privé support l’appel au methodes magic, vous pouvez donc codé librement, dans le respect des interfaces de base

• http://cx.cx/2011/02/22/fail2ban-installation-et-configuration/
• http://gardouilleland.free.fr/wordpress/?cat=17
• http://forum.inforeseau.com/post118.html

donc , je trouvais l’approche de l’analyse du fichier de log de fail2ban (gardouilleland) etre une bonne approche;

Je me suis donc mis en tete de rajouter un filtre puis une action

En suivant le tuto de gardouilleland, je n’arrivais pas a faire fonctionner la mise en prison des ip qui insiste malgres des ban repeté (les boths ne ce lassent pas vite)

J’ai donc testé le filtre mise en place

fail2ban-regex /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

et la constaté qu’il manquait le <host> en fin de regex, comme precié dans le wiki

http://www.fail2ban.org/wiki/index.php/MANUAL_0_8

avec sont encadrement , soit:
(?P<host> ... )

Ajout régle et jail pour bloquer les tentatives incessantes

fichier filter fail2ban.conf

Et la, c’est ok apres test de la regex, plus de soucis, celle ci est bien trouvé; Ce qui donne donc , l’ajout d’un fichier etc/fail2ban/filter.d/fail2ban.conf composé comme suit:

# Fail1Ban: fichier de configuration
#
# Author: Tom Hendrikx
# Traduction: Gardouille
#
# Version: 1.0
#
[Definition]
# Option: failregex
# Notes.: regex qui correspond aux messages d'erreur relatifs
# à un mauvais mot de passe dans le fichier de log.
# L'hote doit correspondre à un groupe nommé "host".
# Le tag "<HOST>" peut être utilisé pour faire correspondre
# les IP/hostname et c'est seulement un alias pour
# (?:::f{4,6}:)?(?P<host>\S+)
# Valeur: Texte
#
# Compter toutes les ip bannies dans le fichier de log
failregex = fail2ban.actions: WARNING \[(.*)\] Ban (?P<host>\S+)

# Option: ignoreregex
# Notes.: regex à ignorer. Si cette regex correspond, la ligne est ignorée.
# Valeur: Texte
#
# Ignorer nos propres bannissements, pour garder nos comptes exacts.
# Dans le fichier de config, nommer la prison 'fail2ban', ou alors changer cette ligne!
ignoreregex = fail2ban.actions: WARNING \[fail2ban\] Ban

jail

Et la régle jail correpsondante, dans le fichier etc/fail2ban/jail.conf

[fail2ban]
enabled = true
filter = fail2ban
action = iptables-allports[name=fail2ban]
sendmail-whois[dest="aurelien@oscim.com",name="fail2ban",sender="fail2ban@sd-27429.dedibox.fr"]
# Fichier de log analysé :
logpath = /var/log/fail2ban.log
# Analyse les logs sur 1 semaine
findtime = 604800
# bantime: 1 semaine
bantime = 604800
maxretry = 2

Ajout régle est jail en complement de suhosin

On construit le fichier de configuration

# Fail1Ban: fichier de configuration
#
# Author: oscim
#
# Version: 1.0
#
[Definition]
# Option: failregex
# Notes.: regex qui correspond aux messages d'erreur relatifs
# à un mauvais mot de passe dans le fichier de log.
# L'hote doit correspondre à un groupe nommé "host".
# Le tag "<HOST>" peut être utilisé pour faire correspondre
# les IP/hostname et c'est seulement un alias pour
# (?:::f{4,6}:)?(?P<host>\S+)
# Valeur: Texte
#
# Compter toutes les attack bloqué par suhosin et declaré dans le log (/var/log/user.log) et on les bannies
failregex =   suhosin\[\d*\].*\(attacker\s'<HOST>'.*

# Option: ignoreregex
# Notes.: regex à ignorer. Si cette regex correspond, la ligne est ignorée.
# Valeur: Texte
#
# Ignorer nos propres bannissements, pour garder nos comptes exacts.
# Dans le fichier de config, nommer la prison 'fail2ban', ou alors changer cette ligne!
ignoreregex = fail2ban.actions: WARNING \[suhosin\] Ban

On teste ensuite la regex avec

fail2ban-regex /var/log/user.log /etc/fail2ban/filter.d/suhosin.conf

jail

Et la régle jail correpsondante, dans le fichier etc/fail2ban/jail.conf

[suhosin]
enabled = true
port    = http,https
filter  = suhosin
logpath = /var/log/syslog/*error.log
maxretry = 1

suhosin