Hello everyone,
I am facing a strange behaviour regarding Product Store Promotions that are active for one of the ecommerce sites that my company manage. In all the pages of the sites, we have included the ShowPromoText.groovy script that retrieves the promotions active for a specific store: we then use data gathered from the script to make some customizations (ftl-side) on how the promos are shown to the end user customers. The main method that the script uses to get all the promos for a store is *getStoreProductPromos *of the class* ProductPromoWorker.java.* Right now there are active on the site ten/fifteen different kind of promotions like order discount promotions, ship charge discount promotions, promocodes linked to a specific party and more; what I noticed is that the groovy script cannot always retrieve all the available promos for a store so I started check out a bit the method getStoreProductPromos: this method loops over all the ProductStorePromoAppl records, tests each promo and if the promo conditions are met then the record is added to a list of valid promos; if the conditions are not met then the promo is nulled. I found that if one of the first promo processed fails the rule conditions check, due to a boolean flag *condResult *that switches to* false* then, all the following promos in the (ProductStorePromoAppl) list are never checked and nulled, and at the end never shown to the end user customer. I would like to ask if this is actually an issue of the getStoreProductPromos method or if is not the case, what are the reasons behind that piece of logic. Thank you in advance for your help. Kind regards, Giulio -- Giulio Speri *Mp Styl**e Srl* via Antonio Meucci, 37 41019 Limidi di Soliera (MO) T 059/684916 M 334/3779851 www.mpstyle.it |
Giulio,
I hope its not too late, the logic you are referring is simply should be used when we want to show the applicable promotion only. But if you want to show/use all promotions then - trace the logic at - https://demo-trunk.ofbiz.apache.org/ecommerce/control/showAllPromotions I would say, system behavior is correct. But if you want some input on some business case which gives you problem then you should tell that business case instead of code logic. It will help at our end, to provide you solution. Thanks! Best Regards, -- Rishi Solanki *CTO, Mindpath Technology* cell: +91-98932-87847 LinkedIn <https://www.linkedin.com/in/rishi-solanki-62271b7/> On Tue, Feb 25, 2020 at 12:57 AM Giulio Speri - MpStyle Srl < [hidden email]> wrote: > Hello everyone, > > I am facing a strange behaviour regarding Product Store Promotions that are > active for one of the ecommerce sites that my company manage. > > In all the pages of the sites, we have included the ShowPromoText.groovy > script that retrieves the promotions active for a specific store: we then > use data gathered from the script to make some customizations (ftl-side) on > how the promos are shown to the end user customers. > The main method that the script uses to get all the promos for a store > is *getStoreProductPromos > *of the class* ProductPromoWorker.java.* > > Right now there are active on the site ten/fifteen different kind of > promotions like order discount promotions, ship charge discount promotions, > promocodes linked to a specific party and more; what I noticed is that the > groovy script cannot always retrieve all the available promos for a store > so I started check out a bit the method getStoreProductPromos: this method > loops over all the ProductStorePromoAppl records, tests each promo and if > the promo conditions are met then the record is added to a list of valid > promos; if the conditions are not met then the promo is nulled. > I found that if one of the first promo processed fails the rule conditions > check, due to a boolean flag *condResult *that switches to* false* then, > all the following promos in the (ProductStorePromoAppl) list are never > checked and nulled, and at the end never shown to the end user customer. > > > I would like to ask if this is actually an issue of the > getStoreProductPromos method or if is not the case, what are the reasons > behind that piece of logic. > > > Thank you in advance for your help. > > Kind regards, > Giulio > > > > -- > Giulio Speri > > > *Mp Styl**e Srl* > via Antonio Meucci, 37 > 41019 Limidi di Soliera (MO) > T 059/684916 > M 334/3779851 > > www.mpstyle.it > |
Free forum by Nabble | Edit this page |