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

Adding Uom to product quantity in production run forms

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Trivial
    • Resolution: Implemented
    • Affects Version/s: Release Branch 13.07, Trunk
    • Fix Version/s: 14.12.01, 16.11.01
    • Component/s: manufacturing, product
    • Labels:
      None

      Description

      When a production run has components, forms show quantity of each component, but not their uom description.

      1. Show-Uom-Quantity-13.07.patch
        4 kB
        Guillaume Sigoigne
      2. Show-Uom-Quantity-trunk.patch
        4 kB
        Guillaume Sigoigne

        Issue Links

          Activity

          Hide
          pfm.smits Pierre Smits added a comment -

          Guillaume,

          Given that your patch (for trunk) also applies to the manufacturing component, please set the component field accordingly.
          If your patch for 13.07 is the same as the one for trunk, you can do with 1 patch file.

          I will test the trunk version shortly.

          Show
          pfm.smits Pierre Smits added a comment - Guillaume, Given that your patch (for trunk) also applies to the manufacturing component, please set the component field accordingly. If your patch for 13.07 is the same as the one for trunk, you can do with 1 patch file. I will test the trunk version shortly.
          Hide
          pfm.smits Pierre Smits added a comment -

          Seem to be duplicates.

          Show
          pfm.smits Pierre Smits added a comment - Seem to be duplicates.
          Hide
          gsigoigne Guillaume Sigoigne added a comment -

          Sorry, I didnt understand what you mean by duplicates.
          Is it the code between release 13.07 and trunk, or is it an update which has already been proposed, or something else ?

          Show
          gsigoigne Guillaume Sigoigne added a comment - Sorry, I didnt understand what you mean by duplicates. Is it the code between release 13.07 and trunk, or is it an update which has already been proposed, or something else ?
          Hide
          pfm.smits Pierre Smits added a comment -

          The issues are duplicates.

          If you find something wrong in your personal development set up with the OFBiz code, it is advised to look if already a JIRA issue is registered and work from there. This avoids having to do a lot of issue clean-up.

          Show
          pfm.smits Pierre Smits added a comment - The issues are duplicates. If you find something wrong in your personal development set up with the OFBiz code, it is advised to look if already a JIRA issue is registered and work from there. This avoids having to do a lot of issue clean-up.
          Hide
          gsigoigne Guillaume Sigoigne added a comment -

          Oups, sorry Pierre, I didn't notice the JIRA you are talking about.
          I understand the problem of clean-up, so I would be more careful next time.

          Regarding the 2 patchs, no, I couldn't do only one patch. There was some small differences in the modified files between the two releases.

          Show
          gsigoigne Guillaume Sigoigne added a comment - Oups, sorry Pierre, I didn't notice the JIRA you are talking about. I understand the problem of clean-up, so I would be more careful next time. Regarding the 2 patchs, no, I couldn't do only one patch. There was some small differences in the modified files between the two releases.
          Hide
          pfm.smits Pierre Smits added a comment -

          I have applied the 'Show-Uom-Quantity-Trunk' patch and it tested successfully.

          Show
          pfm.smits Pierre Smits added a comment - I have applied the 'Show-Uom-Quantity-Trunk' patch and it tested successfully.
          Hide
          pfm.smits Pierre Smits added a comment -

          I also applied the ''Show-Uom-Quantity-13.07' patch to trunk and it also tested successfully.
          Comparing the two line by line I couldn't find any significant differences (maybe I overlooked).

          Anyway, this can be applied.

          Show
          pfm.smits Pierre Smits added a comment - I also applied the ''Show-Uom-Quantity-13.07' patch to trunk and it also tested successfully. Comparing the two line by line I couldn't find any significant differences (maybe I overlooked). Anyway, this can be applied.
          Hide
          gsigoigne Guillaume Sigoigne added a comment -

          Efectively, there is no difference of code between the 2 versions, there is only difference of line number in the file.
          I thought it was easier for commiter to have the 2 versions, to avoid looking for the right place in the file.

          When there is only position difference, you advise to create only one patch ?

          Show
          gsigoigne Guillaume Sigoigne added a comment - Efectively, there is no difference of code between the 2 versions, there is only difference of line number in the file. I thought it was easier for commiter to have the 2 versions, to avoid looking for the right place in the file. When there is only position difference, you advise to create only one patch ?
          Hide
          pfm.smits Pierre Smits added a comment -

          The best approach, when having identified an issue for a specific release version, is to state the release version in the 'affected version' field.
          If you (or another contributor) then investigate further and find the issue also present in another release version, adjust the 'affected version' field.

          That way people can do fine grained searches to find what they look for.

          Then, when having created, tested and uploaded the patch for your version, state that version in the 'fix version' field. And if you have the time and pleasure to test the patch for the other affected version and the tests pass you update the 'fix version' field. If it becomes clear that a specific release version needs a special patch, you then have the options to either include that special patch in the issue and describe in the upload comment what the affected release version it is applicable to, or create a new issue.

          The more information provided in a JIRA issue the better it helps other users, contributors and especially committers, as the burden to commit is on them. If the information is incomplete or cryptic the issue will take longer to be resolved.

          In this case (this issue), the issue applies to trunk first. And given that the differences between trunk and 13.07 with respect to the affected areas is negligible, it can be used as a fix for 13.07 as well.

          Show
          pfm.smits Pierre Smits added a comment - The best approach, when having identified an issue for a specific release version, is to state the release version in the 'affected version' field. If you (or another contributor) then investigate further and find the issue also present in another release version, adjust the 'affected version' field. That way people can do fine grained searches to find what they look for. Then, when having created, tested and uploaded the patch for your version, state that version in the 'fix version' field. And if you have the time and pleasure to test the patch for the other affected version and the tests pass you update the 'fix version' field. If it becomes clear that a specific release version needs a special patch, you then have the options to either include that special patch in the issue and describe in the upload comment what the affected release version it is applicable to, or create a new issue. The more information provided in a JIRA issue the better it helps other users, contributors and especially committers, as the burden to commit is on them. If the information is incomplete or cryptic the issue will take longer to be resolved. In this case (this issue), the issue applies to trunk first. And given that the differences between trunk and 13.07 with respect to the affected areas is negligible, it can be used as a fix for 13.07 as well.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Amendment to what Pierre Smits wrote in the last comment: please do not set the 'fix version' field; that field will be set by the committer to specify the release branches in which the patch was committed.

          Show
          jacopoc Jacopo Cappellato added a comment - Amendment to what Pierre Smits wrote in the last comment: please do not set the 'fix version' field; that field will be set by the committer to specify the release branches in which the patch was committed.
          Hide
          pfm.smits Pierre Smits added a comment -

          Thanks for the correction, Jacopo.

          Show
          pfm.smits Pierre Smits added a comment - Thanks for the correction, Jacopo.
          Hide
          soledad Nicolas Malin added a comment -

          Hello Guillaume (ça farte)

          I reviewed your patch and my remarks is the result is fine but isn't a good way to store in the context your description on quantityUomId field. It's better to use a dedicate name like quantityUomDesc.

          But (because they are another but !) why don't use direclty this

          +        <row-actions>
          +            <entity-one entity-name="Product" value-name="product" use-cache="true"/>
          +        </row-actions>
          ....
          +        <field name="quantityUomId" map-name="product"><display-entity entity-name="Uom" key-field-name="uomId"/></field>
          
          Show
          soledad Nicolas Malin added a comment - Hello Guillaume (ça farte) I reviewed your patch and my remarks is the result is fine but isn't a good way to store in the context your description on quantityUomId field. It's better to use a dedicate name like quantityUomDesc. But (because they are another but !) why don't use direclty this + <row-actions> + <entity-one entity-name= "Product" value-name= "product" use-cache= " true " /> + </row-actions> .... + <field name= "quantityUomId" map-name= "product" ><display-entity entity-name= "Uom" key-field-name= "uomId" /></field>
          Hide
          pfm.smits Pierre Smits added a comment -

          I see different approaches applied in various forms.

          <row-actions>
          <entity-one entity-name="Product" value-field="product"/>
          <set field="productUom" value="${product.quantityUomId}"/>
          </row-actions>
          
          <field name="quantityUomId" entry-name="productUom" title="UoM">
          <display-entity entity-name="Uom" key-field-name="uomId" description="${abbreviation}"/>
          </field>
          

          And

          <row-actions>
          <script location="component://product/webapp/catalog/WEB-INF/actions/product/GetProductQuantityUomId.groovy"/>
          </row-actions>
          
          <field name="quantityUomId">
          <display-entity entity-name="Uom" key-field-name="uomId" description="${abbreviation}"/>
          </field>
          

          Basically it is about choosing the approach that suits us best, and then apply it everywhere where applicable.

          Show
          pfm.smits Pierre Smits added a comment - I see different approaches applied in various forms. <row-actions> <entity-one entity-name= "Product" value-field= "product" /> <set field= "productUom" value= "${product.quantityUomId}" /> </row-actions> <field name= "quantityUomId" entry-name= "productUom" title= "UoM" > <display-entity entity-name= "Uom" key-field-name= "uomId" description= "${abbreviation}" /> </field> And <row-actions> <script location= "component://product/webapp/catalog/WEB-INF/actions/product/GetProductQuantityUomId.groovy" /> </row-actions> <field name= "quantityUomId" > <display-entity entity-name= "Uom" key-field-name= "uomId" description= "${abbreviation}" /> </field> Basically it is about choosing the approach that suits us best, and then apply it everywhere where applicable.
          Hide
          pfm.smits Pierre Smits added a comment -

          Come to think of it, the product page of a product in catalog shows a lot of product measurements and associated uomIds in the 'Measure' section.

          We could consider expanding this issue, the groovy patch and have it applicable for any and all product measurements and uomIds.

          Show
          pfm.smits Pierre Smits added a comment - Come to think of it, the product page of a product in catalog shows a lot of product measurements and associated uomIds in the 'Measure' section. We could consider expanding this issue, the groovy patch and have it applicable for any and all product measurements and uomIds.
          Hide
          soledad Nicolas Malin added a comment -

          Ok, I commited this proposition on
          trunk : 1655165
          14.12 : 1655166

          I didt propage on 13.07 because is the stable branch and isn't a bug .

          Thanks Guillaume for the issue and pierre for your comments.
          For other measure types, I think we need to deploy a configurable template, but it's an other story.

          Show
          soledad Nicolas Malin added a comment - Ok, I commited this proposition on trunk : 1655165 14.12 : 1655166 I didt propage on 13.07 because is the stable branch and isn't a bug . Thanks Guillaume for the issue and pierre for your comments. For other measure types, I think we need to deploy a configurable template, but it's an other story.

            People

            • Assignee:
              soledad Nicolas Malin
              Reporter:
              gsigoigne Guillaume Sigoigne
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development