Re: buildbot failure in ASF Buildbot on ofbiz-trunk
I think a few people were trying to test it out, I just fixed a bug that Jacques introduced this morning :-) Thanks Jacopo, ping me if you need any help, it's only been a couple of days since I was working on those tests. Regards Scott On 24/11/2009, at 8:39 PM, Jacopo Cappellato wrote: On Nov 24, 2009, at 6:13 AM, Scott Gray wrote: I did actually expect the build to fail, Jacopo committed some data changes yesterday that the accounting tests depend on but I'll get them fixed up tonight. After that you're all on your own, you break it you fix it :-) I could try to say that I was just testing the new build notification mechanism :-) Please Scott, don't work on this, I am fixing them now. Jacopo Regards Scott HotWax Media http://www.hotwaxmedia.com On 24/11/2009, at 6:32 PM, build...@apache.org wrote: The Buildbot has detected a failed build of ofbiz-trunk on ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/1829 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: forced: by IRC user on channel #asftest: testing new config as requested in INFRA-2345 Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile_1 sincerely, -The Buildbot smime.p7s Description: S/MIME cryptographic signature
Re: buildbot failure in ASF Buildbot on ofbiz-trunk
On Nov 24, 2009, at 6:13 AM, Scott Gray wrote: > I did actually expect the build to fail, Jacopo committed some data changes > yesterday that the accounting tests depend on but I'll get them fixed up > tonight. After that you're all on your own, you break it you fix it :-) > I could try to say that I was just testing the new build notification mechanism :-) Please Scott, don't work on this, I am fixing them now. Jacopo > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 24/11/2009, at 6:32 PM, build...@apache.org wrote: > >> The Buildbot has detected a failed build of ofbiz-trunk on ASF Buildbot. >> Full details are available at: >> http://ci.apache.org/builders/ofbiz-trunk/builds/1829 >> >> Buildbot URL: http://ci.apache.org/ >> >> Buildslave for this Build: isis_ubuntu >> >> Build Reason: forced: by IRC user on channel #asftest: testing >> new config as requested in INFRA-2345 >> Build Source Stamp: HEAD >> Blamelist: >> >> BUILD FAILED: failed compile_1 >> >> sincerely, >> -The Buildbot >> >
Re: All JUnit tests now pass! Next steps...
Hey Scott, I think I am responsible for this (I have changed some of the demo data yesterday). I am going to fix them right away, so don't waste your time on this. Thank you for the notice, Jacopo On Nov 24, 2009, at 6:13 AM, Scott Gray wrote: > BTW, the accounting tests are failing at the moment but I'll have them fixed > again shortly. > > Regards > Scott > > On 24/11/2009, at 6:09 PM, Scott Gray wrote: > >> Hi Adrian, >> >> Yeah that issue has been there for a while but you'll notice that the >> exception is just a logged exception and isn't actually thrown, hence no >> error and the test passes. >> >> Regards >> Scott >> >> On 24/11/2009, at 6:01 PM, Adrian Crum wrote: >> >>> Scott, >>> >>> Are you sure all tests pass? I'm seeing errors in the entity engine test - >>> testBlobCreate. I thought it might be caused by my recent Blob converter >>> commit, so I reverted it locally. I still get the same error. Looking at >>> the code causing the error (GenericEntity.java line 420) it appears to me >>> this test never should have succeeded. >>> >>> -Adrian >>> >>> --- On Mon, 11/23/09, Scott Gray wrote: >>> From: Scott Gray Subject: Re: All JUnit tests now pass! Next steps... To: dev@ofbiz.apache.org Date: Monday, November 23, 2009, 7:53 PM Quick update, I've since learnt that we've already had the trunk and 9.04 branch running on buildbot at the ASF for a few months now. I've created an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345) requesting that build notifications be sent to the dev list and also that the run-install and run-tests targets be added to the buildbot configuration (for the trunk only). Regards Scott On 20/11/2009, at 9:06 AM, Scott Gray wrote: > Thanks for the pointer Christian, I figured the ASF would have something for us and they haven't disappointed :-) > > I'll keep playing around the different CI services locally for a little bit so I can learn how they work a bit better and also find the one that will be the most useful to us. > > Thanks > Scott > > On 20/11/2009, at 1:08 AM, Christian Geisert wrote: > >> Scott Gray schrieb: >>> It took a while but all our JUnit tests now pass, next I'd like to get a continuous integration server set up. Can anybody recommend some tools >> >> Why not just use what is available at the ASF ;-) >> >> http://ci.apache.org/ >> >> I use Hudson and like it, but I haven't tried the others... >> >>> Once that is done I'd like to have it run the tests after every commit and report any failures to the dev list. It would then be the offending committer's responsibility (well primarily at least) to fix the problem as soon as possible, much like a build failure. If we can't get everyone to agree to take on that responsibility then I might as well stop now because I'll be damned if I'm going to spend any more time fixing tests that I didn't break :-) >> >> +1 >> >>> All of this should help us increase the stability of the trunk and our confidence when taking a checkout that we won't half to spend our development time fixing things that used to work. It'll hopefully also encourage the community to contribute more tests with the knowledge that doing so will increase the stability of the functionality they depend on. Fix a bug and you're good for a day, write a test and you're good a lifetime :-) >> >> Absolutly agreed, big thanks for your (and all the others) work in this area! >> >> --Christian >> > >>> >>> >>> >> >
[jira] Closed: (OFBIZ-2619) Issues with Receive PO functionality
[ https://issues.apache.org/jira/browse/OFBIZ-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-2619. -- Resolution: Fixed Thanks Mridul for the contribution. Yesterday I had put your changes in trunk and today it is back ported to release branch 9.04 at r883604. Also closing this issue. We will reopen it if we see any comment from Adrian or others? on recent changes. -- Ashish Vijaywargiya > Issues with Receive PO functionality > > > Key: OFBIZ-2619 > URL: https://issues.apache.org/jira/browse/OFBIZ-2619 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Mridul Pathak >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBiz-2619.patch, OFBiz-2619.patch, OFBiz-2619.patch > > > Following are the issues that I came across while going through different > scenarios of receiving PO: > # Create a shipment and receive it from Facility > Shipment > Receive Against > PO (This scenario works correctly) > ## Before receiving shipment: > OrderItem.quantity = 10 > ## Receiving half if the ordered quantity - New ShipmentItem record created. > New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## Receiving remaining quantity but receiving some extra quantity too - > ShipmentItem record updated. New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 7 > ShipmentItem.quantity = 12 (5 + 7) > ItemIssuance.quantity = 7 > Total ItemIssuance.quantity = 12 (5 + 7) > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Shipment > Receive Against PO > ## Before Issuing Order Items - No ShipmentItem or ItemIssuance record > OrderItem.quantity = 5 > ## After Issuing Order Items - ShipmentItem created, ItemIssuance created. > OrderItem.quantity = 5 > Issued quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## On receiving shipment - ShipmentItem updated, new ItemIssuance created > OrderItem.quantity = 5 > Received quantity = 5 > ShipmentItem.quantity = 10 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 10 (5 + 5) > This seems to be a weird behavior. When I have already issued the item in > #b, then on receiving the shipment for the same orderItem quantity in #c, the > ShipmentItem shouldn't be updated and new item issuance shouldn't be created > (creating new item issuance means that I am re-issuing the items). > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Facilities > Receive Inventory by > selecting PO and the respective newly created shipment. > If I issue the same (or more) quantity as ordered for the Order Item and then > receive the exact amount that has been issued (in one or more steps) this > scenario works fine. in following scenarios there is no change in > ShipmentItem and ItemIssuance, which causes conflicts: > ## I issue same quantity as ordered for the Order Item but while receiving > receive more than the issued ordered quantity. > ## I issue same quantity as ordered for the Order Item. While receiving, > receive less first time. Go back to same screen again. Receive more than > the remaining ordered quantity. > ## I issue less quantity than ordered for the Order Item but receive more > than the issued order item quantity. > # Quick Receive Purchase Order > If I Quick Receive Purchase Order from Order Detail page, Shipment is created > and all the Order Items are issued and I am taken to the Receive Inventory > screen directly. If I receive exactly the same amount as ordered for each > order item (at one go, or receiving it in parts) functionality works fine. > But following are the scenarios which breaks everything. > ## Same as #3-a and #3-b. > ## If I receive less quantity than the quantity ordered for order item, and > receive remaining (or more) ordered quantity from Facility > Shipment > > Receive against PO then same issue as reported in #2 occurs. > Note: For testing these issues, comment out eca action > updatePoOnReceiveInventory at line no. 55 in order/servicedef/secas.xml. > This service was recently added in revision 757749, but it only covers #3-a > and #3-c below partially and its logic needs to be rewritten. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3236) Add new field - Closing balance to Reconciliation Screen
[ https://issues.apache.org/jira/browse/OFBIZ-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-3236. -- Resolution: Fixed Thanks Sumit for the contribution - Done at r883601. -- Ashish Vijaywargiya > Add new field - Closing balance to Reconciliation Screen > > > Key: OFBIZ-3236 > URL: https://issues.apache.org/jira/browse/OFBIZ-3236 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3236.patch > > > At > https://localhost:8443/accounting/control/ViewGlReconciliationWithTransaction?glReconciliationId=9000&finAccountId=SC_CHECKING > - Add a new field to represent Closing balance of Reconciliation. This will > sum of Opening Balance(default 0) + Reconciled Balance (default 0). > - Also rearrange rows showing information. It is as follows - > -- OLD : > Gl Reconciliation Name > Reconciled Balance > Status > Reconciled Date > Opening Balance > -- NEW : > Gl Reconciliation Name > Status > Reconciled Date > Opening Balance > Reconciled Balance > Closing Balance -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: buildbot failure in ASF Buildbot on ofbiz-trunk
Link for our interest: http://ci.apache.org/waterfall?show=ofbiz-trunk -- Ashish On Tue, Nov 24, 2009 at 10:43 AM, Scott Gray wrote: > I did actually expect the build to fail, Jacopo committed some data changes > yesterday that the accounting tests depend on but I'll get them fixed up > tonight. After that you're all on your own, you break it you fix it :-) > > Regards > Scott > > > HotWax Media > http://www.hotwaxmedia.com > > On 24/11/2009, at 6:32 PM, build...@apache.org wrote: > > The Buildbot has detected a failed build of ofbiz-trunk on ASF Buildbot. >> Full details are available at: >> http://ci.apache.org/builders/ofbiz-trunk/builds/1829 >> >> Buildbot URL: http://ci.apache.org/ >> >> Buildslave for this Build: isis_ubuntu >> >> Build Reason: forced: by IRC user on channel #asftest: testing >> new config as requested in INFRA-2345 >> Build Source Stamp: HEAD >> Blamelist: >> >> BUILD FAILED: failed compile_1 >> >> sincerely, >> -The Buildbot >> >> >
Re: Q - FinAccounting Reconciliation Issue
Hi Sumit, IMO this doesnt appears correct to me. I would like to explain with an example :- Suppose FA1 is Banking Account and REC1 is the statement given by the FA1 Bank Account. So this is not possible that the transactions associated with FA2 will Reconcile in the REC1. Definitely FinAccountTrans Associated with FA2 will be reconcile in REC2. Only FinAccountTrans associated with FA1, should reconcile in REC1. Regards -- Chirag Manocha Freelancer +91-98263-19099 On Tue, Nov 24, 2009 at 1:43 AM, Sumit Pandit wrote: > Hi All, I have a question about Financial Account Reconciliation process. > > Currently In Fin Account Reconciliation, more then one FinAccount's > transaction can associate to one Reconciliation. Please verify that is it > correct according to business process? There should be one to one > relationship in FinAccount and Reconciliation. > Explanation with example - > > Suppose - > Fin Account ID : FA1 > Fin Account Transaction for Fin Account Id FA1 - 1, 10001, 10002, > 10003. > Fin Account ID : FA2 > Fin Account Transaction for Fin Account Id FA2 - 10004, 10005, 10006, > 10007. > > Reconciliation Id : REC1, REC2 > > Current Implementation - > REC1 can associate to 1, 10001, 10004, 10005 > Conclusion - One reconciliation can associate to more then on FinAccount's > transaction. > > Please suggest that, Is above process correct? Can one reconciliation > contains more then one FinAccount's transactions? > > -- > Thanks and Regards > Sumit Pandit > >
[jira] Commented: (OFBIZ-3238) FinAccount Reconciliation Search Result Table - Add new column for Cancel Reconciliation.
[ https://issues.apache.org/jira/browse/OFBIZ-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781791#action_12781791 ] Ashish Vijaywargiya commented on OFBIZ-3238: Thanks you Mukesh for the contribution along with Sumit. > FinAccount Reconciliation Search Result Table - Add new column for Cancel > Reconciliation. > - > > Key: OFBIZ-3238 > URL: https://issues.apache.org/jira/browse/OFBIZ-3238 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ_3238.patch > > > At > https://localhost:8443/accounting/control/FindFinAccountReconciliations?finAccountId=SC_CHECKING > In search results, add a column to "Cancel Reconciliation" In this column > show "Cancel" button to cancel reconciliations which are in CREATED status. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3238) FinAccount Reconciliation Search Result Table - Add new column for Cancel Reconciliation.
[ https://issues.apache.org/jira/browse/OFBIZ-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-3238. -- Resolution: Fixed Thanks Sumit for the contribution - Done at r883597. -- Ashish Vijaywargiya > FinAccount Reconciliation Search Result Table - Add new column for Cancel > Reconciliation. > - > > Key: OFBIZ-3238 > URL: https://issues.apache.org/jira/browse/OFBIZ-3238 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ_3238.patch > > > At > https://localhost:8443/accounting/control/FindFinAccountReconciliations?finAccountId=SC_CHECKING > In search results, add a column to "Cancel Reconciliation" In this column > show "Cancel" button to cancel reconciliations which are in CREATED status. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3235) List Reconciliations under Financial Account must bee associated to the Finanacial Account.
[ https://issues.apache.org/jira/browse/OFBIZ-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-3235. -- Resolution: Fixed Thanks Sumit for the contribution - Done at r883588. -- Ashish Vijaywargiya > List Reconciliations under Financial Account must bee associated to the > Finanacial Account. > --- > > Key: OFBIZ-3235 > URL: https://issues.apache.org/jira/browse/OFBIZ-3235 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya > Fix For: SVN trunk > > Attachments: OFBIZ-3235.patch > > > At - > https://demo.ofbiz.org/accounting/control/FindFinAccountReconciliations?finAccountId=SC_CHECKING > At above page, currently all Reconciliation are displaying, but it should > display only those Reconciliation which are associated to the selected > FinAccount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-3242) Add new feature to Bulk Print Invoices.
[ https://issues.apache.org/jira/browse/OFBIZ-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780832#action_12780832 ] Sumit Pandit edited comment on OFBIZ-3242 at 11/24/09 5:24 AM: --- Thanks Awdesh Singh Parihar for patch and testing steps. Testing Scenario for AP :- 1) Go to Url https://localhost:8443/ap/control/findInvoices 2) Search invoice by clicking on find button . 3) Select the invoice you want to print . 4) Select "Print Invoices" option from drop down. 5) Perform Run action . Expected Result : - This will generate one PDF for all selected invoice. Testing Scenario for AR :- 1) Go to Url https://localhost:8443/ar/control/findInvoices 2) Search invoice by clicking on find button . 3) Select the invoices you want to print . 4) Select "Print Invoices" option from drop down. 5) Perform Run action . Expected Result : - This will generate one PDF for all selected invoices . was (Author: sumitp): Thanks Awdesh Singh Parihar for patch and testing steps. Testing Scenario for AP :- 1) Go to Url https://localhost:8443/ap/control/findInvoices 2) Search invoice by clicking on find button . 3) Select the invoice you want to print . 4) Select "Print Invoices" option from drop down. 5) Perform Run action . Expected Result : - This will generate one PDF for all selected invoice. Testing Scenario for AR :- 1) Go to Url https://localhost:8443/ar/control/findInvoices 2) Search invoice by clicking on find button . 3) Select the invoices you want to print . 4) Select "Print Invoices" option from drop down. 5) Perform Run action . Expected Result : - This will generate one PDF for all selected invoices . Actual Result : - Not in current implementation I have added this functionality in patch "EZERP-434EasyErp.patch" > Add new feature to Bulk Print Invoices. > --- > > Key: OFBIZ-3242 > URL: https://issues.apache.org/jira/browse/OFBIZ-3242 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya > Fix For: SVN trunk > > Attachments: OFBIZ-3242.patch > > > It Applies to findInvoices screen in AR and AP. User selects items from > findInvoice search results. Selects Print action and clicks on Run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: All JUnit tests now pass! Next steps...
I didn't notice that. Thanks for pointing it out. -Adrian --- On Mon, 11/23/09, Scott Gray wrote: > From: Scott Gray > Subject: Re: All JUnit tests now pass! Next steps... > To: dev@ofbiz.apache.org > Date: Monday, November 23, 2009, 9:09 PM > Hi Adrian, > > Yeah that issue has been there for a while but you'll > notice that the > exception is just a logged exception and isn't actually > thrown, hence > no error and the test passes. > > Regards > Scott > > On 24/11/2009, at 6:01 PM, Adrian Crum wrote: > > > Scott, > > > > Are you sure all tests pass? I'm seeing errors in the > entity engine > > test - testBlobCreate. I thought it might be caused by > my recent > > Blob converter commit, so I reverted it locally. I > still get the > > same error. Looking at the code causing the > error > > (GenericEntity.java line 420) it appears to me this > test never > > should have succeeded. > > > > -Adrian > > > > --- On Mon, 11/23/09, Scott Gray > wrote: > > > >> From: Scott Gray > >> Subject: Re: All JUnit tests now pass! Next > steps... > >> To: dev@ofbiz.apache.org > >> Date: Monday, November 23, 2009, 7:53 PM > >> Quick update, I've since learnt that > >> we've already had the trunk and 9.04 branch > running on > >> buildbot at the ASF for a few months now. > I've created > >> an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345) > >> requesting that build notifications be sent to the > dev list > >> and also that the run-install and run-tests > targets be added > >> to the buildbot configuration (for the trunk > only). > >> > >> Regards > >> Scott > >> > >> On 20/11/2009, at 9:06 AM, Scott Gray wrote: > >> > >>> Thanks for the pointer Christian, I figured > the ASF > >> would have something for us and they haven't > disappointed > >> :-) > >>> > >>> I'll keep playing around the different CI > services > >> locally for a little bit so I can learn how they > work a bit > >> better and also find the one that will be the most > useful to > >> us. > >>> > >>> Thanks > >>> Scott > >>> > >>> On 20/11/2009, at 1:08 AM, Christian Geisert > wrote: > >>> > Scott Gray schrieb: > > It took a while but all our JUnit > tests now > >> pass, next I'd like to get a continuous > integration server > >> set up. Can anybody recommend some tools > > Why not just use what is available at the > ASF ;-) > > http://ci.apache.org/ > > I use Hudson and like it, but I haven't > tried the > >> others... > > > Once that is done I'd like to have it > run the > >> tests after every commit and report any failures > to the dev > >> list. It would then be the offending > committer's > >> responsibility (well primarily at least) to fix > the problem > >> as soon as possible, much like a build > failure. If we > >> can't get everyone to agree to take on that > responsibility > >> then I might as well stop now because I'll be > damned if I'm > >> going to spend any more time fixing tests that I > didn't > >> break :-) > > +1 > > > All of this should help us increase > the > >> stability of the trunk and our confidence when > taking a > >> checkout that we won't half to spend our > development time > >> fixing things that used to work. It'll > hopefully also > >> encourage the community to contribute more tests > with the > >> knowledge that doing so will increase the > stability of the > >> functionality they depend on. Fix a bug and > you're > >> good for a day, write a test and you're good a > lifetime :-) > > Absolutly agreed, big thanks for your (and > all the > >> others) work in this area! > > --Christian > > >>> > >> > >> > > > > > > > >
Re: buildbot failure in ASF Buildbot on ofbiz-trunk
I did actually expect the build to fail, Jacopo committed some data changes yesterday that the accounting tests depend on but I'll get them fixed up tonight. After that you're all on your own, you break it you fix it :-) Regards Scott HotWax Media http://www.hotwaxmedia.com On 24/11/2009, at 6:32 PM, build...@apache.org wrote: The Buildbot has detected a failed build of ofbiz-trunk on ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/1829 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: forced: by IRC user on channel #asftest: testing new config as requested in INFRA-2345 Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile_1 sincerely, -The Buildbot smime.p7s Description: S/MIME cryptographic signature
Re: All JUnit tests now pass! Next steps...
BTW, the accounting tests are failing at the moment but I'll have them fixed again shortly. Regards Scott On 24/11/2009, at 6:09 PM, Scott Gray wrote: Hi Adrian, Yeah that issue has been there for a while but you'll notice that the exception is just a logged exception and isn't actually thrown, hence no error and the test passes. Regards Scott On 24/11/2009, at 6:01 PM, Adrian Crum wrote: Scott, Are you sure all tests pass? I'm seeing errors in the entity engine test - testBlobCreate. I thought it might be caused by my recent Blob converter commit, so I reverted it locally. I still get the same error. Looking at the code causing the error (GenericEntity.java line 420) it appears to me this test never should have succeeded. -Adrian --- On Mon, 11/23/09, Scott Gray wrote: From: Scott Gray Subject: Re: All JUnit tests now pass! Next steps... To: dev@ofbiz.apache.org Date: Monday, November 23, 2009, 7:53 PM Quick update, I've since learnt that we've already had the trunk and 9.04 branch running on buildbot at the ASF for a few months now. I've created an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345) requesting that build notifications be sent to the dev list and also that the run-install and run-tests targets be added to the buildbot configuration (for the trunk only). Regards Scott On 20/11/2009, at 9:06 AM, Scott Gray wrote: Thanks for the pointer Christian, I figured the ASF would have something for us and they haven't disappointed :-) I'll keep playing around the different CI services locally for a little bit so I can learn how they work a bit better and also find the one that will be the most useful to us. Thanks Scott On 20/11/2009, at 1:08 AM, Christian Geisert wrote: Scott Gray schrieb: It took a while but all our JUnit tests now pass, next I'd like to get a continuous integration server set up. Can anybody recommend some tools Why not just use what is available at the ASF ;-) http://ci.apache.org/ I use Hudson and like it, but I haven't tried the others... Once that is done I'd like to have it run the tests after every commit and report any failures to the dev list. It would then be the offending committer's responsibility (well primarily at least) to fix the problem as soon as possible, much like a build failure. If we can't get everyone to agree to take on that responsibility then I might as well stop now because I'll be damned if I'm going to spend any more time fixing tests that I didn't break :-) +1 All of this should help us increase the stability of the trunk and our confidence when taking a checkout that we won't half to spend our development time fixing things that used to work. It'll hopefully also encourage the community to contribute more tests with the knowledge that doing so will increase the stability of the functionality they depend on. Fix a bug and you're good for a day, write a test and you're good a lifetime :-) Absolutly agreed, big thanks for your (and all the others) work in this area! --Christian smime.p7s Description: S/MIME cryptographic signature
Re: All JUnit tests now pass! Next steps...
Hi Adrian, Yeah that issue has been there for a while but you'll notice that the exception is just a logged exception and isn't actually thrown, hence no error and the test passes. Regards Scott On 24/11/2009, at 6:01 PM, Adrian Crum wrote: Scott, Are you sure all tests pass? I'm seeing errors in the entity engine test - testBlobCreate. I thought it might be caused by my recent Blob converter commit, so I reverted it locally. I still get the same error. Looking at the code causing the error (GenericEntity.java line 420) it appears to me this test never should have succeeded. -Adrian --- On Mon, 11/23/09, Scott Gray wrote: From: Scott Gray Subject: Re: All JUnit tests now pass! Next steps... To: dev@ofbiz.apache.org Date: Monday, November 23, 2009, 7:53 PM Quick update, I've since learnt that we've already had the trunk and 9.04 branch running on buildbot at the ASF for a few months now. I've created an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345) requesting that build notifications be sent to the dev list and also that the run-install and run-tests targets be added to the buildbot configuration (for the trunk only). Regards Scott On 20/11/2009, at 9:06 AM, Scott Gray wrote: Thanks for the pointer Christian, I figured the ASF would have something for us and they haven't disappointed :-) I'll keep playing around the different CI services locally for a little bit so I can learn how they work a bit better and also find the one that will be the most useful to us. Thanks Scott On 20/11/2009, at 1:08 AM, Christian Geisert wrote: Scott Gray schrieb: It took a while but all our JUnit tests now pass, next I'd like to get a continuous integration server set up. Can anybody recommend some tools Why not just use what is available at the ASF ;-) http://ci.apache.org/ I use Hudson and like it, but I haven't tried the others... Once that is done I'd like to have it run the tests after every commit and report any failures to the dev list. It would then be the offending committer's responsibility (well primarily at least) to fix the problem as soon as possible, much like a build failure. If we can't get everyone to agree to take on that responsibility then I might as well stop now because I'll be damned if I'm going to spend any more time fixing tests that I didn't break :-) +1 All of this should help us increase the stability of the trunk and our confidence when taking a checkout that we won't half to spend our development time fixing things that used to work. It'll hopefully also encourage the community to contribute more tests with the knowledge that doing so will increase the stability of the functionality they depend on. Fix a bug and you're good for a day, write a test and you're good a lifetime :-) Absolutly agreed, big thanks for your (and all the others) work in this area! --Christian smime.p7s Description: S/MIME cryptographic signature
Re: All JUnit tests now pass! Next steps...
Scott, Are you sure all tests pass? I'm seeing errors in the entity engine test - testBlobCreate. I thought it might be caused by my recent Blob converter commit, so I reverted it locally. I still get the same error. Looking at the code causing the error (GenericEntity.java line 420) it appears to me this test never should have succeeded. -Adrian --- On Mon, 11/23/09, Scott Gray wrote: > From: Scott Gray > Subject: Re: All JUnit tests now pass! Next steps... > To: dev@ofbiz.apache.org > Date: Monday, November 23, 2009, 7:53 PM > Quick update, I've since learnt that > we've already had the trunk and 9.04 branch running on > buildbot at the ASF for a few months now. I've created > an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345) > requesting that build notifications be sent to the dev list > and also that the run-install and run-tests targets be added > to the buildbot configuration (for the trunk only). > > Regards > Scott > > On 20/11/2009, at 9:06 AM, Scott Gray wrote: > > > Thanks for the pointer Christian, I figured the ASF > would have something for us and they haven't disappointed > :-) > > > > I'll keep playing around the different CI services > locally for a little bit so I can learn how they work a bit > better and also find the one that will be the most useful to > us. > > > > Thanks > > Scott > > > > On 20/11/2009, at 1:08 AM, Christian Geisert wrote: > > > >> Scott Gray schrieb: > >>> It took a while but all our JUnit tests now > pass, next I'd like to get a continuous integration server > set up. Can anybody recommend some tools > >> > >> Why not just use what is available at the ASF ;-) > >> > >> http://ci.apache.org/ > >> > >> I use Hudson and like it, but I haven't tried the > others... > >> > >>> Once that is done I'd like to have it run the > tests after every commit and report any failures to the dev > list. It would then be the offending committer's > responsibility (well primarily at least) to fix the problem > as soon as possible, much like a build failure. If we > can't get everyone to agree to take on that responsibility > then I might as well stop now because I'll be damned if I'm > going to spend any more time fixing tests that I didn't > break :-) > >> > >> +1 > >> > >>> All of this should help us increase the > stability of the trunk and our confidence when taking a > checkout that we won't half to spend our development time > fixing things that used to work. It'll hopefully also > encourage the community to contribute more tests with the > knowledge that doing so will increase the stability of the > functionality they depend on. Fix a bug and you're > good for a day, write a test and you're good a lifetime :-) > >> > >> Absolutly agreed, big thanks for your (and all the > others) work in this area! > >> > >> --Christian > >> > > > >
UtilCache fileStore
UtilCache uses CacheLineTable, and passes a per-instance fileStore. However, CacheLineTable uses a *static* jdbm storage manager. So the first time a CacheLineTable is created that needs to be stored on disk, the manager will be created with that instance's fileStore location. Now all subsequent CacheLineTables will use the previous fileStore. Does anyone else agree with my reading of this code?
buildbot failure in ASF Buildbot on ofbiz-trunk
The Buildbot has detected a failed build of ofbiz-trunk on ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/1829 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: forced: by IRC user on channel #asftest: testing new config as requested in INFRA-2345 Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[jira] Commented: (OFBIZ-2619) Issues with Receive PO functionality
[ https://issues.apache.org/jira/browse/OFBIZ-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781774#action_12781774 ] Ashish Vijaywargiya commented on OFBIZ-2619: Will do it today, Mridul. Thanks for your comment. -- Ashish > Issues with Receive PO functionality > > > Key: OFBIZ-2619 > URL: https://issues.apache.org/jira/browse/OFBIZ-2619 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Mridul Pathak >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBiz-2619.patch, OFBiz-2619.patch, OFBiz-2619.patch > > > Following are the issues that I came across while going through different > scenarios of receiving PO: > # Create a shipment and receive it from Facility > Shipment > Receive Against > PO (This scenario works correctly) > ## Before receiving shipment: > OrderItem.quantity = 10 > ## Receiving half if the ordered quantity - New ShipmentItem record created. > New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## Receiving remaining quantity but receiving some extra quantity too - > ShipmentItem record updated. New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 7 > ShipmentItem.quantity = 12 (5 + 7) > ItemIssuance.quantity = 7 > Total ItemIssuance.quantity = 12 (5 + 7) > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Shipment > Receive Against PO > ## Before Issuing Order Items - No ShipmentItem or ItemIssuance record > OrderItem.quantity = 5 > ## After Issuing Order Items - ShipmentItem created, ItemIssuance created. > OrderItem.quantity = 5 > Issued quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## On receiving shipment - ShipmentItem updated, new ItemIssuance created > OrderItem.quantity = 5 > Received quantity = 5 > ShipmentItem.quantity = 10 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 10 (5 + 5) > This seems to be a weird behavior. When I have already issued the item in > #b, then on receiving the shipment for the same orderItem quantity in #c, the > ShipmentItem shouldn't be updated and new item issuance shouldn't be created > (creating new item issuance means that I am re-issuing the items). > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Facilities > Receive Inventory by > selecting PO and the respective newly created shipment. > If I issue the same (or more) quantity as ordered for the Order Item and then > receive the exact amount that has been issued (in one or more steps) this > scenario works fine. in following scenarios there is no change in > ShipmentItem and ItemIssuance, which causes conflicts: > ## I issue same quantity as ordered for the Order Item but while receiving > receive more than the issued ordered quantity. > ## I issue same quantity as ordered for the Order Item. While receiving, > receive less first time. Go back to same screen again. Receive more than > the remaining ordered quantity. > ## I issue less quantity than ordered for the Order Item but receive more > than the issued order item quantity. > # Quick Receive Purchase Order > If I Quick Receive Purchase Order from Order Detail page, Shipment is created > and all the Order Items are issued and I am taken to the Receive Inventory > screen directly. If I receive exactly the same amount as ordered for each > order item (at one go, or receiving it in parts) functionality works fine. > But following are the scenarios which breaks everything. > ## Same as #3-a and #3-b. > ## If I receive less quantity than the quantity ordered for order item, and > receive remaining (or more) ordered quantity from Facility > Shipment > > Receive against PO then same issue as reported in #2 occurs. > Note: For testing these issues, comment out eca action > updatePoOnReceiveInventory at line no. 55 in order/servicedef/secas.xml. > This service was recently added in revision 757749, but it only covers #3-a > and #3-c below partially and its logic needs to be rewritten. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3241) Cancel Payment Batch - Need to correct error message.
[ https://issues.apache.org/jira/browse/OFBIZ-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-3241: -- Assignee: Ashish Vijaywargiya > Cancel Payment Batch - Need to correct error message. > - > > Key: OFBIZ-3241 > URL: https://issues.apache.org/jira/browse/OFBIZ-3241 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3241.patch > > > At https://demo.ofbiz.org/ar/control/FindArPaymentGroups > When try to cancel a payment batch which is associated to active > reconciliation. Then it is showing success message that "Action is performed > successfully", instead of this, it must show error message which inform user > that Payment batch associated to Reconciliation can not be canceled. It is > needed to show right message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3238) FinAccount Reconciliation Search Result Table - Add new column for Cancel Reconciliation.
[ https://issues.apache.org/jira/browse/OFBIZ-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-3238: -- Assignee: Ashish Vijaywargiya > FinAccount Reconciliation Search Result Table - Add new column for Cancel > Reconciliation. > - > > Key: OFBIZ-3238 > URL: https://issues.apache.org/jira/browse/OFBIZ-3238 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ_3238.patch > > > At > https://localhost:8443/accounting/control/FindFinAccountReconciliations?finAccountId=SC_CHECKING > In search results, add a column to "Cancel Reconciliation" In this column > show "Cancel" button to cancel reconciliations which are in CREATED status. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3242) Add new feature to Bulk Print Invoices.
[ https://issues.apache.org/jira/browse/OFBIZ-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-3242: -- Assignee: Ashish Vijaywargiya > Add new feature to Bulk Print Invoices. > --- > > Key: OFBIZ-3242 > URL: https://issues.apache.org/jira/browse/OFBIZ-3242 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya > Fix For: SVN trunk > > Attachments: OFBIZ-3242.patch > > > It Applies to findInvoices screen in AR and AP. User selects items from > findInvoice search results. Selects Print action and clicks on Run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3236) Add new field - Closing balance to Reconciliation Screen
[ https://issues.apache.org/jira/browse/OFBIZ-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-3236: -- Assignee: Ashish Vijaywargiya > Add new field - Closing balance to Reconciliation Screen > > > Key: OFBIZ-3236 > URL: https://issues.apache.org/jira/browse/OFBIZ-3236 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Reporter: Sumit Pandit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3236.patch > > > At > https://localhost:8443/accounting/control/ViewGlReconciliationWithTransaction?glReconciliationId=9000&finAccountId=SC_CHECKING > - Add a new field to represent Closing balance of Reconciliation. This will > sum of Opening Balance(default 0) + Reconciled Balance (default 0). > - Also rearrange rows showing information. It is as follows - > -- OLD : > Gl Reconciliation Name > Reconciled Balance > Status > Reconciled Date > Opening Balance > -- NEW : > Gl Reconciliation Name > Status > Reconciled Date > Opening Balance > Reconciled Balance > Closing Balance -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: All JUnit tests now pass! Next steps...
Awesome Scott - thanks. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Nov 23, 2009, at 8:53 PM, Scott Gray wrote: Quick update, I've since learnt that we've already had the trunk and 9.04 branch running on buildbot at the ASF for a few months now. I've created an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345 ) requesting that build notifications be sent to the dev list and also that the run-install and run-tests targets be added to the buildbot configuration (for the trunk only). Regards Scott On 20/11/2009, at 9:06 AM, Scott Gray wrote: Thanks for the pointer Christian, I figured the ASF would have something for us and they haven't disappointed :-) I'll keep playing around the different CI services locally for a little bit so I can learn how they work a bit better and also find the one that will be the most useful to us. Thanks Scott On 20/11/2009, at 1:08 AM, Christian Geisert wrote: Scott Gray schrieb: It took a while but all our JUnit tests now pass, next I'd like to get a continuous integration server set up. Can anybody recommend some tools Why not just use what is available at the ASF ;-) http://ci.apache.org/ I use Hudson and like it, but I haven't tried the others... Once that is done I'd like to have it run the tests after every commit and report any failures to the dev list. It would then be the offending committer's responsibility (well primarily at least) to fix the problem as soon as possible, much like a build failure. If we can't get everyone to agree to take on that responsibility then I might as well stop now because I'll be damned if I'm going to spend any more time fixing tests that I didn't break :-) +1 All of this should help us increase the stability of the trunk and our confidence when taking a checkout that we won't half to spend our development time fixing things that used to work. It'll hopefully also encourage the community to contribute more tests with the knowledge that doing so will increase the stability of the functionality they depend on. Fix a bug and you're good for a day, write a test and you're good a lifetime :-) Absolutly agreed, big thanks for your (and all the others) work in this area! -- Christian smime.p7s Description: S/MIME cryptographic signature
Re: All JUnit tests now pass! Next steps...
Quick update, I've since learnt that we've already had the trunk and 9.04 branch running on buildbot at the ASF for a few months now. I've created an infra ticket (https://issues.apache.org/jira/browse/INFRA-2345 ) requesting that build notifications be sent to the dev list and also that the run-install and run-tests targets be added to the buildbot configuration (for the trunk only). Regards Scott On 20/11/2009, at 9:06 AM, Scott Gray wrote: Thanks for the pointer Christian, I figured the ASF would have something for us and they haven't disappointed :-) I'll keep playing around the different CI services locally for a little bit so I can learn how they work a bit better and also find the one that will be the most useful to us. Thanks Scott On 20/11/2009, at 1:08 AM, Christian Geisert wrote: Scott Gray schrieb: It took a while but all our JUnit tests now pass, next I'd like to get a continuous integration server set up. Can anybody recommend some tools Why not just use what is available at the ASF ;-) http://ci.apache.org/ I use Hudson and like it, but I haven't tried the others... Once that is done I'd like to have it run the tests after every commit and report any failures to the dev list. It would then be the offending committer's responsibility (well primarily at least) to fix the problem as soon as possible, much like a build failure. If we can't get everyone to agree to take on that responsibility then I might as well stop now because I'll be damned if I'm going to spend any more time fixing tests that I didn't break :-) +1 All of this should help us increase the stability of the trunk and our confidence when taking a checkout that we won't half to spend our development time fixing things that used to work. It'll hopefully also encourage the community to contribute more tests with the knowledge that doing so will increase the stability of the functionality they depend on. Fix a bug and you're good for a day, write a test and you're good a lifetime :-) Absolutly agreed, big thanks for your (and all the others) work in this area! -- Christian smime.p7s Description: S/MIME cryptographic signature
Adding services to handle InventoryItemAttribute
Hi, It seems there is no service to handle the entity "InventoryItemAttribute" like there are for "ProductAttribute". Here is the missing code : applications/product/servicedef/services_facility.xml Create a InventoryItemAttribute Update a InventoryItemAttribute Delete a InventoryItemAttribute applications/product/script/org/ofbiz/product/inventory/InventoryServices.xml I know it would be better with a test class and a patch. Maybe the next time... :-) Cimballi
[jira] Commented: (OFBIZ-2347) BIRT Component
[ https://issues.apache.org/jira/browse/OFBIZ-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781739#action_12781739 ] WeizhanGuo commented on OFBIZ-2347: --- Thank you for your good job. I found a problem when render report using BirtViewHandler. The BirtViewHandler works well when export report as pdf or word, but the chart can't display if the content-type is text/html. Have you met this problem? > BIRT Component > -- > > Key: OFBIZ-2347 > URL: https://issues.apache.org/jira/browse/OFBIZ-2347 > Project: OFBiz > Issue Type: New Feature >Affects Versions: SVN trunk > Environment: software >Reporter: Chatree Srichart >Assignee: Hans Bakker > Fix For: SVN trunk > > Attachments: birt.zip, birtfiles.txt > > > I have component for use Eclipse BIRT as report builder. > Features: > 1. BIRT View Handler > 2. BIRT Email Service > I hope contributers contribute it to trunk. > INSTALLATION > 1. download birt.zip from attachment file > 2. extract birt.zip > 3. copy birt folder to hot-deploy folder > 4. download Eclipse BIRT runtime from > http://download.eclipse.org/birt/downloads/ > 5. extract birt-runtime-x_x_x.zip > 6. copy all jar file from birt-runtime-x_x_x/ReportEngine/lib folder to > hot-deploy/birt/lib folder > 7. change birt.engine.home property in hot-deploy/birt/config/birt.properties > to your ReportEngine path in birt-runtime_x_x_x folder > 8. add birt-container in ofbiz-container.xml file after beanshell-container > container like this > class="org.ofbiz.birt.container.BirtContainer"> > > > > > 9. compile birt component > 10. start ofbiz > ** I have use birt-runtime version 2.3.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Vaadin integration
I had looked at it. Vaadin seems very capable and mature. The issue is that GWT 2.0 is far far more advanced than GWT 1.7. GWT 2.0 is in RC1 and is stable/released. Vaadin is beautiful, Apache license but not 2.0 based from what i understand. At the present moment the best things to integrate IMHO are GWT and GWT Incubator. Harmeet Manuel Desdin wrote: hi, anybody out there by chance interested in integrating vaadin into ofbiz? http://vaadin.com/ http://vaadin.com/features it uses google gwt on the client side regards, manuel.
Re: svn commit: r835270 - in /ofbiz/trunk: applications/marketing/ applications/marketing/config/ applications/marketing/data/ applications/marketing/src/org/ofbiz/sfa/vcard/ applications/marketing/we
Hi Hans
Could you explain the reason for changing the decorator-screen name
from main-decorator to CommonPartyDecorator for the ManagePortalPages
screen in your commit below? I would like to change it back so that
other apps can use the screen without requiring the
CommonPartyDecorator and I see no adverse effects in SFA by doing so
but I prefer to check with you first.
Thanks
Scott
HotWax Media
http://www.hotwaxmedia.com
On 12/11/2009, at 8:04 PM, hans...@apache.org wrote:
Author: hansbak
Date: Thu Nov 12 07:04:41 2009
New Revision: 835270
URL: http://svn.apache.org/viewvc?rev=835270&view=rev
Log:
add a portal page as the first page in sfa containing calendar and
email, but can be changed as required via preferences. add the first
screens for events which will appear on the calendar. next step will
be to be able to connect events/tasks to opportunities, show them in
the party pprofile etc...
Added:
ofbiz/trunk/applications/marketing/data/SfaPortletData.xml
(with props)
ofbiz/trunk/applications/marketing/widget/sfa/EventScreens.xml
(with props)
ofbiz/trunk/applications/marketing/widget/sfa/forms/
EventForms.xml (with props)
Modified:
ofbiz/trunk/applications/marketing/config/MarketingUiLabels.xml
ofbiz/trunk/applications/marketing/ofbiz-component.xml
ofbiz/trunk/applications/marketing/src/org/ofbiz/sfa/vcard/
VCard.java
ofbiz/trunk/applications/marketing/webapp/sfa/WEB-INF/
controller.xml
ofbiz/trunk/applications/marketing/widget/sfa/AccountScreens.xml
ofbiz/trunk/applications/marketing/widget/sfa/CommonScreens.xml
ofbiz/trunk/applications/marketing/widget/sfa/SfaMenus.xml
ofbiz/trunk/applications/workeffort/script/org/ofbiz/workeffort/
workeffort/WorkEffortSimpleServices.xml
ofbiz/trunk/framework/common/widget/PortalPageScreens.xml
[snip]
Modified: ofbiz/trunk/framework/common/widget/PortalPageScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/PortalPageScreens.xml?rev=835270&r1=835269&r2=835270&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/framework/common/widget/PortalPageScreens.xml
(original)
+++ ofbiz/trunk/framework/common/widget/PortalPageScreens.xml Thu
Nov 12 07:04:41 2009
@@ -103,7 +103,7 @@
-
+location="${parameters.mainDecoratorLocation}">
location="component://common/widget/PortalPageForms.xml"/>
smime.p7s
Description: S/MIME cryptographic signature
[jira] Reopened: (OFBIZ-3240) Catalog menu not visible
[ https://issues.apache.org/jira/browse/OFBIZ-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reopened OFBIZ-3240: Sorry Bruno, But this is still true > Catalog menu not visible > > > Key: OFBIZ-3240 > URL: https://issues.apache.org/jira/browse/OFBIZ-3240 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: SVN trunk >Reporter: Jacques Le Roux >Assignee: Bruno Busco >Priority: Trivial > Attachments: Menu not visible.jpg > > > See screen-copy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781684#action_12781684 ] Adrian Crum commented on OFBIZ-3245: Erwan, The exception you reported was expected, because no Blob converters were developed. It should work with rev 883529. What database did you use? > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jdk 1.5 or 1.6
There are some API things that are better in 1.6, and not compatible with the 1.5 API, but they all seem to have some sort of work around. For some of those things we'll get better performance and maybe better flexibility (and maybe less code to maintain) if we use the 1.6 API. IMO the biggest reason to require 1.6 is that some of the libraries we use are starting to require 1.6 for their newer versions, and chances are that will happen more over time. In other words, sooner or later we'll want to update something and they won't offer a 1.5 compatible alternative any more. -David On Nov 23, 2009, at 2:16 PM, Scott Gray wrote: > I'm not necessarily against it but I'm yet to hear what we actually gain by > doing so, what are these changes that we could optionally make once we stop > supporting 1.5? With the change from 1.4 to 1.5 it was pretty clear because > of things like generics. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 24/11/2009, at 9:49 AM, David E Jones wrote: > >> >> OFBiz already runs fine on 1.6, so this would just be a matter of updating >> documentation and such, and then people could optionally make changes that >> require 1.6. >> >> If everyone is in favour of this, we might as well get a vote going... >> >> -David >> >> >> On Nov 23, 2009, at 11:20 AM, Erwan de FERRIERES wrote: >> >>> +1 >>> >>> Furthermore, on a debian lenny server, there is no jdk 1.5 in the >>> repository... >>> >>> So, in order to make this migration, what are the required steps ? How can >>> we divide the work to be done ? >>> >>> Cheers >>> >>> Le 14/11/2009 05:44, Tim Ruppert a écrit : >>> ../.. >>> >>> -- >>> Erwan >> >
Re: jdk 1.5 or 1.6
On 24/11/2009, at 11:19 AM, Matthieu Bollot wrote: Le lundi 23 novembre 2009 à 15:32 -0600, Adam Heath a écrit : Scott Gray wrote: I'm not necessarily against it but I'm yet to hear what we actually gain by doing so, what are these changes that we could optionally make once we stop supporting 1.5? With the change from 1.4 to 1.5 it was pretty clear because of things like generics. NavigablMap, which is implemented by ConcurrentSkipListMap, which provides for sorted concurrent maps. I use java 1.6, it could explain why I still have some errors while running junit tests. May be someone to tell me if I'm wrong ? Thanks for reporting, I'll look into it as soon as I get a chance. Regards Scott smime.p7s Description: S/MIME cryptographic signature
[jira] Closed: (OFBIZ-3151) fix for using "equals" operator with null field in performFind service.
[ https://issues.apache.org/jira/browse/OFBIZ-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Bakker closed OFBIZ-3151. -- Resolution: Fixed Thanks for your contribution, Committed revision 883525. > fix for using "equals" operator with null field in performFind service. > --- > > Key: OFBIZ-3151 > URL: https://issues.apache.org/jira/browse/OFBIZ-3151 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Chatree Srichart > Fix For: SVN trunk > > Attachments: FindServices.java.diff > > > Because I can not use "equals" operator with null field in performFind > service. So I fixed for use one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jdk 1.5 or 1.6
Le lundi 23 novembre 2009 à 15:32 -0600, Adam Heath a écrit : > Scott Gray wrote: > > I'm not necessarily against it but I'm yet to hear what we actually gain > > by doing so, what are these changes that we could optionally make once > > we stop supporting 1.5? With the change from 1.4 to 1.5 it was pretty > > clear because of things like generics. > > NavigablMap, which is implemented by ConcurrentSkipListMap, which > provides for sorted concurrent maps. I use java 1.6, it could explain why I still have some errors while running junit tests. May be someone to tell me if I'm wrong ?
[jira] Closed: (OFBIZ-770) Use UtilValidate.is(Not)Empty methods instead of repeated (obj == null) || (obj.size == 0)
[ https://issues.apache.org/jira/browse/OFBIZ-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-770. - Resolution: Fixed Assignee: Jacques Le Roux Should be fixed at r883492 > Use UtilValidate.is(Not)Empty methods instead of repeated (obj == null) || > (obj.size == 0) > -- > > Key: OFBIZ-770 > URL: https://issues.apache.org/jira/browse/OFBIZ-770 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Stefan Huehner >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: SVN trunk > > Attachments: ofbiz-770-FindFacilityPhysicalInventory.bsh.patch, > ofbiz_isEmpty1.diff, ofbiz_isEmpty2.diff > > > Hi, > this task is to keep track of the conversion of hardcoded isEmpty checks to > the existing UtilValidate methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jdk 1.5 or 1.6
Scott Gray wrote: > I'm not necessarily against it but I'm yet to hear what we actually gain > by doing so, what are these changes that we could optionally make once > we stop supporting 1.5? With the change from 1.4 to 1.5 it was pretty > clear because of things like generics. NavigablMap, which is implemented by ConcurrentSkipListMap, which provides for sorted concurrent maps.
Re: jdk 1.5 or 1.6
Optional changes would include the code contained in UtilProperties.java. Java 6 improves support for extending ResourceBundle. Some of the code in there mimics Java 6 classes, so the change would be straightforward. -Adrian Scott Gray wrote: I'm not necessarily against it but I'm yet to hear what we actually gain by doing so, what are these changes that we could optionally make once we stop supporting 1.5? With the change from 1.4 to 1.5 it was pretty clear because of things like generics. Regards Scott HotWax Media http://www.hotwaxmedia.com On 24/11/2009, at 9:49 AM, David E Jones wrote: OFBiz already runs fine on 1.6, so this would just be a matter of updating documentation and such, and then people could optionally make changes that require 1.6. If everyone is in favour of this, we might as well get a vote going... -David On Nov 23, 2009, at 11:20 AM, Erwan de FERRIERES wrote: +1 Furthermore, on a debian lenny server, there is no jdk 1.5 in the repository... So, in order to make this migration, what are the required steps ? How can we divide the work to be done ? Cheers Le 14/11/2009 05:44, Tim Ruppert a écrit : ../.. -- Erwan
[jira] Closed: (OFBIZ-2947) The 1st time you close a project you get an error, it works the 2d time
[ https://issues.apache.org/jira/browse/OFBIZ-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-2947. -- Resolution: Fixed Fix Version/s: (was: Release Branch 9.04) I can't reproduce this error in trunk and it's not possible in R9.04 because you get another error message (not a bug) before, I gave up on R9.04 > The 1st time you close a project you get an error, it works the 2d time > --- > > Key: OFBIZ-2947 > URL: https://issues.apache.org/jira/browse/OFBIZ-2947 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/projectmgr >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > > ERROR: Could not complete the Update Work Effort > [file:/D:/workspace/ofbizRun/applications/workeffort/script/org/ofbiz/workeffort/workeffort/WorkEffortSimpleServices.xml#updateWorkEffort] > process [problem creating the newWorkEffortStatus value: Error while > inserting: [GenericEntity:WorkEffortStatus][createdStamp,2009-09-16 > 15:10:35.548(java.sql.Timestamp)][createdTxStamp,2009-09-16 > 15:10:35.501(java.sql.Timestamp)][lastUpdatedStamp,2009-09-16 > 15:10:35.548(java.sql.Timestamp)][lastUpdatedTxStamp,2009-09-16 > 15:10:35.501(java.sql.Timestamp)][setByUserLogin,admin(java.lang.String)][statusDatetime,2009-09-16 > 15:10:35.548(java.sql.Timestamp)][statusId,PRJ_CLOSED(java.lang.String)] > (SQL Exception while executing the following:INSERT INTO > public.WORK_EFFORT_STATUS (WORK_EFFORT_ID, STATUS_ID, STATUS_DATETIME, > SET_BY_USER_LOGIN, REASON, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, > CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) (ERREUR: > une valeur NULL viole la contrainte NOT NULL de la colonne « work_effort_id > »))] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jdk 1.5 or 1.6
I'm not necessarily against it but I'm yet to hear what we actually gain by doing so, what are these changes that we could optionally make once we stop supporting 1.5? With the change from 1.4 to 1.5 it was pretty clear because of things like generics. Regards Scott HotWax Media http://www.hotwaxmedia.com On 24/11/2009, at 9:49 AM, David E Jones wrote: OFBiz already runs fine on 1.6, so this would just be a matter of updating documentation and such, and then people could optionally make changes that require 1.6. If everyone is in favour of this, we might as well get a vote going... -David On Nov 23, 2009, at 11:20 AM, Erwan de FERRIERES wrote: +1 Furthermore, on a debian lenny server, there is no jdk 1.5 in the repository... So, in order to make this migration, what are the required steps ? How can we divide the work to be done ? Cheers Le 14/11/2009 05:44, Tim Ruppert a écrit : ../.. -- Erwan smime.p7s Description: S/MIME cryptographic signature
Re: jdk 1.5 or 1.6
OFBiz already runs fine on 1.6, so this would just be a matter of updating documentation and such, and then people could optionally make changes that require 1.6. If everyone is in favour of this, we might as well get a vote going... -David On Nov 23, 2009, at 11:20 AM, Erwan de FERRIERES wrote: > +1 > > Furthermore, on a debian lenny server, there is no jdk 1.5 in the > repository... > > So, in order to make this migration, what are the required steps ? How can we > divide the work to be done ? > > Cheers > > Le 14/11/2009 05:44, Tim Ruppert a écrit : > ../.. > > -- > Erwan
Vaadin integration
hi, anybody out there by chance interested in integrating vaadin into ofbiz? http://vaadin.com/ http://vaadin.com/features it uses google gwt on the client side regards, manuel. smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (OFBIZ-3253) possible bug with adding an item to an order that has a canceled item
[ https://issues.apache.org/jira/browse/OFBIZ-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Mayo updated OFBIZ-3253: --- Affects Version/s: Release Branch 9.04 > possible bug with adding an item to an order that has a canceled item > - > > Key: OFBIZ-3253 > URL: https://issues.apache.org/jira/browse/OFBIZ-3253 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 4.0, Release Branch 9.04 >Reporter: Albert Mayo > > 1. I created an order with GZ-1000 and GZ-1004. > 2. I canceled the GZ-1004 item. > 3. I added GZ-1001 to the order. > Instead of putting GZ-1001 as a new line item, it looks like GZ-1001 replaces > the GZ-1004 line item. > I say it is a possible bug because I do not know if this is the functional > intent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3253) possible bug with adding an item to an order that has a canceled item
[ https://issues.apache.org/jira/browse/OFBIZ-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781600#action_12781600 ] Albert Mayo commented on OFBIZ-3253: I just tried the test outlined above on the public 9.04 DEMO OFBiz and had the same results. It looks like the error only happens when the last item is canceled. > possible bug with adding an item to an order that has a canceled item > - > > Key: OFBIZ-3253 > URL: https://issues.apache.org/jira/browse/OFBIZ-3253 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 4.0 >Reporter: Albert Mayo > > 1. I created an order with GZ-1000 and GZ-1004. > 2. I canceled the GZ-1004 item. > 3. I added GZ-1001 to the order. > Instead of putting GZ-1001 as a new line item, it looks like GZ-1001 replaces > the GZ-1004 line item. > I say it is a possible bug because I do not know if this is the functional > intent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Q - FinAccounting Reconciliation Issue
Hi All, I have a question about Financial Account Reconciliation process. Currently In Fin Account Reconciliation, more then one FinAccount's transaction can associate to one Reconciliation. Please verify that is it correct according to business process? There should be one to one relationship in FinAccount and Reconciliation. Explanation with example - Suppose - Fin Account ID : FA1 Fin Account Transaction for Fin Account Id FA1 - 1, 10001, 10002, 10003. Fin Account ID : FA2 Fin Account Transaction for Fin Account Id FA2 - 10004, 10005, 10006, 10007. Reconciliation Id : REC1, REC2 Current Implementation - REC1 can associate to 1, 10001, 10004, 10005 Conclusion - One reconciliation can associate to more then on FinAccount's transaction. Please suggest that, Is above process correct? Can one reconciliation contains more then one FinAccount's transactions? -- Thanks and Regards Sumit Pandit
[jira] Commented: (OFBIZ-3126) quantities incorrect when canceling partially shipped items
[ https://issues.apache.org/jira/browse/OFBIZ-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781592#action_12781592 ] Adrian Crum commented on OFBIZ-3126: Albert, We appreciate your help, but a patch that references a different repository will be unusable. It would help us if you could check out the R 4.0 version, copy your modified file(s) over to it, and then create a patch. > quantities incorrect when canceling partially shipped items > > > Key: OFBIZ-3126 > URL: https://issues.apache.org/jira/browse/OFBIZ-3126 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Si Chen > Fix For: Release Branch 9.04, SVN trunk > > Attachments: cancel quantitys 4.0.patch, jira-3126.patch, Picture > 9.png > > > if you create a sales order for quantity 5 of a product, and then partially > pack and ship 2 of this item, then go back and cancel all the item, the > quantity canceled its 5 but should be 3 because 2 had already been shipped. > See enclosed screenshot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3126) quantities incorrect when canceling partially shipped items
[ https://issues.apache.org/jira/browse/OFBIZ-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Mayo updated OFBIZ-3126: --- Attachment: cancel quantitys 4.0.patch I cannot officially contribute, but hopefully the attached patch helps whoever takes it on. The patch is from my own local SVN repository so ignore the revision numbers, but the modifications were done on an OFBiz 4.0 release. > quantities incorrect when canceling partially shipped items > > > Key: OFBIZ-3126 > URL: https://issues.apache.org/jira/browse/OFBIZ-3126 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Si Chen > Fix For: Release Branch 9.04, SVN trunk > > Attachments: cancel quantitys 4.0.patch, jira-3126.patch, Picture > 9.png > > > if you create a sales order for quantity 5 of a product, and then partially > pack and ship 2 of this item, then go back and cancel all the item, the > quantity canceled its 5 but should be 3 because 2 had already been shipped. > See enclosed screenshot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3126) quantities incorrect when canceling partially shipped items
[ https://issues.apache.org/jira/browse/OFBIZ-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781573#action_12781573 ] Albert Mayo commented on OFBIZ-3126: By the way, I believe I had this same issue in release 4.0. > quantities incorrect when canceling partially shipped items > > > Key: OFBIZ-3126 > URL: https://issues.apache.org/jira/browse/OFBIZ-3126 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Si Chen > Fix For: Release Branch 9.04, SVN trunk > > Attachments: jira-3126.patch, Picture 9.png > > > if you create a sales order for quantity 5 of a product, and then partially > pack and ship 2 of this item, then go back and cancel all the item, the > quantity canceled its 5 but should be 3 because 2 had already been shipped. > See enclosed screenshot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3151) fix for using "equals" operator with null field in performFind service.
[ https://issues.apache.org/jira/browse/OFBIZ-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781574#action_12781574 ] Jacques Le Roux commented on OFBIZ-3151: Hi Chatree, Should we close ? > fix for using "equals" operator with null field in performFind service. > --- > > Key: OFBIZ-3151 > URL: https://issues.apache.org/jira/browse/OFBIZ-3151 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Chatree Srichart > Fix For: SVN trunk > > Attachments: FindServices.java.diff > > > Because I can not use "equals" operator with null field in performFind > service. So I fixed for use one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3253) possible bug with adding an item to an order that has a canceled item
[ https://issues.apache.org/jira/browse/OFBIZ-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781552#action_12781552 ] Albert Mayo commented on OFBIZ-3253: This happens because because the service "loadCartFromOrder" is called from the function "loadCartForUpdate". Inside the service loadCartFromOrder, the only items that are loaded into the cart are the "valid" order items with the function OrderReadHelper.getValidOrderItems, which exclude canceled items. When items are added and the makeOrderItems function is called, it will use the next item sequence number which could be the same number of the canceled item. > possible bug with adding an item to an order that has a canceled item > - > > Key: OFBIZ-3253 > URL: https://issues.apache.org/jira/browse/OFBIZ-3253 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 4.0 >Reporter: Albert Mayo > > 1. I created an order with GZ-1000 and GZ-1004. > 2. I canceled the GZ-1004 item. > 3. I added GZ-1001 to the order. > Instead of putting GZ-1001 as a new line item, it looks like GZ-1001 replaces > the GZ-1004 line item. > I say it is a possible bug because I do not know if this is the functional > intent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Q - What should happen with Canceled FinAccunt Reconciliation Ids.
Extending scope of discussion. On Nov 23, 2009, at 11:33 AM, Sumit Pandit wrote: > Hi All, I have a question for reconciliation process. > > In Financial Account Reconciliation, we have an option to cancel the > reconciliation if it is in not reconciled yet. As a result of cancel > reconciliation all FinAccountTrans associated to it are released and ready to > assign in new reconciliation. > My question is that - what should happen with canceled reconciliationids. > Are they allowed to take part again in reconciliation process like other > reconciliationid in created status. Or it should just expire and have no more > use? > Your views are much appreciated. > > -- > Thanks And Regards > Sumit Pandit
Q - What should happen with Canceled FinAccunt Reconciliation Ids.
Hi All, I have a question for reconciliation process. In Financial Account Reconciliation, we have an option to cancel the reconciliation if it is in not reconciled yet. As a result of cancel reconciliation all FinAccountTrans associated to it are released and ready to assign in new reconciliation. My question is that - what should happen with canceled reconciliationids. Are they allowed to take part again in reconciliation process like other reconciliationid in created status. Or it should just expire and have no more use? Your views are much appreciated. -- Thanks And Regards Sumit Pandit
Re: jdk 1.5 or 1.6
+1 Furthermore, on a debian lenny server, there is no jdk 1.5 in the repository... So, in order to make this migration, what are the required steps ? How can we divide the work to be done ? Cheers Le 14/11/2009 05:44, Tim Ruppert a écrit : ../.. -- Erwan
[jira] Closed: (OFBIZ-3251) PaymentOverview screen -FinAccountTransAssociatedWithPayment section
[ https://issues.apache.org/jira/browse/OFBIZ-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anil K Patel closed OFBIZ-3251. --- > PaymentOverview screen -FinAccountTransAssociatedWithPayment section > > > Key: OFBIZ-3251 > URL: https://issues.apache.org/jira/browse/OFBIZ-3251 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Aswath Satrasala >Assignee: Anil K Patel >Priority: Minor > Attachments: FinAccountTransAssociatedWithPayment.txt > > > Format the FinAccountTransAssociatedWithPayment section in the > PaymentOverview screen. > The section was extending outside the screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OFBIZ-3251) PaymentOverview screen -FinAccountTransAssociatedWithPayment section
[ https://issues.apache.org/jira/browse/OFBIZ-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anil K Patel resolved OFBIZ-3251. - Resolution: Fixed Patch applied to r883410. Thanks Aswath Satrasala for fix patch. > PaymentOverview screen -FinAccountTransAssociatedWithPayment section > > > Key: OFBIZ-3251 > URL: https://issues.apache.org/jira/browse/OFBIZ-3251 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Aswath Satrasala >Assignee: Anil K Patel >Priority: Minor > Attachments: FinAccountTransAssociatedWithPayment.txt > > > Format the FinAccountTransAssociatedWithPayment section in the > PaymentOverview screen. > The section was extending outside the screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r883291 - /ofbiz/trunk/.classpath
Jacques Le Roux wrote: > From: "Adam Heath" >> jler...@apache.org wrote: >>> Author: jleroux >>> Date: Mon Nov 23 09:33:12 2009 >>> New Revision: 883291 >>> >>> URL: http://svn.apache.org/viewvc?rev=883291&view=rev >>> Log: >>> A patch from Erwan de FERRIERES "add path to framework/sql in >>> classpath file" (https://issues.apache.org/jira/browse/OFBIZ-3231) - >>> OFBIZ-3231 >>> With the new framework/sql /* files, we should add the path in the >>> classpath file. If not added, we have errors in eclipse... >> >> You know, we should really write something to generate these files, >> based on build.xml. Maybe using xslt. > > Yes this seems to be a good suggestion, any takers (I'm not good at > xslt, to say the least) ? I've done evil stuff with xslt. I had a perl module, that had embedded xslt(inside a perl HERE doc), that read an xml config file, that then output another perl file, to be used at runtime. It basically compiled the xml config to a perl function. I've also written xslt that reads ofbiz-containers.xml, chain-reads ofbiz-component.xml, chain-reads entitymodel.xml, then after all that, outputs CREATE TABLE-like stmts for each found .
Re: Proposal for some changes to the fields of AcctgTrans/AcctgTransEntry
Hi Jacopo, These changes are good, +1. -- Thanks And Regards Sumit Pandit On Nov 23, 2009, at 6:44 AM, Anil Patel wrote: > Jacopo, > Thanks for thinking through this. Makes sense to me. > > Thanks and Regards > Anil Patel > HotWax Media Inc > http://www.hotwaxmedia.com > http://us.apachecon.com/c/acus2009/sponsors/sponsors > > On Nov 23, 2009, at 5:36 AM, Jacopo Cappellato wrote: > >> I would like to introduce the following changes to the entity definitions of >> AcctgTrans and AcctgTransEntry: >> >> 1) move the field AcctgTransEntry.currencyUomId to AcctgTrans.currencyUomId >> (but keeping the AcctgTransEntry.origCurrencyUomId as is now) >> 2) add the new field AcctgTrans.totalAmount: for a valid transaction the >> field (its absolute value) will have to match with absolute value of the sum >> of all credits (or debits); before a transaction it is posted, the system >> will check that AcctgTrans.totalAmount = sum of all credits >> (AcctgTransEntry) = sum of all debits (AcctgTransEntry) >> >> Main reasons for this: >> a) since the records in AcctgTrans actually represents the lines of a >> Journal, it makes sense to have in them all the fields required by journals >> (type/description of the transaction, date and amount) >> b) the user workflow will be improved: when the AcctgTrans is created >> (before the entries) the user already know the amount to be posted (and >> split into the different Ledgers) >> >> What do you think? >> >> Jacopo >> >
[jira] Created: (OFBIZ-3253) possible bug with adding an item to an order that has a canceled item
possible bug with adding an item to an order that has a canceled item - Key: OFBIZ-3253 URL: https://issues.apache.org/jira/browse/OFBIZ-3253 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Release Branch 4.0 Reporter: Albert Mayo 1. I created an order with GZ-1000 and GZ-1004. 2. I canceled the GZ-1004 item. 3. I added GZ-1001 to the order. Instead of putting GZ-1001 as a new line item, it looks like GZ-1001 replaces the GZ-1004 line item. I say it is a possible bug because I do not know if this is the functional intent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[
https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781470#action_12781470
]
Adrian Crum commented on OFBIZ-3245:
David,
I re-read your initial comment and you are correct - this change will affect
things from the API point of view. Actually, that was my original goal.
The Java type specified in the fieldtypes*.xml files must be a Java class that
the JDBC driver recognizes, otherwise an exception will be thrown. Let's say we
want to add a new Java object type to the framework - like the TimeDuration
that I'm trying get implemented. In the existing code, having something like
{code}
{code}
won't work because the JDBC driver doesn't know what to do with a TimeDuration
Java object type. Like you said, the TimeDuration object is passed to the JDBC
driver as-is, and the result is it blows up.
So, this change will make the entity engine more flexible, more adaptable.
Users will be able to introduce their own data types without having to change
entity engine Java code.
> Sandbox: Integrating The New Conversion Framework Into The Entity Engine
>
>
> Key: OFBIZ-3245
> URL: https://issues.apache.org/jira/browse/OFBIZ-3245
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Adrian Crum
>Assignee: Adrian Crum
>Priority: Minor
> Attachments: conversion.patch, conversion.patch
>
>
> This issue contains a patch intended for evaluation before it is committed.
> See comments for details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r883140 - in /ofbiz/trunk/applications: accounting/config/ accounting/script/org/ofbiz/accounting/ accounting/script/org/ofbiz/accounting/agreement/ accounting/servicedef/ accounting/w
From: "Bilgin Ibryam" Hi Jacques, could you tell me why it doesn't follow the best practice? Because you changed the name of an entity (AgreementWorkEffortAppl to AgreementWorkEffortApplic) you should provide a path to follow at http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration (how to use your migrating service, think about people in 2 years ;o) Thanks Jacques If it is about the info that should be put in http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration I did it with some delay, because yesterday I had difficulties accessing the page. If there is another reason, please indicate it, so I can fix that. Thanks Bilgin Jacques Le Roux wrote: Hi Bilgin, This does not follow best practices http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities Though, with the migrating service you provided, most is done :o) Thanks Jacques
[jira] Assigned: (OFBIZ-3251) PaymentOverview screen -FinAccountTransAssociatedWithPayment section
[ https://issues.apache.org/jira/browse/OFBIZ-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anil K Patel reassigned OFBIZ-3251: --- Assignee: Anil K Patel > PaymentOverview screen -FinAccountTransAssociatedWithPayment section > > > Key: OFBIZ-3251 > URL: https://issues.apache.org/jira/browse/OFBIZ-3251 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Aswath Satrasala >Assignee: Anil K Patel >Priority: Minor > Attachments: FinAccountTransAssociatedWithPayment.txt > > > Format the FinAccountTransAssociatedWithPayment section in the > PaymentOverview screen. > The section was extending outside the screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r883291 - /ofbiz/trunk/.classpath
From: "Adam Heath" jler...@apache.org wrote: Author: jleroux Date: Mon Nov 23 09:33:12 2009 New Revision: 883291 URL: http://svn.apache.org/viewvc?rev=883291&view=rev Log: A patch from Erwan de FERRIERES "add path to framework/sql in classpath file" (https://issues.apache.org/jira/browse/OFBIZ-3231) - OFBIZ-3231 With the new framework/sql /* files, we should add the path in the classpath file. If not added, we have errors in eclipse... You know, we should really write something to generate these files, based on build.xml. Maybe using xslt. Yes this seems to be a good suggestion, any takers (I'm not good at xslt, to say the least) ? Jacques PS : Oops, I was sending this top-posted (joke ;o)
[jira] Closed: (OFBIZ-3248) Wrong Label used when creating an employee
[ https://issues.apache.org/jira/browse/OFBIZ-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3248. -- Resolution: Fixed Fix Version/s: SVN trunk Assignee: Jacques Le Roux Thanks for report Sam, Corrected in trunk at r883387 > Wrong Label used when creating an employee > -- > > Key: OFBIZ-3248 > URL: https://issues.apache.org/jira/browse/OFBIZ-3248 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: SVN trunk >Reporter: Sam Hamilton >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: SVN trunk > > > On the https://demo.ofbiz.org/partymgr/control/NewEmployee page the label for > Username is labelled "* Customer will receive a temporary password by email." > I think that should read "* Employee will receive a temporary password by > email." > I should add that this is happening in Flat Grey theme, not tested the other > themes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3252) Add Supplier for Product, it is showing warning on the console.
[ https://issues.apache.org/jira/browse/OFBIZ-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Singh Pandya updated OFBIZ-3252: -- Attachment: OFBIZ-3252.patch Here is the patch to resolve this issue. > Add Supplier for Product, it is showing warning on the console. > --- > > Key: OFBIZ-3252 > URL: https://issues.apache.org/jira/browse/OFBIZ-3252 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: SVN trunk >Reporter: Arpit Singh Pandya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3252.patch > > > When we are going to associate supplier for any product from catalog, it is > showing warning on console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3252) Add Supplier for Product, it is showing warning on the console.
Add Supplier for Product, it is showing warning on the console. --- Key: OFBIZ-3252 URL: https://issues.apache.org/jira/browse/OFBIZ-3252 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Arpit Singh Pandya Priority: Minor Fix For: SVN trunk When we are going to associate supplier for any product from catalog, it is showing warning on console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r883291 - /ofbiz/trunk/.classpath
jler...@apache.org wrote: > Author: jleroux > Date: Mon Nov 23 09:33:12 2009 > New Revision: 883291 > > URL: http://svn.apache.org/viewvc?rev=883291&view=rev > Log: > A patch from Erwan de FERRIERES "add path to framework/sql in classpath file" > (https://issues.apache.org/jira/browse/OFBIZ-3231) - OFBIZ-3231 > With the new framework/sql /* files, we should add the path in the classpath > file. If not added, we have errors in eclipse... You know, we should really write something to generate these files, based on build.xml. Maybe using xslt.
[jira] Updated: (OFBIZ-3248) Wrong Label used when creating an employee
[ https://issues.apache.org/jira/browse/OFBIZ-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-3248: --- Issue Type: Improvement (was: Bug) This is not really a bug because it does not break anything. So it will not be backported to releases... > Wrong Label used when creating an employee > -- > > Key: OFBIZ-3248 > URL: https://issues.apache.org/jira/browse/OFBIZ-3248 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: SVN trunk >Reporter: Sam Hamilton >Priority: Trivial > > On the https://demo.ofbiz.org/partymgr/control/NewEmployee page the label for > Username is labelled "* Customer will receive a temporary password by email." > I think that should read "* Employee will receive a temporary password by > email." > I should add that this is happening in Flat Grey theme, not tested the other > themes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2619) Issues with Receive PO functionality
[ https://issues.apache.org/jira/browse/OFBIZ-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781416#action_12781416 ] Mridul Pathak commented on OFBIZ-2619: -- Thanks for committing the patch, Ashish. It would be good to port this fix to the release 9.04 too as this particular issue and bug fix in OFBIZ-2928 are already being ported to the release branch. > Issues with Receive PO functionality > > > Key: OFBIZ-2619 > URL: https://issues.apache.org/jira/browse/OFBIZ-2619 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Mridul Pathak >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBiz-2619.patch, OFBiz-2619.patch, OFBiz-2619.patch > > > Following are the issues that I came across while going through different > scenarios of receiving PO: > # Create a shipment and receive it from Facility > Shipment > Receive Against > PO (This scenario works correctly) > ## Before receiving shipment: > OrderItem.quantity = 10 > ## Receiving half if the ordered quantity - New ShipmentItem record created. > New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## Receiving remaining quantity but receiving some extra quantity too - > ShipmentItem record updated. New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 7 > ShipmentItem.quantity = 12 (5 + 7) > ItemIssuance.quantity = 7 > Total ItemIssuance.quantity = 12 (5 + 7) > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Shipment > Receive Against PO > ## Before Issuing Order Items - No ShipmentItem or ItemIssuance record > OrderItem.quantity = 5 > ## After Issuing Order Items - ShipmentItem created, ItemIssuance created. > OrderItem.quantity = 5 > Issued quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## On receiving shipment - ShipmentItem updated, new ItemIssuance created > OrderItem.quantity = 5 > Received quantity = 5 > ShipmentItem.quantity = 10 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 10 (5 + 5) > This seems to be a weird behavior. When I have already issued the item in > #b, then on receiving the shipment for the same orderItem quantity in #c, the > ShipmentItem shouldn't be updated and new item issuance shouldn't be created > (creating new item issuance means that I am re-issuing the items). > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Facilities > Receive Inventory by > selecting PO and the respective newly created shipment. > If I issue the same (or more) quantity as ordered for the Order Item and then > receive the exact amount that has been issued (in one or more steps) this > scenario works fine. in following scenarios there is no change in > ShipmentItem and ItemIssuance, which causes conflicts: > ## I issue same quantity as ordered for the Order Item but while receiving > receive more than the issued ordered quantity. > ## I issue same quantity as ordered for the Order Item. While receiving, > receive less first time. Go back to same screen again. Receive more than > the remaining ordered quantity. > ## I issue less quantity than ordered for the Order Item but receive more > than the issued order item quantity. > # Quick Receive Purchase Order > If I Quick Receive Purchase Order from Order Detail page, Shipment is created > and all the Order Items are issued and I am taken to the Receive Inventory > screen directly. If I receive exactly the same amount as ordered for each > order item (at one go, or receiving it in parts) functionality works fine. > But following are the scenarios which breaks everything. > ## Same as #3-a and #3-b. > ## If I receive less quantity than the quantity ordered for order item, and > receive remaining (or more) ordered quantity from Facility > Shipment > > Receive against PO then same issue as reported in #2 occurs. > Note: For testing these issues, comment out eca action > updatePoOnReceiveInventory at line no. 55 in order/servicedef/secas.xml. > This service was recently added in revision 757749, but it only covers #3-a > and #3-c below partially and its logic needs to be rewritten. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Error while creating new customer
Same here. Not able to create the customer. Rishi Solanki Enterprise Software Developer HotWax Media Pvt. Ltd. On Mon, Nov 23, 2009 at 2:11 PM, Deepak Dixit wrote: > I am getting following error while creating new customer. > > Error in Service [partyRolePermissionCheck]: You must be logged in to > complete the [Party role permission logic] process. > > It is working fine for r883228 but not for r883229. > > Thanks & Regards > -- > Deepak Dixit > HotWax Media Pvt. Ltd. > Website :- www.hotwaxmedia.com > Contact :- +91-98267-54548 > >
[jira] Created: (OFBIZ-3251) PaymentOverview screen -FinAccountTransAssociatedWithPayment section
PaymentOverview screen -FinAccountTransAssociatedWithPayment section Key: OFBIZ-3251 URL: https://issues.apache.org/jira/browse/OFBIZ-3251 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: Aswath Satrasala Priority: Minor Attachments: FinAccountTransAssociatedWithPayment.txt Format the FinAccountTransAssociatedWithPayment section in the PaymentOverview screen. The section was extending outside the screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3251) PaymentOverview screen -FinAccountTransAssociatedWithPayment section
[ https://issues.apache.org/jira/browse/OFBIZ-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aswath Satrasala updated OFBIZ-3251: Attachment: FinAccountTransAssociatedWithPayment.txt Fix the formatting of FinAccountTransAssociatedWithPayment section. > PaymentOverview screen -FinAccountTransAssociatedWithPayment section > > > Key: OFBIZ-3251 > URL: https://issues.apache.org/jira/browse/OFBIZ-3251 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Aswath Satrasala >Priority: Minor > Attachments: FinAccountTransAssociatedWithPayment.txt > > > Format the FinAccountTransAssociatedWithPayment section in the > PaymentOverview screen. > The section was extending outside the screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2619) Issues with Receive PO functionality
[ https://issues.apache.org/jira/browse/OFBIZ-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781408#action_12781408 ] Ashish Vijaywargiya commented on OFBIZ-2619: Mridul, Thanks for the contribution - your changes are in trunk at r883348. Your changes looks good to me. I would wait for Adrian's comment for next 1 or 2 days then we will close this issue. -- Ashish Vijaywargiya > Issues with Receive PO functionality > > > Key: OFBIZ-2619 > URL: https://issues.apache.org/jira/browse/OFBIZ-2619 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Mridul Pathak >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBiz-2619.patch, OFBiz-2619.patch, OFBiz-2619.patch > > > Following are the issues that I came across while going through different > scenarios of receiving PO: > # Create a shipment and receive it from Facility > Shipment > Receive Against > PO (This scenario works correctly) > ## Before receiving shipment: > OrderItem.quantity = 10 > ## Receiving half if the ordered quantity - New ShipmentItem record created. > New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## Receiving remaining quantity but receiving some extra quantity too - > ShipmentItem record updated. New ItemIssuance record created. > OrderItem.quantity = 10 > Received quantity = 7 > ShipmentItem.quantity = 12 (5 + 7) > ItemIssuance.quantity = 7 > Total ItemIssuance.quantity = 12 (5 + 7) > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Shipment > Receive Against PO > ## Before Issuing Order Items - No ShipmentItem or ItemIssuance record > OrderItem.quantity = 5 > ## After Issuing Order Items - ShipmentItem created, ItemIssuance created. > OrderItem.quantity = 5 > Issued quantity = 5 > ShipmentItem.quantity = 5 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 5 > ## On receiving shipment - ShipmentItem updated, new ItemIssuance created > OrderItem.quantity = 5 > Received quantity = 5 > ShipmentItem.quantity = 10 > ItemIssuance.quantity = 5 > Total ItemIssuance.quantity = 10 (5 + 5) > This seems to be a weird behavior. When I have already issued the item in > #b, then on receiving the shipment for the same orderItem quantity in #c, the > ShipmentItem shouldn't be updated and new item issuance shouldn't be created > (creating new item issuance means that I am re-issuing the items). > # Create a shipment, issue order items from Facility > Shipment > Order > Items, then receive it from Facility > Facilities > Receive Inventory by > selecting PO and the respective newly created shipment. > If I issue the same (or more) quantity as ordered for the Order Item and then > receive the exact amount that has been issued (in one or more steps) this > scenario works fine. in following scenarios there is no change in > ShipmentItem and ItemIssuance, which causes conflicts: > ## I issue same quantity as ordered for the Order Item but while receiving > receive more than the issued ordered quantity. > ## I issue same quantity as ordered for the Order Item. While receiving, > receive less first time. Go back to same screen again. Receive more than > the remaining ordered quantity. > ## I issue less quantity than ordered for the Order Item but receive more > than the issued order item quantity. > # Quick Receive Purchase Order > If I Quick Receive Purchase Order from Order Detail page, Shipment is created > and all the Order Items are issued and I am taken to the Receive Inventory > screen directly. If I receive exactly the same amount as ordered for each > order item (at one go, or receiving it in parts) functionality works fine. > But following are the scenarios which breaks everything. > ## Same as #3-a and #3-b. > ## If I receive less quantity than the quantity ordered for order item, and > receive remaining (or more) ordered quantity from Facility > Shipment > > Receive against PO then same issue as reported in #2 occurs. > Note: For testing these issues, comment out eca action > updatePoOnReceiveInventory at line no. 55 in order/servicedef/secas.xml. > This service was recently added in revision 757749, but it only covers #3-a > and #3-c below partially and its logic needs to be rewritten. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r883140 - in /ofbiz/trunk/applications: accounting/config/ accounting/script/org/ofbiz/accounting/ accounting/script/org/ofbiz/accounting/agreement/ accounting/servicedef/ accounting/w
Hi Jacques, could you tell me why it doesn't follow the best practice? If it is about the info that should be put in http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration I did it with some delay, because yesterday I had difficulties accessing the page. If there is another reason, please indicate it, so I can fix that. Thanks Bilgin Jacques Le Roux wrote: Hi Bilgin, This does not follow best practices http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities Though, with the migrating service you provided, most is done :o) Thanks Jacques
[jira] Updated: (OFBIZ-3250) PaymentHeader section - formatting
[ https://issues.apache.org/jira/browse/OFBIZ-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aswath Satrasala updated OFBIZ-3250: Attachment: paymentheader.patch Fix for PaymentHeader section overlapping into PaymentsApplied section > PaymentHeader section - formatting > -- > > Key: OFBIZ-3250 > URL: https://issues.apache.org/jira/browse/OFBIZ-3250 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk > Environment: trunk version >Reporter: Aswath Satrasala >Priority: Minor > Attachments: paymentheader.patch > > > In the PaymentOverview screen: > PaymentHeader section is displayed as 2 columns. Some of the fields overlap > to the PaymentsApplied section. > Fix: PaymentHeader section fields are now displayed in 1 column -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3250) PaymentHeader section - formatting
PaymentHeader section - formatting -- Key: OFBIZ-3250 URL: https://issues.apache.org/jira/browse/OFBIZ-3250 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Environment: trunk version Reporter: Aswath Satrasala Priority: Minor In the PaymentOverview screen: PaymentHeader section is displayed as 2 columns. Some of the fields overlap to the PaymentsApplied section. Fix: PaymentHeader section fields are now displayed in 1 column -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781403#action_12781403 ] Jacques Le Roux commented on OFBIZ-3249: Thanks for that comment Ashish, We all know it's not always easy to test all cases, and sometimes there are side-effects. Anyway, i agree this should not prevent us to take care as much as possible. Thanks for you help > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal for some changes to the fields of AcctgTrans/AcctgTransEntry
Jacopo, Thanks for thinking through this. Makes sense to me. Thanks and Regards Anil Patel HotWax Media Inc http://www.hotwaxmedia.com http://us.apachecon.com/c/acus2009/sponsors/sponsors On Nov 23, 2009, at 5:36 AM, Jacopo Cappellato wrote: > I would like to introduce the following changes to the entity definitions of > AcctgTrans and AcctgTransEntry: > > 1) move the field AcctgTransEntry.currencyUomId to AcctgTrans.currencyUomId > (but keeping the AcctgTransEntry.origCurrencyUomId as is now) > 2) add the new field AcctgTrans.totalAmount: for a valid transaction the > field (its absolute value) will have to match with absolute value of the sum > of all credits (or debits); before a transaction it is posted, the system > will check that AcctgTrans.totalAmount = sum of all credits (AcctgTransEntry) > = sum of all debits (AcctgTransEntry) > > Main reasons for this: > a) since the records in AcctgTrans actually represents the lines of a > Journal, it makes sense to have in them all the fields required by journals > (type/description of the transaction, date and amount) > b) the user workflow will be improved: when the AcctgTrans is created (before > the entries) the user already know the amount to be posted (and split into > the different Ledgers) > > What do you think? > > Jacopo >
[jira] Commented: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781398#action_12781398 ] Ashish Vijaywargiya commented on OFBIZ-3249: Yes this makes perfect sense to me, Arun (Thanks!). Man please don't do guess :-) - lot of people are using release branch 9.04 keeping in mind that it is stable. Before two day I have committed code for shopping cart changes in release branch keeping in mind that it might have been tested / reviewed by developer. Then I saw the release branch was broken due to my changes and a new mail in my Inbox for reporting this issue (Thanks Scott for reporting the issue). I have only cross checked things for trunk but now I would prefer to keep myself active for release branch changes as well before committing any changes in it. Arun & others please help me and other committers to test / review things on release branch before mentioning that it is ready for release branch and this bug exists in release branch. Thanks Arun for your contribution. I will wait till morning, if your patch is not picked up by someone else then I will take care of it. -- Ashish Vijaywargiya > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal for some changes to the fields of AcctgTrans/AcctgTransEntry
2) sounds like a good improvement to me Jacques From: "Jacopo Cappellato" I would like to introduce the following changes to the entity definitions of AcctgTrans and AcctgTransEntry: 1) move the field AcctgTransEntry.currencyUomId to AcctgTrans.currencyUomId (but keeping the AcctgTransEntry.origCurrencyUomId as is now) 2) add the new field AcctgTrans.totalAmount: for a valid transaction the field (its absolute value) will have to match with absolute value of the sum of all credits (or debits); before a transaction it is posted, the system will check that AcctgTrans.totalAmount = sum of all credits (AcctgTransEntry) = sum of all debits (AcctgTransEntry) Main reasons for this: a) since the records in AcctgTrans actually represents the lines of a Journal, it makes sense to have in them all the fields required by journals (type/description of the transaction, date and amount) b) the user workflow will be improved: when the AcctgTrans is created (before the entries) the user already know the amount to be posted (and split into the different Ledgers) What do you think? Jacopo
Re: Selenium ehlp
Also, should we free the comment at ? With Oxygen it's "easy" to handle listitem and orderedlist, I mean I can do it if needed... Jacques From: "Jacques Le Roux" Hi, In HELP_WEBTOOLS_selenium.xml. This snippet refers to screen shots that don't exist. Is this a WIP or missing simply ? There also a such paragraph in OfbizSeleniumSetupHTTPS.xml Thanks Jacques
[jira] Updated: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Patidar updated OFBIZ-3249: Fix Version/s: (was: Release Branch 9.04) Ashish, Thanks Ashish for taking care of this. I have not tested it on 9.04 but this issue is very old so It was my guess only. Now I am updating this issue only for trunk, I will test it on 9.04 and if it exists there then I will create new issue for that. --- Arun > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781389#action_12781389 ] Ashish Vijaywargiya commented on OFBIZ-3249: Arun, have you tested it on release branch 9.04? -- Ashish > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Selenium ehlp
Hi, In HELP_WEBTOOLS_selenium.xml. This snippet refers to screen shots that don't exist. Is this a WIP or missing simply ? There also a such paragraph in OfbizSeleniumSetupHTTPS.xml Thanks Jacques
[jira] Updated: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Patidar updated OFBIZ-3249: Fix Version/s: (was: Release Branch 4.0) SVN trunk Ashish - Its by mistake. This bug should be exists in 9.04 and trunk only. > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781381#action_12781381 ] Ashish Vijaywargiya commented on OFBIZ-3249: Arun - Is this bug exists only in release branch 4 & 9.04? -- Ashish > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: Release Branch 4.0, Release Branch 9.04 > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
[ https://issues.apache.org/jira/browse/OFBIZ-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Patidar updated OFBIZ-3249: Attachment: OFBIZ-3249.patch Here is patch for update cart on one page checkout page when a gift item a added in cart after applying valid coupon code. Steps to test: 1. Create a new product promo for 'Gift With Purchase' action with require coupon code. 2. Go to ecommerce -> main 3. Purchase X product and go for one page checkout page. 4. Enter coupon code 5 If this coupon code is valid according to condition given in promotion then a you will get Y product as gift in cart with 0.0 price. > Shopping cart on checkout page does not gets update when a gift item is > added in cart after applying coupon code. > -- > > Key: OFBIZ-3249 > URL: https://issues.apache.org/jira/browse/OFBIZ-3249 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Reporter: Arun Patidar >Priority: Minor > Fix For: Release Branch 4.0, Release Branch 9.04 > > Attachments: OFBIZ-3249.patch > > > For a coupon code on which a gift item is added in cart, shopping cart on > checkout page does not gets update for that new added gift item. > Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3249) Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code.
Shopping cart on checkout page does not gets update when a gift item is added in cart after applying coupon code. -- Key: OFBIZ-3249 URL: https://issues.apache.org/jira/browse/OFBIZ-3249 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Reporter: Arun Patidar Priority: Minor Fix For: Release Branch 4.0, Release Branch 9.04 For a coupon code on which a gift item is added in cart, shopping cart on checkout page does not gets update for that new added gift item. Currently cart is only updating for discounted amount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3248) Wrong Label used when creating an employee
[ https://issues.apache.org/jira/browse/OFBIZ-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Hamilton updated OFBIZ-3248: Description: On the https://demo.ofbiz.org/partymgr/control/NewEmployee page the label for Username is labelled "* Customer will receive a temporary password by email." I think that should read "* Employee will receive a temporary password by email." I should add that this is happening in Flat Grey theme, not tested the other themes. was:On the https://demo.ofbiz.org/partymgr/control/NewEmployee page the label for Username is labelled "* Customer will receive a temporary password by email." I think that should read "* Employee will receive a temporary password by email." > Wrong Label used when creating an employee > -- > > Key: OFBIZ-3248 > URL: https://issues.apache.org/jira/browse/OFBIZ-3248 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: SVN trunk >Reporter: Sam Hamilton >Priority: Trivial > > On the https://demo.ofbiz.org/partymgr/control/NewEmployee page the label for > Username is labelled "* Customer will receive a temporary password by email." > I think that should read "* Employee will receive a temporary password by > email." > I should add that this is happening in Flat Grey theme, not tested the other > themes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3248) Wrong Label used when creating an employee
Wrong Label used when creating an employee -- Key: OFBIZ-3248 URL: https://issues.apache.org/jira/browse/OFBIZ-3248 Project: OFBiz Issue Type: Bug Components: party Affects Versions: SVN trunk Reporter: Sam Hamilton Priority: Trivial On the https://demo.ofbiz.org/partymgr/control/NewEmployee page the label for Username is labelled "* Customer will receive a temporary password by email." I think that should read "* Employee will receive a temporary password by email." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3247) State field is missing - Not in List or N/A
[ https://issues.apache.org/jira/browse/OFBIZ-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Hamilton updated OFBIZ-3247: Description: When you are creating an employee on https://demo.ofbiz.org/partymgr/control/NewEmployee there is no field in the drop down box for Not Applicable, just in case you cant find the state you wanted, I was trying to find an English counties at the time. was:When you are creating an employee there is no field in the drop down box for Not Applicable, just in case you cant find the state you wanted, I was trying to find an English counties at the time. > State field is missing - Not in List or N/A > --- > > Key: OFBIZ-3247 > URL: https://issues.apache.org/jira/browse/OFBIZ-3247 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: SVN trunk >Reporter: Sam Hamilton >Priority: Trivial > > When you are creating an employee on > https://demo.ofbiz.org/partymgr/control/NewEmployee there is no field in the > drop down box for Not Applicable, just in case you cant find the state you > wanted, I was trying to find an English counties at the time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3247) State field is missing - Not in List or N/A
State field is missing - Not in List or N/A --- Key: OFBIZ-3247 URL: https://issues.apache.org/jira/browse/OFBIZ-3247 Project: OFBiz Issue Type: Bug Components: party Affects Versions: SVN trunk Reporter: Sam Hamilton Priority: Trivial When you are creating an employee there is no field in the drop down box for Not Applicable, just in case you cant find the state you wanted, I was trying to find an English counties at the time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3228) Update german GeoData.xml - 3 states added
[ https://issues.apache.org/jira/browse/OFBIZ-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781366#action_12781366 ] Christian Geisert commented on OFBIZ-3228: -- Yes, looks good. Thanks Jacques (and Sascha) > Update german GeoData.xml - 3 states added > -- > > Key: OFBIZ-3228 > URL: https://issues.apache.org/jira/browse/OFBIZ-3228 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Christian Geisert > Fix For: SVN trunk > > Attachments: GeoData_DE.xml.patch > > > Hi, > in the GeoData.xml were 3 states missing. > best regards, > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal for some changes to the fields of AcctgTrans/AcctgTransEntry
I totally agree on these changes. This will also helps in effective report generations. Regards -- Chirag Manocha Freelancer +91-98263-19099 On Mon, Nov 23, 2009 at 4:06 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > I would like to introduce the following changes to the entity definitions > of AcctgTrans and AcctgTransEntry: > > 1) move the field AcctgTransEntry.currencyUomId to AcctgTrans.currencyUomId > (but keeping the AcctgTransEntry.origCurrencyUomId as is now) > 2) add the new field AcctgTrans.totalAmount: for a valid transaction the > field (its absolute value) will have to match with absolute value of the sum > of all credits (or debits); before a transaction it is posted, the system > will check that AcctgTrans.totalAmount = sum of all credits > (AcctgTransEntry) = sum of all debits (AcctgTransEntry) > > Main reasons for this: > a) since the records in AcctgTrans actually represents the lines of a > Journal, it makes sense to have in them all the fields required by journals > (type/description of the transaction, date and amount) > b) the user workflow will be improved: when the AcctgTrans is created > (before the entries) the user already know the amount to be posted (and > split into the different Ledgers) > > What do you think? > > Jacopo > >
[jira] Updated: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-3227: --- Attachment: myPortalDragNDrop_v2.patch sorry for the many posts, but i added a fix for this 'stupid' div flickering bug :-) best regards, Sascha > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Proposal for some changes to the fields of AcctgTrans/AcctgTransEntry
I would like to introduce the following changes to the entity definitions of AcctgTrans and AcctgTransEntry: 1) move the field AcctgTransEntry.currencyUomId to AcctgTrans.currencyUomId (but keeping the AcctgTransEntry.origCurrencyUomId as is now) 2) add the new field AcctgTrans.totalAmount: for a valid transaction the field (its absolute value) will have to match with absolute value of the sum of all credits (or debits); before a transaction it is posted, the system will check that AcctgTrans.totalAmount = sum of all credits (AcctgTransEntry) = sum of all debits (AcctgTransEntry) Main reasons for this: a) since the records in AcctgTrans actually represents the lines of a Journal, it makes sense to have in them all the fields required by journals (type/description of the transaction, date and amount) b) the user workflow will be improved: when the AcctgTrans is created (before the entries) the user already know the amount to be posted (and split into the different Ledgers) What do you think? Jacopo
Re: svn commit: r883140 - in /ofbiz/trunk/applications: accounting/config/ accounting/script/org/ofbiz/accounting/ accounting/script/org/ofbiz/accounting/agreement/ accounting/servicedef/ accounting/w
Hi Bilgin, This does not follow best practices http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities Though, with the migrating service you provided, most is done :o) Thanks Jacques Author: bibryam Date: Sun Nov 22 20:17:38 2009 New Revision: 883140 URL: http://svn.apache.org/viewvc?rev=883140&view=rev Log: Renamed AgreementWorkEffortAppl entity to AgreementWorkEffortApplic in order to change relation types so that assigning WorkEfforts to Agreements is possible w/o specifying an agreementItemSeqId. Added a migrateAgreementWorkEffortAppl service to migrate existing data to the new entity. Added: ofbiz/trunk/applications/party/entitydef/entitymodel_old.xml Modified: ofbiz/trunk/applications/accounting/config/AccountingHelpUrls.xml ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/UpgradeServices.xml ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/agreement/AgreementServices.xml ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml ofbiz/trunk/applications/accounting/servicedef/services_upgrade.xml ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml ofbiz/trunk/applications/accounting/widget/AccountingMenus.xml ofbiz/trunk/applications/accounting/widget/AgreementForms.xml ofbiz/trunk/applications/accounting/widget/AgreementScreens.xml ofbiz/trunk/applications/party/entitydef/entitymodel.xml ofbiz/trunk/applications/party/ofbiz-component.xml ofbiz/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml ofbiz/trunk/applications/workeffort/widget/WorkEffortForms.xml ofbiz/trunk/applications/workeffort/widget/WorkEffortMenus.xml ofbiz/trunk/applications/workeffort/widget/WorkEffortScreens.xml Modified: ofbiz/trunk/applications/accounting/config/AccountingHelpUrls.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/AccountingHelpUrls.xml?rev=883140&r1=883139&r2=883140&view=diff == --- ofbiz/trunk/applications/accounting/config/AccountingHelpUrls.xml (original) +++ ofbiz/trunk/applications/accounting/config/AccountingHelpUrls.xml Sun Nov 22 20:17:38 2009 @@ -203,8 +203,8 @@ 09.3 Agreement Items 09.3 ååæ¡æ¬¾ - -09.4 Agreement Work Effort Appls + +09.4 Agreement Work Effort Applics 09.4 åå人工æå¡ç¨é Modified: ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml?rev=883140&r1=883139&r2=883140&view=diff == --- ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml (original) +++ ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml Sun Nov 22 20:17:38 2009 @@ -215,11 +215,11 @@ รหัสหà¸à¹à¸§à¸¢à¸§à¸±à¸à¸à¸³à¸à¸§à¸à¹à¸à¸´à¸ å®é éé¢è´§å¸åä½æ è¯ - + Vereinbarung-Arbeitseinsatz hinzufügen -Add Agreement Work Effort Appl +Add Agreement Work Effort Applic Ajouter une application de tâche d'accord commercial -ठनà¥à¤¬à¤à¤§ à¤à¤¾à¤°à¥à¤¯ पà¥à¤°à¤¯à¤¾à¤¸ ठनà¥à¤ªà¥à¤°à¤¯à¥à¤(AgreementWorkEffortAppl) बनाà¤à¤ +ठनà¥à¤¬à¤à¤§ à¤à¤¾à¤°à¥à¤¯ पà¥à¤°à¤¯à¤¾à¤¸ ठनà¥à¤ªà¥à¤°à¤¯à¥à¤(AgreementWorkEffortApplic) बनाà¤à¤ Aggiungi Applicazione Termine Impegno di Lavoro Voeg Werkinzettoepassing van overeenkomt toe æ·»å å议人工æå¡ç¨é @@ -647,16 +647,16 @@ รหัสà¸à¸£à¸°à¹à¸ à¸à¸ªà¸±à¸à¸à¸² ååç±»åæ è¯ - -Agreement Work Effort Appl Already Exists + +Agreement Work Effort Applic Already Exists Cette tâche d'application d'accord commercial existe déjà ठनà¥à¤¬à¤à¤§ - à¤à¤¾à¤® पà¥à¤°à¤¯à¤¾à¤¸ à¤à¤¾ ठनà¥à¤ªà¥à¤°à¤¯à¥à¤ पहलॠसॠहॠमà¥à¤à¥à¤¦ हॠApplicazioni contratto impegno di labovo già esistente -Overeenkomst Work Effort Appl bestaat al +Overeenkomst Work Effort Applic bestaat al åå人工æå¡ç¨éå·²åå¨ - -Agreement Work Effort Appls + +Agreement Work Effort Applics Applications de tâche d'accord commercial ठनà¥à¤¬à¤à¤§- à¤à¤¾à¤°à¥à¤¯ पà¥à¤°à¤¯à¤¾à¤¸ ठनà¥à¤ªà¥à¤°à¤¯à¥à¤ Applicazioni Impegni di Lavoro @@ -5487,9 +5487,9 @@ à¸à¸¥à¸£à¸§à¸¡à¹à¸à¸§ æ»è¡æ° - + Zugewiesene Arbeitseinsätze zu Vereinbarungen auflisten -List Agreement Work Effort Appls +List Agreement Work Effort Applics
[jira] Closed: (OFBIZ-3231) add path to framework/sql in classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3231. -- Resolution: Fixed Assignee: Jacques Le Roux Right! I was wondering why I got this error message when launching OFBiz from Eclipse these last days:) Thanks Erwan, your patch is in trunk at r883291 > add path to framework/sql in classpath file > --- > > Key: OFBIZ-3231 > URL: https://issues.apache.org/jira/browse/OFBIZ-3231 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Erwan de FERRIERES >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3231.patch > > > with the new framework/sql /* files, we should add the path in the classpath > file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-3227: --- Attachment: (was: myPortalDragNDrop_v2.patch) > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-3227: --- Attachment: myPortalDragNDrop_v2.patch > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3231) add path to framework/sql in classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781337#action_12781337 ] Erwan de FERRIERES commented on OFBIZ-3231: --- If not added, we have errors in eclipse... > add path to framework/sql in classpath file > --- > > Key: OFBIZ-3231 > URL: https://issues.apache.org/jira/browse/OFBIZ-3231 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Erwan de FERRIERES > Fix For: SVN trunk > > Attachments: OFBIZ-3231.patch > > > with the new framework/sql /* files, we should add the path in the classpath > file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
