Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-5766

Error when adding/modifying a task to a Production Run - field type error

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Trivial
    • Resolution: Fixed
    • Affects Version/s: Release Branch 13.07, Trunk
    • Fix Version/s: 14.12.01, 12.04.06, 13.07.02
    • Component/s: manufacturing
    • Labels:
      None

      Description

      You select a production run, then you click on "Task" tab to list tasks included in the production run.
      You are not able to add a new task or modify any of already included tasks because of field type error.
      Following events and services are waiting estimatedMilliseconds and estimatedSetupMillis as BigDecimal instead of Double.
      Events :
      ProductionRunSimpleEvents.editProductionRunRoutingTask
      ProductionRunSimpleEvents.addProductionRunRoutinsTask
      Services :
      services_production_run.addProductionRunRoutingTask
      services_production_run.checkUpdatePrunRoutingTask

      Add-Task-To-Production-Run (13.07 and trunk releases) change fields type from BigDecimal to Double.

      1. Add-Task-To-Production-Run-13.07.patch
        5 kB
        Guillaume Sigoigne
      2. Add-Task-To-Production-Run-trunk.patch
        5 kB
        Guillaume Sigoigne
      3. OFBIZ-5766.patch
        4 kB
        Divesh Dutta

        Activity

        Hide
        pfm.smits Pierre Smits added a comment -

        Guillaume,

        Your issue and its patch are confusing. The title of the issue is about a problem when trying to add a task. You description talks about adding and modifying task as the main problem. And your patch (for trunk) is about changing the field type of 2 fields.

        What should it be? Please make your title and description reflect the patch or your patch and description reflect the title. Now it is confusing.

        Regards,

        Pierre

        Show
        pfm.smits Pierre Smits added a comment - Guillaume, Your issue and its patch are confusing. The title of the issue is about a problem when trying to add a task. You description talks about adding and modifying task as the main problem. And your patch (for trunk) is about changing the field type of 2 fields. What should it be? Please make your title and description reflect the patch or your patch and description reflect the title. Now it is confusing. Regards, Pierre
        Hide
        gsigoigne Guillaume Sigoigne added a comment -

        Pierre,

        I understand what you mean.
        The main problem is that field type of estimatedMilliseconds and estimatedSetupMillis are wrong in some events and services.

        Are my modifications to title and description correct enough?

        Show
        gsigoigne Guillaume Sigoigne added a comment - Pierre, I understand what you mean. The main problem is that field type of estimatedMilliseconds and estimatedSetupMillis are wrong in some events and services. Are my modifications to title and description correct enough?
        Hide
        soledad Nicolas Malin added a comment - - edited

        Guillaume,

        I confirm the problem but I think your correction isn't raise the real problem.
        I find that the conversion from Double to BigDecimal has been commited by David E. Jones on the revision 731851

        Manual merge of typecheckcleanup200810 branch as of rev 731346 in that branch, resolved all conflicts; with this BigDecimal is not the native type for many entity fields and is used for many calculations; some work is still needed in certain areas of the project but this covers the most critical ones; thanks especially to Scott for his work on this

        But the problem is that most of service like "addProductionRunRoutingTask" call createWorkEffort where the attribute define by

            <service name="createWorkEffort" default-entity-name="WorkEffort" engine="simple" ...
                <auto-attributes mode="INOUT" include="pk" optional="true"/>
            </service>
        

        Who generate an entry for Double and not BigDecimal

        We have many solution, now we need to choose the best :

        • Convert all service use estimatedSetupMillis and estimatedMilliSeconds from BigDecimal to Double, in other word revert a part of the commit 731851
        • Extend WorkEffort service to take estimatedSetupMillis and estimatedMilliSeconds as BigDecimal
        • Authorize the automatic conversion BigDecimal to Double

        Any suggest ?

        Show
        soledad Nicolas Malin added a comment - - edited Guillaume, I confirm the problem but I think your correction isn't raise the real problem. I find that the conversion from Double to BigDecimal has been commited by David E. Jones on the revision 731851 Manual merge of typecheckcleanup200810 branch as of rev 731346 in that branch, resolved all conflicts; with this BigDecimal is not the native type for many entity fields and is used for many calculations; some work is still needed in certain areas of the project but this covers the most critical ones; thanks especially to Scott for his work on this But the problem is that most of service like "addProductionRunRoutingTask" call createWorkEffort where the attribute define by <service name= "createWorkEffort" default -entity-name= "WorkEffort" engine= "simple" ... <auto-attributes mode= "INOUT" include= "pk" optional= " true " /> </service> Who generate an entry for Double and not BigDecimal We have many solution, now we need to choose the best : Convert all service use estimatedSetupMillis and estimatedMilliSeconds from BigDecimal to Double, in other word revert a part of the commit 731851 Extend WorkEffort service to take estimatedSetupMillis and estimatedMilliSeconds as BigDecimal Authorize the automatic conversion BigDecimal to Double Any suggest ?
        Hide
        julien.nicolas Julien NICOLAS added a comment -

        Hi,

        I don't know why using BigDecimal on a field that store millisecond ?
        Maybe I'm wrong but do we need nanosecond ? Are systems able to provide nanosecond for time elapsed ? Do we need it in ERP ?

        The problem is that BigDecimal use more memory and processor time to be managed unlike long variable.
        I know that change again estimatedMilliSecond and estimatedSetupMillis from BigDecimal to long could be painful.

        Maybe we could use the automatic conversion to do the job and solve this problem like that ?

        Any suggestions ?

        Show
        julien.nicolas Julien NICOLAS added a comment - Hi, I don't know why using BigDecimal on a field that store millisecond ? Maybe I'm wrong but do we need nanosecond ? Are systems able to provide nanosecond for time elapsed ? Do we need it in ERP ? The problem is that BigDecimal use more memory and processor time to be managed unlike long variable. I know that change again estimatedMilliSecond and estimatedSetupMillis from BigDecimal to long could be painful. Maybe we could use the automatic conversion to do the job and solve this problem like that ? Any suggestions ?
        Hide
        diveshdut Divesh Dutta added a comment -

        Here is the patch which fix this issue. Here we are getting estimatedSetupMillis as BigDecimal in service implementation of addProductionRunRoutingTask service and converting it into Double using doubleValue method of BigDecimal class.

        This fixed the issue. After fixing this issue, also found error in getEstimatedTaskTime method of ProductionRun class. Fixed that as well in this patch.

        Also fixed code in Update Production run routing task process as same error was in returned in that process.

        Show
        diveshdut Divesh Dutta added a comment - Here is the patch which fix this issue. Here we are getting estimatedSetupMillis as BigDecimal in service implementation of addProductionRunRoutingTask service and converting it into Double using doubleValue method of BigDecimal class. This fixed the issue. After fixing this issue, also found error in getEstimatedTaskTime method of ProductionRun class. Fixed that as well in this patch. Also fixed code in Update Production run routing task process as same error was in returned in that process.
        Hide
        toashishvijay Ashish Vijaywargiya added a comment -

        Hey Nicolas, I have assigned this issue to myself. I am taking care of it now. I hope this is fine. Thanks!

        Show
        toashishvijay Ashish Vijaywargiya added a comment - Hey Nicolas, I have assigned this issue to myself. I am taking care of it now. I hope this is fine. Thanks!
        Hide
        toashishvijay Ashish Vijaywargiya added a comment -

        Thanks Guillaume for reporting the issue. Thanks Divesh for providing the fix.
        Changes are committed at:

        trunk - 1639880
        13.07 - 1639881
        12.04 - 1639883

        Show
        toashishvijay Ashish Vijaywargiya added a comment - Thanks Guillaume for reporting the issue. Thanks Divesh for providing the fix. Changes are committed at: trunk - 1639880 13.07 - 1639881 12.04 - 1639883
        Hide
        soledad Nicolas Malin added a comment -

        Hey Nicolas, I have assigned this issue to myself. I am taking care of it now. I hope this is fine. Thanks!

        It's groovy Ashish, I hadn't the possibility to take the time to complete this issue. Thanks to you and Jacques for fixed it

        Show
        soledad Nicolas Malin added a comment - Hey Nicolas, I have assigned this issue to myself. I am taking care of it now. I hope this is fine. Thanks! It's groovy Ashish, I hadn't the possibility to take the time to complete this issue. Thanks to you and Jacques for fixed it
        Hide
        gsigoigne Guillaume Sigoigne added a comment -

        Thanks all for having fixing this issue.

        Show
        gsigoigne Guillaume Sigoigne added a comment - Thanks all for having fixing this issue.

          People

          • Assignee:
            toashishvijay Ashish Vijaywargiya
            Reporter:
            gsigoigne Guillaume Sigoigne
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development