[jira] [Updated] (OFBIZ-11129) Clean usage of the ServletContext
[ https://issues.apache.org/jira/browse/OFBIZ-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11129: --- Attachment: OFBIZ-11129_plugins-Improved-Use-ServletRequest-getServletContext-when-p.patch > Clean usage of the ServletContext > - > > Key: OFBIZ-11129 > URL: https://issues.apache.org/jira/browse/OFBIZ-11129 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: > OFBIZ-11129_0001-Improved-Use-ServletRequest-getServletContext-when-p.patch, > OFBIZ-11129_0002-Improved-Add-RequestHandler-from-static-method.patch, > OFBIZ-11129_plugins-Improved-Use-ServletRequest-getServletContext-when-p.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-11129) Clean usage of the ServletContext
[ https://issues.apache.org/jira/browse/OFBIZ-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11129: --- Attachment: OFBIZ-11129_0001-Improved-Use-ServletRequest-getServletContext-when-p.patch OFBIZ-11129_0002-Improved-Add-RequestHandler-from-static-method.patch > Clean usage of the ServletContext > - > > Key: OFBIZ-11129 > URL: https://issues.apache.org/jira/browse/OFBIZ-11129 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: > OFBIZ-11129_0001-Improved-Use-ServletRequest-getServletContext-when-p.patch, > OFBIZ-11129_0002-Improved-Add-RequestHandler-from-static-method.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-11129) Clean usage of the ServletContext
Mathieu Lirzin created OFBIZ-11129: -- Summary: Clean usage of the ServletContext Key: OFBIZ-11129 URL: https://issues.apache.org/jira/browse/OFBIZ-11129 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875136#comment-16875136 ] Jacques Le Roux commented on OFBIZ-10307: - Currently the CORS demonstration in example component is useless. I'd like to commit [^OFBIZ-10307.patch] . What do you think? > Navigate from a domain to another with automated signed in authentication > - > > Key: OFBIZ-10307 > URL: https://issues.apache.org/jira/browse/OFBIZ-10307 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test > from example.patch, OFBIZ-10307-test from example.patch, > OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, > OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch > > > This will use a JWT Token authentication to get from one domain, where you > are signed in, to another domain where you get signed in automatically. > Something like ExternalLoginKey or Tomcat SSO, but not on the same domain. > This will build upon the initial work done at OFBIZ-9833 which has been > partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I > explained why and what I did at [https://s.apache.org/a5Km] > I turned to Ajax for the "Authorization" header sending. I initially thought > I'd just pass an "Authorization" header and use it in the > externalServerLoginCheck preprocessor, et voilà. > But I stumbled upon something I did not know well : CORS! And in particular > the upstream control (Pre-verified requests): > > [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example] > [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS] > [https://www.w3.org/TR/cors/] > To be able to pass an "Authorization" header, the server must respond > positively in the Preflight HTTP response (OPTIONS). To do this, either you > use a Tomcat filter (or your own filter, there are examples on the Net) or > use HTTPD (or Nginx) configuration on the target server. > I tried Tomcat first, without success. With HTTPD it's easier just 3 lines. > For my tests, future tests by OFBiz users and as an example, I asked infra to > put them in our HTTPD trunk demo config: > Header set Access-Control-Allow-Origin "https://localhost:8443; > Header set Access-Control-Allow-Headers "Authorization" > Header set Access-Control-Allow-Credentials "true" > No code change (either in all web.xml files for Tomcat or Java for own > filter), and more safety. It does not give more right to outsiders than what > we give with the admin credential. > In Header set Access-Control-Allow-Origin you can put more domains. I just > used [https://localhost:8443|https://localhost:8443/] for the tests. > It works in Chrome, Firefox and Opera and partially in IE11 (not tested in > Edge). I did not test Safari, but I guess like other modern browsers it > should work. > For those (very few I guess) interested by IE11 (for Edge test yourself and > report please), here is the solution > > [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true] > > [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx] > > [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/] > TODO (maybe) in the future, use the new Fetch API (not available yet): > [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API] > > Here is a complement about the way it's architectured: > # A change to cookies was introduced with OFBIZ-4959. Actually it was not > really a bug rather a clean-up. The autoLogin cookies were only used by the > ecommerce component and maybe webpos. But all applications were creating such > cookies with a one year duration. They were useless until I needed them for > the feature of this Jira issue. But even if they were safe (httponly) then I > needed them to be clean, not a one year duration (to be as safe as possible, > temporary cookies are better). So after doing it crudely, [inspired by > Taher's suggestion|https://s.apache.org/qLGC] I introduced the > keep-autologin-cookie attribute in ofbiz-component.xml. It's used to > remove not kept cookies when login in or out. So those cookies are only kept > during a session. Also a cookie is created
[jira] [Updated] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10307: Attachment: OFBIZ-10307.patch > Navigate from a domain to another with automated signed in authentication > - > > Key: OFBIZ-10307 > URL: https://issues.apache.org/jira/browse/OFBIZ-10307 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test > from example.patch, OFBIZ-10307-test from example.patch, > OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, > OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch > > > This will use a JWT Token authentication to get from one domain, where you > are signed in, to another domain where you get signed in automatically. > Something like ExternalLoginKey or Tomcat SSO, but not on the same domain. > This will build upon the initial work done at OFBIZ-9833 which has been > partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I > explained why and what I did at [https://s.apache.org/a5Km] > I turned to Ajax for the "Authorization" header sending. I initially thought > I'd just pass an "Authorization" header and use it in the > externalServerLoginCheck preprocessor, et voilà. > But I stumbled upon something I did not know well : CORS! And in particular > the upstream control (Pre-verified requests): > > [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example] > [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS] > [https://www.w3.org/TR/cors/] > To be able to pass an "Authorization" header, the server must respond > positively in the Preflight HTTP response (OPTIONS). To do this, either you > use a Tomcat filter (or your own filter, there are examples on the Net) or > use HTTPD (or Nginx) configuration on the target server. > I tried Tomcat first, without success. With HTTPD it's easier just 3 lines. > For my tests, future tests by OFBiz users and as an example, I asked infra to > put them in our HTTPD trunk demo config: > Header set Access-Control-Allow-Origin "https://localhost:8443; > Header set Access-Control-Allow-Headers "Authorization" > Header set Access-Control-Allow-Credentials "true" > No code change (either in all web.xml files for Tomcat or Java for own > filter), and more safety. It does not give more right to outsiders than what > we give with the admin credential. > In Header set Access-Control-Allow-Origin you can put more domains. I just > used [https://localhost:8443|https://localhost:8443/] for the tests. > It works in Chrome, Firefox and Opera and partially in IE11 (not tested in > Edge). I did not test Safari, but I guess like other modern browsers it > should work. > For those (very few I guess) interested by IE11 (for Edge test yourself and > report please), here is the solution > > [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true] > > [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx] > > [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/] > TODO (maybe) in the future, use the new Fetch API (not available yet): > [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API] > > Here is a complement about the way it's architectured: > # A change to cookies was introduced with OFBIZ-4959. Actually it was not > really a bug rather a clean-up. The autoLogin cookies were only used by the > ecommerce component and maybe webpos. But all applications were creating such > cookies with a one year duration. They were useless until I needed them for > the feature of this Jira issue. But even if they were safe (httponly) then I > needed them to be clean, not a one year duration (to be as safe as possible, > temporary cookies are better). So after doing it crudely, [inspired by > Taher's suggestion|https://s.apache.org/qLGC] I introduced the > keep-autologin-cookie attribute in ofbiz-component.xml. It's used to > remove not kept cookies when login in or out. So those cookies are only kept > during a session. Also a cookie is created when an user jumps from one > application to another on the source domain. These cookies are used when > navigating from a domain to
[jira] [Commented] (OFBIZ-11108) Freemarker error on reviewProduct page on storefront
[ https://issues.apache.org/jira/browse/OFBIZ-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874889#comment-16874889 ] Jacques Le Roux commented on OFBIZ-11108: - Just a question: [~minal.phalak] and [~minal] are you the same person? If yes please drop one of the username or ask Infra to do so. It always confusing when the same person has 2 usernames in Jira. Else just forget it :) > Freemarker error on reviewProduct page on storefront > > > Key: OFBIZ-11108 > URL: https://issues.apache.org/jira/browse/OFBIZ-11108 > Project: OFBiz > Issue Type: Improvement > Components: ecommerce >Reporter: Minal Phalak >Assignee: Phalak Minal Yuvraj >Priority: Major > Attachments: OFBIZ-11108.patch, reviewProduct.png > > > Steps to regenerate: > 1)Navigate to [https://demo-trunk.ofbiz.apache.org/ecommerce/control/main] > 2) User should not be logged in > 3) Click on any product > 4) Click on Be The First To Review This Product! link > 5) FTL error for the null check is occurring > Refer the attached screenshot: -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-9533) User should be notified with success message on MRP run in manufacturing component
[ https://issues.apache.org/jira/browse/OFBIZ-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9533. -- Resolution: Fixed Fix Version/s: 18.12.01 16.11.06 17.12.01 Thanks Humera, Your patch is in trunk r1862278 R18 r1862279 R17 r1862280 R16 r1862281 Thanks Prachi for testing. Pierre noticed this could be backported and Aditya agreed. Despite being a sub-task of an improvement I unilaterally decided to backport. It works well and nothing could go wrong, only UI changes. > User should be notified with success message on MRP run in manufacturing > component > -- > > Key: OFBIZ-9533 > URL: https://issues.apache.org/jira/browse/OFBIZ-9533 > Project: OFBiz > Issue Type: Sub-task > Components: manufacturing >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12, > Release Branch 18.12 >Reporter: Aditya Sharma >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: 17.12.01, 16.11.06, 18.12.01 > > Attachments: OFBIZ-9533-trunk.patch, OFBIZ-9533.patch > > > Steps to regenerate: > 1. Go to Manufacturing component > (https://demo-trunk.ofbiz.apache.org/manufacturing/control/main) > 2. Click on Mrp sub menu > (https://demo-trunk.ofbiz.apache.org/manufacturing/control/FindInventoryEventPlan) > 3. Click on Run Mrp > button.(https://demo-trunk.ofbiz.apache.org/manufacturing/control/RunMrp) > 4. Select Facility/Facility Group and Click Submit button. > On success, the user should be notified with success message like "Mrp run is > scheduled". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-9533) User should be notified with success message on MRP run in manufacturing component
[ https://issues.apache.org/jira/browse/OFBIZ-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9533: -- Assignee: Jacques Le Roux (was: Humera Khan) > User should be notified with success message on MRP run in manufacturing > component > -- > > Key: OFBIZ-9533 > URL: https://issues.apache.org/jira/browse/OFBIZ-9533 > Project: OFBiz > Issue Type: Sub-task > Components: manufacturing >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12, > Release Branch 18.12 >Reporter: Aditya Sharma >Assignee: Jacques Le Roux >Priority: Trivial > Attachments: OFBIZ-9533-trunk.patch, OFBIZ-9533.patch > > > Steps to regenerate: > 1. Go to Manufacturing component > (https://demo-trunk.ofbiz.apache.org/manufacturing/control/main) > 2. Click on Mrp sub menu > (https://demo-trunk.ofbiz.apache.org/manufacturing/control/FindInventoryEventPlan) > 3. Click on Run Mrp > button.(https://demo-trunk.ofbiz.apache.org/manufacturing/control/RunMrp) > 4. Select Facility/Facility Group and Click Submit button. > On success, the user should be notified with success message like "Mrp run is > scheduled". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874851#comment-16874851
]
Jayansh Shinde edited comment on OFBIZ-10966 at 6/28/19 11:48 AM:
--
Hi Jacques/Mathieu,
Thank you for pointing this out, I will change it to jackson, and remove
the dependency. This is a mistake, as library is there already I should have
implemented same. This is what we practice, but don't know how I missed it.
was (Author: jayansh):
Hi Jacques/Mathieu,
Thank you for pointing this out, I will change it to jackson, and remove
the dependency. I will keep posted.
On Fri, Jun 28, 2019 at 3:00 PM Jacques Le Roux (JIRA)
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10671) Error message is displayed when user having space in username logs in at ecommerce
[ https://issues.apache.org/jira/browse/OFBIZ-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-10671: --- Assignee: Praveen Sharma (was: Jacques Le Roux) Hi Praveen, "-" misses in the regepx definition. Also I think it's OK, because so far plugins depends on applications (reverse should never be true), but I wonder what other committers think about creating NotValidUserName label in party component when it's only used in ecommerce. I reassign to you, thanks. > Error message is displayed when user having space in username logs in at > ecommerce > -- > > Key: OFBIZ-10671 > URL: https://issues.apache.org/jira/browse/OFBIZ-10671 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Praveen Sharma >Priority: Major > Attachments: 1-Register.png, 2-Redirected.png, 3-Login.png, > OFBIZ-10671-1.patch, OFBIZ-10671-2.patch > > > Steps to regenerate: > # Open URL: [https://demo-trunk.ofbiz.apache.org/ecommerce/control/main] > # Click on register in header section > # Provide all the mandatory information but provide a user name such that is > contains a space (like: Walter White or Jesse Pinkman) (Please refer > attachment: 1-Register) > # Click on save button > Actual: When user clicks on save button then he is redirected to main page of > ecommerce and an error message is displayed. (Please refer attachment: > 2-Redirected) > Similarly when user with space in username tries to login, error message is > displayed. (Please refer attachment: 3-Login) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10671) Error message is displayed when user having space in username logs in at ecommerce
[ https://issues.apache.org/jira/browse/OFBIZ-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-10671: --- Assignee: Jacques Le Roux (was: Praveen Sharma) > Error message is displayed when user having space in username logs in at > ecommerce > -- > > Key: OFBIZ-10671 > URL: https://issues.apache.org/jira/browse/OFBIZ-10671 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: 1-Register.png, 2-Redirected.png, 3-Login.png, > OFBIZ-10671-1.patch, OFBIZ-10671-2.patch > > > Steps to regenerate: > # Open URL: [https://demo-trunk.ofbiz.apache.org/ecommerce/control/main] > # Click on register in header section > # Provide all the mandatory information but provide a user name such that is > contains a space (like: Walter White or Jesse Pinkman) (Please refer > attachment: 1-Register) > # Click on save button > Actual: When user clicks on save button then he is redirected to main page of > ecommerce and an error message is displayed. (Please refer attachment: > 2-Redirected) > Similarly when user with space in username tries to login, error message is > displayed. (Please refer attachment: 3-Login) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874815#comment-16874815 ] Jacques Le Roux edited comment on OFBIZ-10150 at 6/28/19 11:07 AM: --- Thanks Rohit, Your patch is in trunk r1862271 R18 r1862272 R17 r1862273 R16 r1862274 I don't close as it's an opportunity to fix all cases. We could create sub-tasks but I believe patches and comments here are enough. No needs to dilute things. Thankd Jesse for report. was (Author: jacques.le.roux): Thanks Rohit, Your patch is in trunk r1862271 R18 r1862272 R17 r1862273 R16 r1862274 I don't close as it's an opportunity to fix all case. We could create sub-tasks but I believe patches and comments here are enough. No needs to dilute things. Thankd Jesse for report. > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Bug > Components: order, product >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12, > Release Branch 18.12 > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874815#comment-16874815 ] Jacques Le Roux edited comment on OFBIZ-10150 at 6/28/19 11:07 AM: --- Thanks Rohit, Your patch is in trunk r1862271 R18 r1862272 R17 r1862273 R16 r1862274 I don't close as it's an opportunity to fix all case. We could create sub-tasks but I believe patches and comments here are enough. No needs to dilute things. Thankd Jesse for report. was (Author: jacques.le.roux): Thanks Rohit, Your patch is in trunk r1862271 R18 r1862272 R17 r1862273 R196 r1862274 I don't close as it's an opportunity to fix all case. We could create sub-tasks but I believe patches and comments here are enough. No needs to dilute things. Thankd Jesse for report. > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Bug > Components: order, product >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12, > Release Branch 18.12 > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874851#comment-16874851
]
Jayansh Shinde commented on OFBIZ-10966:
Hi Jacques/Mathieu,
Thank you for pointing this out, I will change it to jackson, and remove
the dependency. I will keep posted.
On Fri, Jun 28, 2019 at 3:00 PM Jacques Le Roux (JIRA)
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-10150: - Affects Version/s: Release Branch 18.12 Release Branch 17.12 Release Branch 16.11 > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Bug > Components: order, product >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12, > Release Branch 18.12 > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874816#comment-16874816 ] Suraj Khurana commented on OFBIZ-10150: --- Thanks Jacques !! > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Bug > Components: order, product >Affects Versions: Trunk > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874815#comment-16874815 ] Jacques Le Roux commented on OFBIZ-10150: - Thanks Rohit, Your patch is in trunk r1862271 R18 r1862272 R17 r1862273 R196 r1862274 I don't close as it's an opportunity to fix all case. We could create sub-tasks but I believe patches and comments here are enough. No needs to dilute things. Thankd Jesse for report. > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Bug > Components: order, product >Affects Versions: Trunk > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10150: Priority: Major (was: Minor) Issue Type: Bug (was: Improvement) I was wrong this is a major bug indeed, making it so! > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Bug > Components: order, product >Affects Versions: Trunk > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318266#comment-16318266 ] Jacques Le Roux edited comment on OFBIZ-10150 at 6/28/19 9:30 AM: -- This is not a bug but could be an improvement so only concerns the trunk. Such a thing should be discussed 1st on dev ML prior to create a Jira. was (Author: jacques.le.roux): This is not a bug but could be an improvement son concern only the trunk. Such a thing should be discussed 1st on dev ML prior to create a Jira. > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Improvement > Components: order, product >Affects Versions: Trunk > Environment: all >Reporter: jesse thomas >Assignee: Rohit Hukkeri >Priority: Minor > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10150) supplierProductId Should Have Consistent Types Across Entities.
[ https://issues.apache.org/jira/browse/OFBIZ-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-10150: --- Assignee: Jacques Le Roux (was: Rohit Hukkeri) > supplierProductId Should Have Consistent Types Across Entities. > --- > > Key: OFBIZ-10150 > URL: https://issues.apache.org/jira/browse/OFBIZ-10150 > Project: OFBiz > Issue Type: Improvement > Components: order, product >Affects Versions: Trunk > Environment: all >Reporter: jesse thomas >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-10150.patch > > > During some data migration I hit an issue where my data for supplierProductId > was too long. So I looked up the fields and noticed that the order item > entity had a different type for the field than the supplier product entity. I > think it would be a good idea to pick one so the two fields can be treated > consistently. I would vote for id-long, but I think either way it would be > good to have them be the same type. There are other fields that have this > issue too if you are interested? > > Thanks! > applications/datamodel/entitydef/order-entitymodel.xml: > > applications/datamodel/entitydef/product-entitymodel.xml: > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874804#comment-16874804
]
Jacques Le Roux edited comment on OFBIZ-10966 at 6/28/19 9:29 AM:
--
You don't need to apologise Mathieu. Actually I [somehow knew
it|https://markmail.org/message/4cm5vjuqr4zeym7p] (tend to forget things with
age :P) but was lazy (hè it was 36°c yesterday, and we wait for 45°c today -
higher temp ever in France ;)). I'm happy you spotted it, opportunities for
youth :D.
was (Author: jacques.le.roux):
You don't need to apologise Mathieu. Actually I [somehow knew
it|https://markmail.org/message/4cm5vjuqr4zeym7p] (tend to forget things with
age :P) but was lazy (hè it was 36°c yesterday, and we wait for 45°c today ;)).
I'm happy you spotted it, opportunities for youth :D.
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874808#comment-16874808 ] Jacques Le Roux commented on OFBIZ-10489: - Thanks Mohammad, That sounds legit to me, could you pleas try and confirm it fixes your issues Oleg? > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Mohammad Kathawala >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874804#comment-16874804
]
Jacques Le Roux commented on OFBIZ-10966:
-
You don't need to apologise Mathieu. Actually I [somehow knew
it|https://markmail.org/message/4cm5vjuqr4zeym7p] (tend to forget things with
age :P) but was lazy (hè it was 36°c yesterday, and we wait for 45°c today ;)).
I'm happy you spotted it, opportunities for youth :D.
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874748#comment-16874748
]
Mathieu Lirzin commented on OFBIZ-10966:
I am realizing that my previous message can feel a bit rude, so I apologize for
that.
[~jayansh] Can you investigate how to remove the dependency on
'org.json:json:20140107' to use Jackson instead?
Thanks
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin reassigned OFBIZ-10966:
--
Assignee: Mathieu Lirzin (was: Jacques Le Roux)
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870233#comment-16870233 ] Jacques Le Roux edited comment on OFBIZ-10489 at 6/28/19 6:55 AM: -- The issue is generated because of the code committed in the patch from the ticket OFBIZ-5416. Here the code was properly handled in _ShoppingCartEvents.java_ but not in _ShoppingCartHelper.java._ Did the same handling in _ShoppingCartHelper.java_ in the patch *OFBIZ-10489.patch*. was (Author: mohammad k): The issue is generated because of the code committed in the patch from the ticket https://issues.apache.org/jira/browse/OFBIZ-5416. Here the code was properly handled in _ShoppingCartEvents.java_ but not in _ShoppingCartHelper.java._ Did the same handling in _ShoppingCartHelper.java_ in the patch *OFBIZ-10489.patch*. > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Mohammad Kathawala >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-11128) Error when manually loading data in "XML Data Import" using "Import Text"
[
https://issues.apache.org/jira/browse/OFBIZ-11128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-11128.
---
Resolution: Invalid
I was wrong, surrounding by works!
It's also stated in the page:
bq. These documents all have a root tag of "".
This was not necessary before, I now know it's needed
> Error when manually loading data in "XML Data Import" using "Import Text"
> -
>
> Key: OFBIZ-11128
> URL: https://issues.apache.org/jira/browse/OFBIZ-11128
> Project: OFBiz
> Issue Type: Bug
> Components: framework/webtools
>Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12,
> Release Branch 18.12
>Reporter: Jacques Le Roux
>Priority: Major
>
> I cross this issue for already some times and while testing OFBIZ-10966 I
> decided to report it. It' still present once the today OFBIZ-10966 patch is
> applied. I guess R16 is also concerned.
> I thought only Windows was concerned but I tested today by copying the 1st
> block of line in AccountingDemoData.xml and stable as trunk demo also fail.
> Reproducing is easy: simply copy a block of lines from a data file either in
> Eclipse or in another editor.
> The error is
> {{org.xml.sax.SAXParseException: The markup in the document following the
> root element must be well-formed.}}
> * Importing only the 1st line works.
> * Removing the lines delimiter (ie have the text not separated by lines) in
> the OFBiz textarea does not work
> * Converting CR/LF to LF does not help
> * Removing heading or trailing white spaces does not help
> * Surrounding by does not help
> In other words you have to import lines one by one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
