Ajout datede peremption et n° de lot sur PS1.5

[nullos]

Bonjour,

Suite a des changements légisalatif, ma société doit adapter PS. Malheureusement la crise fait rage donc il ne nous est pas possible de débloquer un budget pour cette opération. J'ai donc décidé de m'y mettre un peu mais j'ai vraiment du mal.

 

J'ai donc ouvert PS (nous travaillons en 1.5.4 les mises a jours sont tjrs bien passé ouf lol)

 

L'idée est de greffer cela à la gestion avancée de stock qui gére déjà l'ajout de produit a la facon de lot (cf structure de la table ps_stock_mvt).

 

J'ai donc modifé la table (ca ce n'est pas compliqué) et j'ai ajouté end_date (pour la date de peremption) ainsi que num_lot (pour le numéro du lot).

 

ALTER TABLE `ps_stock_mvt` ADD `end_date` VARCHAR( 8 ) NOT NULL ,
ADD `num_lot` VARCHAR( 15 ) NOT NULL

 

Jusque la je ne pensse pas m'etre trompé mais bon ditent le moi si c'est la cas ;-)

 

Ensuit, j'essaie de modifier dans la section stock, page "Gestion du stock".

 

Je trouve donc cette page "controllers/admin/AdminStockManagementController.php"

 

Là, je fais la modification suivant :

(je ne vous mets que les bouts de codes que je modifie et leurs situations)

 

Situé à auteur de la ligne "262", du fichier "controllers/admin/AdminStockManagementController.php".

  array(
   'type' => 'text',
   'label' => $this->l('Unit price (tax excl.):'),
   'name' => 'price',
   'required' => true,
   'size' => 10,
   'maxlength' => 10,
   'desc' => $this->l('Unit purchase price or unit manufacturing cost for this product (tax excl.)'),
   'hint' => sprintf($this->l('Last unit price (tax excl.): %s'), $last_sm_unit_price_te),
  ),
////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////// Modification pour lot et end date ///////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////
  array(
   'type' => 'text',
   'label' => /*$this->l('Name:')*/'Date limite :',
   'name' => 'end_date',
   'size' => 15,
   'disabled' => false,
   'desc' => $this->l('Veuillez introduire la date limite de consommation. (jjmmaaaa)'),
  ),
  array(
   'type' => 'text',
   'label' => /*$this->l('Name:')*/'Numéro de lot :',
   'name' => 'num_lot',
   'size' => 15,
   'disabled' => false,
   'desc' => $this->l('Veuilez introduire un numéro de lot.'),
  ),
/////////////////////////////////////////////////////////////////////////////////////////////////////	 
  array(
   'type' => 'select',
   'label' => $this->l('Currency:'),
   'name' => 'id_currency',
   'required' => true,
   'options' => array(
    'query' => $currencies,
    'id' => 'id_currency',
    'name' => 'name'
   ),
   'desc' => $this->l('The currency associated to the product unit price.'),
  ),

 

Là, c'est cool j'ai bien l'affichage des 2 champs dans ma page "ajout un porduit" d'ajout au stock.

 

Bien j'essaye donc par la suite de modifier la page suivante qui est "supprimer un produit".

 

Je continue donc toujours dans le meme fichier :

 

Situé à auteur de la ligne "401", du fichier "controllers/admin/AdminStockManagementController.php".

  array(
   'type' => 'select',
   'label' => $this->l('Warehouse:'),
   'name' => 'id_warehouse',
   'required' => true,
   'options' => array(
    'query' => $warehouses_remove,
    'id' => 'id_warehouse',
    'name' => 'name'
   ),
   'desc' => $this->l('Select the warehouse you\'d like to remove the product from.')
  ),
////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////// Modification pour lot et end date ///////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////	 
  array(
   'type' => 'text',
   'label' => 'Numéro de lot :''Date limite :',
   'name' => 'end_date',
   'size' => 15,
   //'maxlength' => 6,
   'required' => true,
   //'desc' => $this->l('Physical quantity to remove'),
  ),
  array(
   'type' => 'text',
   'label' => 'Date limite :',
   'name' => 'num_lot',
   'size' => 15,
   //'maxlength' => 6,
   'required' => true,
   //'desc' => $this->l('Physical quantity to remove'),
  ),
////////////////////////////////////////////////////////////////////////////////////////////////////
  array(
   'type' => 'select',
   'label' => $this->l('Label:'),
   'name' => 'id_stock_mvt_reason',
   'required' => true,
   'options' => array(
    'query' => StockMvtReason::getStockMvtReasonsWithFilter($this->context->language->id,
				  array(Configuration::get('PS_STOCK_MVT_TRANSFER_FROM')),
				  -1),
    'id' => 'id_stock_mvt_reason',
    'name' => 'name'
   ),

 

C'est là que tout foire lol.

 

Ce n'est pourtant qu'un copié collé modifier qui vient d'un array un peu plus haut.

 

Voilà maintenant je suis donc bloqué. J'ai remis la modif en commentaire et ca refonctionne.

 

Est-ce qu'un bonne âme pourrait m'aider s'il vous plaît

 

Merci d'avance à tous.

[SMorillon.com]

Bonjour,

 

Je pense que votre problème est sur cette ligne :

 

'label' => 'Numéro de lot :''Date limite :',

 

Concernant la méthode, attention : en modifiant directement le fichier controllers/admin/AdminStockManagementController.php, vous allez perdre vos modification à la prochaine mise à jour !

 

Il faut passer par un override pour que les modifications ne soient pas impactées par les futurs mises à jour de Prestashop.

(/override/controllers/admin/...).

Edited July 18, 2013 by SMorillon.com (see edit history)

[Martin Uker K]

D'une manière ou d'une autre, en modifiant directement une table dans la BD de Prestashop il a modifié le coeur de la structure de données. Ses modifications seront possiblement incompatibles avec certains modules et risque de donner des problèmes avec les mises à jour.

 

Mais c'est sûr que l'override serait mieux qu'une modification directe.

 

Il aurait dû faire une table à part et un module pour l'affichage et l'administration par contre.

 

Martin

[Prestaspirit]

Bonjour,

 

Je pense que votre problème est sur cette ligne :

 

'label' => 'Numéro de lot :''Date limite :',

 

Concernant la méthode, attention : en modifiant directement le fichier controllers/admin/AdminStockManagementController.php, vous allez perdre vos modification à la prochaine mise à jour !

 

Il faut passer par un override pour que les modifications ne soient pas impactées par les futurs mises à jour de Prestashop.

(/override/controllers/admin/...).

 

Bonjour,

 

Comme le dit SMorillon.com pour ce type de modification il vaut mieux utiliser l'override dans lequel vous pouvez ajouter facilement des champs dans le méthode renderForm grâce à la propriété fields_form_override

 

c'est vraiment la bonne pratique à mettre en place.

 

Cordialement

Franck

[Prestaspirit]

D'une manière ou d'une autre, en modifiant directement une table dans la BD de Prestashop il a modifié le coeur de la structure de données. Ses modifications seront possiblement incompatibles avec certains modules et risque de donner des problèmes avec les mises à jour.

 

Mais c'est sûr que l'override serait mieux qu'une modification directe.

 

Il aurait dû faire une table à part et un module pour l'affichage et l'administration par contre.

 

Martin

 

Je suis pas tout à fais d'accord avec vous, l'ajout de ces champs peux aussi être géré par le fichier override et être compatible avec les autres modules sans que la modification soit écrasé lors d'une mise à jour, pour bien faire, comme vous l'indiquez, il faudrait créer un module qui permette d'installer et de désinstaller tout ça proprement.

[Martin Uker K]

Oui c'est vrai qu'il peut être géré par override, mais mon point était que le risque d'incompatibilité est plus grand que le module, les Hooks sont plus rarement supprimé que les fonction du coeur son modifié.

 

Mais les fichiers overrides peuvent être aussi glissés dans un module (Comme montré ici). La modularité permet de pouvoir séparé les responsabilités. En plaçant le tout dans un override (Qui pourrait contenir plus que seulement la gestion des lot et date de péremption, par exemple l'ajout de d'autre champs...) on rend le code plus complexe. Le module permet d'encapsuler la responsabilité dans un seul composant logiciel.

 

De plus, la base de données devant être modifié, la gestion de l'installation et de la désinstallation (Si elle est nécessaire) doit bien être quelques part. Dans le cas où on tenterait de migrer de 1.4 à 1.5 où les classes n'ont parfois plus les mêmes algorithmes, notre override pourrait bien être la cause de bien des problèmes et débugger ce code devient plus complexe que de juste désactiver les modules un à un pour voir quelle fonctionnalité cause le problème.

 

La gestion des fonctionnalités se fait mieux par module que par override multiple dans un même dossier.

 

Je ne suis pas en train de dire que l'override est à éviter et qu'il est le démon incarné...Loin de là, il est souvent plus simple et rapide de faire un override que de se perdre à créer un module (Dieu seul sait que j'ai eu une tonnes de problèmes avec certains...), surtout si notre expérience avec Prestashop est limitée.

 

Martin