This repository has been archived by the owner on May 9, 2020. It is now read-only.
add JCR_ARTICLE and JCR_FILE dataresourcetype and related demo under #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334473 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334483 13f79535-47bb-0310-9956-ffa450edef68
Removes a bunch of useless exceptions catches. There are still few cases to discuss, I believe there are useless (or at least without much more information) as well. we will decide on dev ML later... git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334497 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334501 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334502 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334536 13f79535-47bb-0310-9956-ffa450edef68
…l to UtilValidate.isEmpty(Object). git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334575 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334576 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334577 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334578 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334579 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334840 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334915 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334923 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334927 13f79535-47bb-0310-9956-ffa450edef68
…lidate-method>, and <check-id> elements. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334971 13f79535-47bb-0310-9956-ffa450edef68
…pts in the "from" attribute. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334996 13f79535-47bb-0310-9956-ffa450edef68
…ackage that didn't belong there. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1334997 13f79535-47bb-0310-9956-ffa450edef68
…ge. The classes might have been intended for call/return operations originally, but now they are used in a generic way - so I moved them to the org.ofbiz.minilang.method.envops package. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335018 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335020 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335025 13f79535-47bb-0310-9956-ffa450edef68
…rst pass (the next one will probably be to save the image in the session rather than in the file system); the main problems fixed are related to concurrent access: the class was not thread safe and this, especially in servers with high traffic, could cause a series of issues like: * captcha images created and then lost * captcha images created in the wrong location (for example out of the OFBiz folder) * the folder runtime/tempfiles/captcha could be locked git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335047 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335064 13f79535-47bb-0310-9956-ffa450edef68
used the oldFunnyHex encoding, not the fixed correct hex encoding. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335267 13f79535-47bb-0310-9956-ffa450edef68
support for this, run: java org.ofbiz.base.crypto.Main -kek and paste that value as a new attribute in entityengine.xml, <delegator key-encrypting-key="$kekText"/>. Make certain to add that attribute to *all* delegators that share the same datasources. ps: That java command should really be added to build.xml. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335268 13f79535-47bb-0310-9956-ffa450edef68
…t Displayed" https://issues.apache.org/jira/browse/OFBIZ-4859 Promotion list not displayed in trunk. To duplicate: Open Catalog Manager Select Stores > Store Id 9000 > Promos Expected: List of Promotions in the "Edit Product Store Promos" section. Actual: No records in list. Note: There is no component "Catalog" in the issue field Component/s drop above. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335343 13f79535-47bb-0310-9956-ffa450edef68
…ues.apache.org/jira/browse/OFBIZ-4834 After submitting an order using quick checkout, when you want to add products from main page (using Continue shopping or not), at the 1st product you add you get directly to quick checkout and would have to get back to the main page to add another product This was happening because we had used save-current-view="true" for "quickCheckout" request and in the addItem request we are using view-last that's why it was redirecting to quickCheckout after adding item. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335347 13f79535-47bb-0310-9956-ffa450edef68
…/issues.apache.org/jira/browse/OFBIZ-4566 On the edit contact mech page (https://localhost:8443/ecommerce/control/editcontactmech?contactMechId=10001) coming from profile page, there was one js error (in console) git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335351 13f79535-47bb-0310-9956-ffa450edef68
On production systems you can't suppress Debug.log( message by the use of debug.properties file. It is always good to use Debug.* statements that are having log level setup in debug.properties file. The real problem comes with Debug.log( statement when you are printing any list or map object that contains so many records(or data) in it. Here I am changing all the occurrence of Debug.log( with Debug.logInfo(, Debug.logError( or Debug.logWarning( so that we can have better control of Debug.* statements on production system. :-) Bad use of Debug statement. On production system you will get false alarm that you are having error in code base although the resultant statement is only giving additional information instead of error message. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335927 13f79535-47bb-0310-9956-ffa450edef68
…en thruDate < nowTimestamp" https://issues.apache.org/jira/browse/OFBIZ-4858 The button to end the assignment of a resource on a project should only be shown when the thruDate is not set or when the thruDate > nowTimestamp. But the button is also shown when the thruDate < nowTimestamp. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1335946 13f79535-47bb-0310-9956-ffa450edef68
Conflicts: .classpath
Conflicts: hot-deploy/SvdbCache/build.xml
site structure and menus from SiteviewWebsiteData.xml
asfgit
pushed a commit
that referenced
this pull request
May 10, 2013
…y/auth objects in the user session rather than the request; 1) removed the request-maps for changeDelegator from components' controller.xml files: they were not used 2) removed CoreEvents.changeDelegator(...): not used (apart from the request-maps removed at #1) 3) removed CoreEvents.changeDispatcher(...): not used 4) cleaned up some code (related to multitenant development): now the objects are set in the request rather than the session PS: as a consequence this will also fix the issue reported in OFBIZ-4289 git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1353681 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Dec 30, 2013
…rcome some limitations that prevented it to select and apply the best set of promotions under special conditions. Example: Consider two promotions: * consider two products: Product A, with price $20, and Product B, with price $40 * Promotion 1: 20% discount on all the products in a category containing Product A and Product B * Promotion 2: 40% discount on Product A When Product A and Product B are both in the cart: * Expected behavior: on Product A the Promotion 2 should be applied i.e. 40% discount, and on Product B Promotion 1 should be applied i.e. 20% discount. ** Summary Product Price Discount Subtotal A $20 $8 (40% discount) $12 B $40 $8 (20% discount) $32 Total Adjustment: $16 * OFBiz behavior (before this fix): Promotion 1 is applied to Product A and Product B; this happens because the total discount of Promotion 1 is greater than the total discount of Promotion 2 and OFBiz applies promotions sorted by discount (desc) ** Summary Product Price Discount Subtotal A $20 $4 (20% discount) $16 B $40 $8 (20% discount) $32 Total Adjustment: $12 The new solution fixes this issue and similar ones. Here are some details about the new algorithm. Overview of the flow: 1) run the promotions one by one in a test run 2) collect the ProductPromoUse information 3) sort them by weight (i.e. the ratio between the discount and the value of the products discounted) 4) execute the ProductPromoUse in the given order In order to understand this solution, and specifically the changes to ProductPromoWorker.java, there is an important concept to consider: one Promotion can generate more than one ProductPromoUseInfo objects. For example if I have 2 units of WG-1111 in the cart (in one cart item) and I have the promotion “20% discount on WG-1111 and GZ-1000” then the system will create TWO ProductPromoUseInfo objects both associated to the same promotion one for each of the 2 units discounted. Similarly if I had two lines: 2 units of WG-1111 and 1 unit of GZ-1000 I would get 3 ProductPromoUseInfo objects 2 objects for WG-1111 and 1 object for GZ-1000 We can sort these ProductPromoUseInfo objects based on their weight (i.e. the ratio between the discount and the value of the products discounted) in desc order and now we have a sorted list of ProductPromoUseInfo objects ready to be executed However we only want to execute each of them once and for this reason we set (in memory, not in the DB) the useLimitPerOrder to 1 in the first ProductPromoUseInfo of a given promotion and then to 2 if the same ProductPromoUseInfo is associated to the same promotion etc... in this way the end result is that the system will generate, as we desire, ONE ProductPromoUseInfo only for each of the ProductPromoUseInfo in the list. Here is an example: we have 2 promotions: PROMO A PROMO B After test run: ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 ProductPromoUseInfo - PROMO B - #1 - weight 0.4 After sorting: ProductPromoUseInfo - PROMO B - #1 - weight 0.4 ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 Based on this we create a list (sortedExplodedProductPromoList) of ProductPromo: PROMO B - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=2 When we apply these to the cart we get the following results: PROMO B - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=2 NOT APPLIED (because PROMO B used the item) git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554265 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Dec 31, 2013
=== This is a refactoring of the product promotion engine in order to overcome some limitations that prevented it to select and apply the best set of promotions under special conditions. Example: Consider two promotions: * consider two products: Product A, with price $20, and Product B, with price $40 * Promotion 1: 20% discount on all the products in a category containing Product A and Product B * Promotion 2: 40% discount on Product A When Product A and Product B are both in the cart: * Expected behavior: on Product A the Promotion 2 should be applied i.e. 40% discount, and on Product B Promotion 1 should be applied i.e. 20% discount. ** Summary Product Price Discount Subtotal A $20 $8 (40% discount) $12 B $40 $8 (20% discount) $32 Total Adjustment: $16 * OFBiz behavior (before this fix): Promotion 1 is applied to Product A and Product B; this happens because the total discount of Promotion 1 is greater than the total discount of Promotion 2 and OFBiz applies promotions sorted by discount (desc) ** Summary Product Price Discount Subtotal A $20 $4 (20% discount) $16 B $40 $8 (20% discount) $32 Total Adjustment: $12 The new solution fixes this issue and similar ones. Here are some details about the new algorithm. Overview of the flow: 1) run the promotions one by one in a test run 2) collect the ProductPromoUse information 3) sort them by weight (i.e. the ratio between the discount and the value of the products discounted) 4) execute the ProductPromoUse in the given order In order to understand this solution, and specifically the changes to ProductPromoWorker.java, there is an important concept to consider: one Promotion can generate more than one ProductPromoUseInfo objects. For example if I have 2 units of WG-1111 in the cart (in one cart item) and I have the promotion “20% discount on WG-1111 and GZ-1000” then the system will create TWO ProductPromoUseInfo objects both associated to the same promotion one for each of the 2 units discounted. Similarly if I had two lines: 2 units of WG-1111 and 1 unit of GZ-1000 I would get 3 ProductPromoUseInfo objects 2 objects for WG-1111 and 1 object for GZ-1000 We can sort these ProductPromoUseInfo objects based on their weight (i.e. the ratio between the discount and the value of the products discounted) in desc order and now we have a sorted list of ProductPromoUseInfo objects ready to be executed However we only want to execute each of them once and for this reason we set (in memory, not in the DB) the useLimitPerOrder to 1 in the first ProductPromoUseInfo of a given promotion and then to 2 if the same ProductPromoUseInfo is associated to the same promotion etc... in this way the end result is that the system will generate, as we desire, ONE ProductPromoUseInfo only for each of the ProductPromoUseInfo in the list. Here is an example: we have 2 promotions: PROMO A PROMO B After test run: ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 ProductPromoUseInfo - PROMO B - #1 - weight 0.4 After sorting: ProductPromoUseInfo - PROMO B - #1 - weight 0.4 ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 Based on this we create a list (sortedExplodedProductPromoList) of ProductPromo: PROMO B - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=2 When we apply these to the cart we get the following results: PROMO B - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=2 NOT APPLIED (because PROMO B used the item) git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release13.07@1554381 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Sep 19, 2015
…typo and missing screen.Added a decorator screen for using with accounting report. git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1704014 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Sep 19, 2015
------------------------------------------------------------------------ r1704014 | arunpatidar | 2015-09-19 15:09:40 +0200 (sam. 19 sept. 2015) | 1 ligne [OFBIZ-6212] Fixed the issue #1 of Accounting reports due to a minor typo and missing screen.Added a decorator screen for using with accounting report. ------------------------------------------------------------------------ � git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release14.12@1704070 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Mar 5, 2017
=== This is a refactoring of the product promotion engine in order to overcome some limitations that prevented it to select and apply the best set of promotions under special conditions. Example: Consider two promotions: * consider two products: Product A, with price $20, and Product B, with price $40 * Promotion 1: 20% discount on all the products in a category containing Product A and Product B * Promotion 2: 40% discount on Product A When Product A and Product B are both in the cart: * Expected behavior: on Product A the Promotion 2 should be applied i.e. 40% discount, and on Product B Promotion 1 should be applied i.e. 20% discount. ** Summary Product Price Discount Subtotal A $20 $8 (40% discount) $12 B $40 $8 (20% discount) $32 Total Adjustment: $16 * OFBiz behavior (before this fix): Promotion 1 is applied to Product A and Product B; this happens because the total discount of Promotion 1 is greater than the total discount of Promotion 2 and OFBiz applies promotions sorted by discount (desc) ** Summary Product Price Discount Subtotal A $20 $4 (20% discount) $16 B $40 $8 (20% discount) $32 Total Adjustment: $12 The new solution fixes this issue and similar ones. Here are some details about the new algorithm. Overview of the flow: 1) run the promotions one by one in a test run 2) collect the ProductPromoUse information 3) sort them by weight (i.e. the ratio between the discount and the value of the products discounted) 4) execute the ProductPromoUse in the given order In order to understand this solution, and specifically the changes to ProductPromoWorker.java, there is an important concept to consider: one Promotion can generate more than one ProductPromoUseInfo objects. For example if I have 2 units of WG-1111 in the cart (in one cart item) and I have the promotion “20% discount on WG-1111 and GZ-1000” then the system will create TWO ProductPromoUseInfo objects both associated to the same promotion one for each of the 2 units discounted. Similarly if I had two lines: 2 units of WG-1111 and 1 unit of GZ-1000 I would get 3 ProductPromoUseInfo objects 2 objects for WG-1111 and 1 object for GZ-1000 We can sort these ProductPromoUseInfo objects based on their weight (i.e. the ratio between the discount and the value of the products discounted) in desc order and now we have a sorted list of ProductPromoUseInfo objects ready to be executed However we only want to execute each of them once and for this reason we set (in memory, not in the DB) the useLimitPerOrder to 1 in the first ProductPromoUseInfo of a given promotion and then to 2 if the same ProductPromoUseInfo is associated to the same promotion etc... in this way the end result is that the system will generate, as we desire, ONE ProductPromoUseInfo only for each of the ProductPromoUseInfo in the list. Here is an example: we have 2 promotions: PROMO A PROMO B After test run: ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 ProductPromoUseInfo - PROMO B - #1 - weight 0.4 After sorting: ProductPromoUseInfo - PROMO B - #1 - weight 0.4 ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 Based on this we create a list (sortedExplodedProductPromoList) of ProductPromo: PROMO B - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=2 When we apply these to the cart we get the following results: PROMO B - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=2 NOT APPLIED (because PROMO B used the item) git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release13.07@1554381 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Mar 5, 2017
------------------------------------------------------------------------ r1353681 | jacopoc | 2012-06-25 19:46:07 +0200 (lun., 25 juin 2012) | 8 lines Cleaned up some code that was adding the delegator/dispatcher/security/auth objects in the user session rather than the request; 1) removed the request-maps for changeDelegator from components' controller.xml files: they were not used 2) removed CoreEvents.changeDelegator(...): not used (apart from the request-maps removed at #1) 3) removed CoreEvents.changeDispatcher(...): not used 4) cleaned up some code (related to multitenant development): now the objects are set in the request rather than the session PS: as a consequence this will also fix the issue reported in OFBIZ-4289 ------------------------------------------------------------------------ � git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release12.04@1358545 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Mar 5, 2017
Applied patch from jira issue - OFBIZ-4343. When user tries to apply the specified promotion then following problem occurs; 1) Promotion is not applying for the customer, that means customer do not get the discount even if any promotion of such kind exists for the user. 1.1) To fix the above will need to add group-by clause to 2 more fields orderTypeId and statusId of view entity OrderHeaderAndRoleSummary as these fields do not have any values to check the condition, as group-by clause do not allow to show them if values are different. 2) After fixing the issue explained in #1, if user pass the other_value as 12 (month) and condVlaue as $ 1000.00, then after $ 1000 if user order history is of $ 900. Then it will pass the check and then user is allow to get discount on any number on the last order. 3) That means even if the limit is 1000 user is able to purchase in discount of 900 + 300 >> 1200 amount with complete discount. So before checking for the total amount on order history now system will check for "order history + cart sub total". Thanks Rishi for the contribution! git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release11.04@1148183 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Mar 5, 2017
Applied patch from jira issue - OFBIZ-4343. When user tries to apply the specified promotion then following problem occurs; 1) Promotion is not applying for the customer, that means customer do not get the discount even if any promotion of such kind exists for the user. 1.1) To fix the above will need to add group-by clause to 2 more fields orderTypeId and statusId of view entity OrderHeaderAndRoleSummary as these fields do not have any values to check the condition, as group-by clause do not allow to show them if values are different. 2) After fixing the issue explained in #1, if user pass the other_value as 12 (month) and condVlaue as $ 1000.00, then after $ 1000 if user order history is of $ 900. Then it will pass the check and then user is allow to get discount on any number on the last order. 3) That means even if the limit is 1000 user is able to purchase in discount of 900 + 300 >> 1200 amount with complete discount. So before checking for the total amount on order history now system will check for "order history + cart sub total". Thanks Rishi for the contribution! git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release10.04@1148182 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Oct 6, 2019
=== This is a refactoring of the product promotion engine in order to overcome some limitations that prevented it to select and apply the best set of promotions under special conditions. Example: Consider two promotions: * consider two products: Product A, with price $20, and Product B, with price $40 * Promotion 1: 20% discount on all the products in a category containing Product A and Product B * Promotion 2: 40% discount on Product A When Product A and Product B are both in the cart: * Expected behavior: on Product A the Promotion 2 should be applied i.e. 40% discount, and on Product B Promotion 1 should be applied i.e. 20% discount. ** Summary Product Price Discount Subtotal A $20 $8 (40% discount) $12 B $40 $8 (20% discount) $32 Total Adjustment: $16 * OFBiz behavior (before this fix): Promotion 1 is applied to Product A and Product B; this happens because the total discount of Promotion 1 is greater than the total discount of Promotion 2 and OFBiz applies promotions sorted by discount (desc) ** Summary Product Price Discount Subtotal A $20 $4 (20% discount) $16 B $40 $8 (20% discount) $32 Total Adjustment: $12 The new solution fixes this issue and similar ones. Here are some details about the new algorithm. Overview of the flow: 1) run the promotions one by one in a test run 2) collect the ProductPromoUse information 3) sort them by weight (i.e. the ratio between the discount and the value of the products discounted) 4) execute the ProductPromoUse in the given order In order to understand this solution, and specifically the changes to ProductPromoWorker.java, there is an important concept to consider: one Promotion can generate more than one ProductPromoUseInfo objects. For example if I have 2 units of WG-1111 in the cart (in one cart item) and I have the promotion “20% discount on WG-1111 and GZ-1000” then the system will create TWO ProductPromoUseInfo objects both associated to the same promotion one for each of the 2 units discounted. Similarly if I had two lines: 2 units of WG-1111 and 1 unit of GZ-1000 I would get 3 ProductPromoUseInfo objects 2 objects for WG-1111 and 1 object for GZ-1000 We can sort these ProductPromoUseInfo objects based on their weight (i.e. the ratio between the discount and the value of the products discounted) in desc order and now we have a sorted list of ProductPromoUseInfo objects ready to be executed However we only want to execute each of them once and for this reason we set (in memory, not in the DB) the useLimitPerOrder to 1 in the first ProductPromoUseInfo of a given promotion and then to 2 if the same ProductPromoUseInfo is associated to the same promotion etc... in this way the end result is that the system will generate, as we desire, ONE ProductPromoUseInfo only for each of the ProductPromoUseInfo in the list. Here is an example: we have 2 promotions: PROMO A PROMO B After test run: ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 ProductPromoUseInfo - PROMO B - #1 - weight 0.4 After sorting: ProductPromoUseInfo - PROMO B - #1 - weight 0.4 ProductPromoUseInfo - PROMO A - #1 - weight 0.3 ProductPromoUseInfo - PROMO A - #2 - weight 0.3 Based on this we create a list (sortedExplodedProductPromoList) of ProductPromo: PROMO B - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=1 PROMO A - with useLimitPerOrder=2 When we apply these to the cart we get the following results: PROMO B - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=1 APPLIED PROMO A - with useLimitPerOrder=2 NOT APPLIED (because PROMO B used the item) git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release13.07@1554381 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Oct 6, 2019
Applied patch from jira issue - OFBIZ-4343. When user tries to apply the specified promotion then following problem occurs; 1) Promotion is not applying for the customer, that means customer do not get the discount even if any promotion of such kind exists for the user. 1.1) To fix the above will need to add group-by clause to 2 more fields orderTypeId and statusId of view entity OrderHeaderAndRoleSummary as these fields do not have any values to check the condition, as group-by clause do not allow to show them if values are different. 2) After fixing the issue explained in #1, if user pass the other_value as 12 (month) and condVlaue as $ 1000.00, then after $ 1000 if user order history is of $ 900. Then it will pass the check and then user is allow to get discount on any number on the last order. 3) That means even if the limit is 1000 user is able to purchase in discount of 900 + 300 >> 1200 amount with complete discount. So before checking for the total amount on order history now system will check for "order history + cart sub total". Thanks Rishi for the contribution! git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release10.04@1148182 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Oct 6, 2019
------------------------------------------------------------------------ r1353681 | jacopoc | 2012-06-25 19:46:07 +0200 (lun., 25 juin 2012) | 8 lines Cleaned up some code that was adding the delegator/dispatcher/security/auth objects in the user session rather than the request; 1) removed the request-maps for changeDelegator from components' controller.xml files: they were not used 2) removed CoreEvents.changeDelegator(...): not used (apart from the request-maps removed at #1) 3) removed CoreEvents.changeDispatcher(...): not used 4) cleaned up some code (related to multitenant development): now the objects are set in the request rather than the session PS: as a consequence this will also fix the issue reported in OFBIZ-4289 ------------------------------------------------------------------------ � git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release12.04@1358545 13f79535-47bb-0310-9956-ffa450edef68
asfgit
pushed a commit
that referenced
this pull request
Oct 6, 2019
Applied patch from jira issue - OFBIZ-4343. When user tries to apply the specified promotion then following problem occurs; 1) Promotion is not applying for the customer, that means customer do not get the discount even if any promotion of such kind exists for the user. 1.1) To fix the above will need to add group-by clause to 2 more fields orderTypeId and statusId of view entity OrderHeaderAndRoleSummary as these fields do not have any values to check the condition, as group-by clause do not allow to show them if values are different. 2) After fixing the issue explained in #1, if user pass the other_value as 12 (month) and condVlaue as $ 1000.00, then after $ 1000 if user order history is of $ 900. Then it will pass the check and then user is allow to get discount on any number on the last order. 3) That means even if the limit is 1000 user is able to purchase in discount of 900 + 300 >> 1200 amount with complete discount. So before checking for the total amount on order history now system will check for "order history + cart sub total". Thanks Rishi for the contribution! git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/release11.04@1148183 13f79535-47bb-0310-9956-ffa450edef68
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cmssite component by adding CMSS_DEMO_JCRPAGE1 and CMSS_DEMO_JCRIMAGE1. Also supporting using standalone jackrabbit server and make it configurable through jcr-config.xml. Need add jcr content first using the jackrabbit under example component.