Pim-community-dev: Modification en masse - Mis à jour à

Donc, cela pourrait avoir à voir avec le fait que le \Pim\Bundle\CatalogBundle\EventSubscriber\TimestampableSubscriber n'écoute que les événements Doctrines prePersist et preUpdate . Le \Pim\Bundle\CatalogBundle\Doctrine\MongoDBODM\Saver\ProductSaver::saveAll n'émet pas du tout ces événements.

Après examen, les dates sont créées dans \Pim\Bundle\TransformBundle\Normalizer\MongoDB\ProductNormalizer::normalize lors de l'exécution de saveAll . Encore un mystère pourquoi les EnhancedConnectors fromLastExecution ne prennent pas en compte ces produits. Y a-t-il une erreur de fuseau horaire quelque part?

Il semble que le normalizedData.updated MondoDB ne soit pas mis à jour ...

Salut Matias,

Que signifie "lors de l'ajout de valeurs aux attributs de produit"? Avez-vous essayé de modifier une valeur de produit commune? J'ai essayé de le reproduire sur une nouvelle installation mais le champ de produit updated_at a bien été mis à jour.
Dans vos informations système, il n'y a pas EnhancedConnectors , normal?

Que signifie "lors de l'ajout de valeurs aux attributs de produit"? Avez-vous essayé de modifier une valeur de produit commune? J'ai essayé de le reproduire sur une nouvelle installation mais le champ de produit updated_at a bien été mis à jour.

Oui, changez n'importe quel attribut afin que le produit soit marqué pour les changements, donc pour être persistant.

Dans vos informations système, il n'y a pas EnhancedConnectors, normal?

Hors du sujet

Lorsque vous effectuez des modifications en masse (quelles que soient les méthodes qui appelleront \Pim\Bundle\CatalogBundle\Doctrine\MongoDBODM\Saver\ProductSaver::saveAll ), les éléments suivants seront appelés \Pim\Bundle\TransformBundle\Normalizer\MongoDB\ProductNormalizer::normalize
Comme nous sommes dans la branche 1.4.x, voyez bien que la valeur _updated_ des produits est mise à jour ici
https://github.com/akeneo/pim-community-dev/blob/v1.4.25/src/Pim/Bundle/TransformBundle/Normalizer/MongoDB/ProductNormalizer.php#L87
Mais les requêtes via le gestionnaire mongo sont ciblées sur les produits normalizedData et qui ne sont pas mis à jour avec les nouveaux horodatages created et updated (https://github.com/akeneo /pim-community-dev/blob/v1.4.25/src/Pim/Bundle/TransformBundle/Normalizer/MongoDB/ProductNormalizer.php#L99).

Pour contourner ce problème, nous écoutons l'événement akeneo.storage.pre_save_all et mettons à jour les horodatages des produits.

Relié / dupliqué par # 5006
@ aRn0D ce n'est pas une question, c'est un bug; selon # 5006 fonctionne en mode ORM mais pas en ODM

En haut.
J'ai reproduit ce bogue dans notre instance PIM.

Le normalisateur met à jour le champ «racine» mis à jour à la volée mais ne le met pas à jour vers l'objet produit. Donc, comme l' a dit

• ici, le champ racine mis à jour est OK (https://github.com/akeneo/pim-community-dev/blob/v1.4.25/src/Pim/Bundle/TransformBundle/Normalizer/MongoDB/ProductNormalizer.php#L87);
• et sur le normalizedData, c'est la mémoire de l'objet produit qui est normalisée (https://github.com/akeneo/pim-community-dev/blob/v1.4.25/src/Pim/Bundle/TransformBundle/Normalizer/MongoDB/ProductNormalizer .php # L99)

Le champ Produit mis à jour et le fichier normalizedData.updated sont toujours désynchronisés. NormalizedData est un pas en retard.

Je pense que le normalisateur n'a jamais à faire $data['updated'] = $this->mongoFactory->createMongoDate(); si les données sont définies dans le modèle de produit. C'est un normalisateur, pas un programme de mise à jour.

Le fait est que le produit doit être mis à jour (champ donc mis à jour) avant la normalisation.

+1

Salut @mathewrapid , @jlestel , @bmarrot !

Pour info, ce problème (PIM-6038) a été corrigé dans les versions suivantes,

• 1.6.8: https://github.com/akeneo/pim-community-dev/blob/1.6/CHANGELOG-1.6.md
• 1.5.18: https://github.com/akeneo/pim-community-dev/blob/1.5/CHANGELOG-1.5.md

Meilleures salutations,

Imo. peut être fermé. Des avis?

Comme @nidup l'a souligné dans https://github.com/akeneo/pim-community-dev/issues/4620#issuecomment -279428030, cela a été corrigé dans PIM-6038.