The problem with Jira is that there is no good way to do threaded
discussions. If it is a single and very simple topic, no big deal...
but as soon as you have multiple questions or comments to respond
to... how do you do that?
Editing previous comments is an interesting way, but if people do that
they MUST put a BIG prefix before their comments so it is possible to
distinguish them from the original text. That should include more than
just a pair of "*" to bold part or all of the response, and should
also include your initials so that it is clear which things you added.
Also, for these sorts of things we should be sure to add and not edit
wherever possible.
Anyway, if there is a better way to handle threaded discussions and
keep things in context that would be GREAT as this is pretty kludgy.
-David
On May 1, 2009, at 12:22 AM, Scott Gray wrote:
Yeah I guess at the end of the day it doesn't really bother me, I
just like to let people know that if you edit your comment and I've
already read the original, well I won't be reading it a second
time :-) My guess is that a lot of other people don't bother
reading edits either.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
I personnaly prefer that we keep it (anyway this would be a Jira
demand to infra) because sometimes it's useful. But totally agree
that we should use this feature parsimoniously
The problem with this kind of non authoritative approach is that
you have to explain over and over. On the other hand, this is what
we call education...
Jacques
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
Hi Divesh (and anybody else who does this regularly)
Wherever possible please avoid editing comments (I almost wish we
could turn it off), most of us read jira issues through email
notifications and it is impossible to know what you've changed in
your comment.
Thanks
Scott
HotWax Media
http://www.hotwaxmedia.com
On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:
[ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704689
#action_12704689 ]
Divesh Dutta edited comment on OFBIZ-2388 at 4/30/09 9:35 PM:
--------------------------------------------------------------
Hello David,
Please see my comments inline :
The way this is implemented will not scale adequately for
deployments with large numbers of orders.
In the ReviewOrdersNotPickedOrPacked.groovy file the first line
of code gets ALL OrderHeader records from the database, ie:
orderHeaders = delegator.findList("OrderHeader", null, null,
null, null, false);
This is not acceptable as there could be hundreds of thousands
of millions of orders in the database, and so this line will fail.
*Very true. Here we can add condition. Below is the code
snippet. Please suggest.*
{quote}condList.add(EntityCondition.makeCondition("statusId",
EntityOperator.EQUALS, "ORDER_APPROVED"));
condList.add(EntityCondition.makeCondition("orderTypeId",
EntityOperator.EQUALS, "SALES_ORDER"));
condList
.add(EntityCondition.makeCondition("pickSheetPrintedDate",
EntityOperator.NOT_EQUAL, null));
cond = EntityCondition.makeCondition(condList, EntityOperator.AND);
orderHeaderList = delegator.findList("OrderHeader", cond, null,
null, null, false);{quote}
Later on down in the file the code looks for Shipment records
with a primaryOrderId that matches the orderId on each
OrderHeader, and then looks at other things on the Shipment
record(s) corresponding.
All of this can, and should, be done with a view entity. In fact,
it must be done with a view entity so that the work is done in a
query in the database and not in a script on the app server
which is hugely inefficient, so much so that in even moderately
large systems it simply WILL NOT WORK!
*Agreed*
An addition note: looking for shipments by matching the
OrderHeader.orderId with the Shipment.primaryOrderId is not
adequate. Please change it to match the OrderHeader.orderId with
the ItemIssuance.orderId and then ItemIssuance.shipmentId with
Shipment.shipmentId. Not that there will be many records for a
single OrderHeader and Shipment combination since the
ItemIssuance really ties a OrderItem to a ShipmentItem, but that
is fine since in this case all we care about is the OrderHeader
to Shipment relationship. Why do we need this? Because it is
possible for a single Shipment to have items from different
orders on it, and simply looking at the Shipment.primaryOrderId
won't capture that... that field is only the PRIMARY orderId.
*But here the confusion is , Entries in ItemIssuance Entity is
not done when we do "Verify Pick" (only done when shipment is
created in Packed status). So Entries are not present in
ItemIssuance entity for Orders which have shipment in "Input",
"Picked", and "Scheduled" status. So IMO above given logic will
not help . Please let me know if I am wrong.*
was (Author: diveshdut):
Hello David,
Please see my comments inline :
The way this is implemented will not scale adequately for
deployments with large numbers of orders.
In the ReviewOrdersNotPickedOrPacked.groovy file the first line
of code gets ALL OrderHeader records from the database, ie:
orderHeaders = delegator.findList("OrderHeader", null, null,
null, null, false);
This is not acceptable as there could be hundreds of thousands
of millions of orders in the database, and so this line will fail.
*Very true*
Later on down in the file the code looks for Shipment records
with a primaryOrderId that matches the orderId on each
OrderHeader, and then looks at other things on the Shipment
record(s) corresponding.
All of this can, and should, be done with a view entity. In fact,
it must be done with a view entity so that the work is done in a
query in the database and not in a script on the app server
which is hugely inefficient, so much so that in even moderately
large systems it simply WILL NOT WORK!
*Agreed*
An addition note: looking for shipments by matching the
OrderHeader.orderId with the Shipment.primaryOrderId is not
adequate. Please change it to match the OrderHeader.orderId with
the ItemIssuance.orderId and then ItemIssuance.shipmentId with
Shipment.shipmentId. Not that there will be many records for a
single OrderHeader and Shipment combination since the
ItemIssuance really ties a OrderItem to a ShipmentItem, but that
is fine since in this case all we care about is the OrderHeader
to Shipment relationship. Why do we need this? Because it is
possible for a single Shipment to have items from different
orders on it, and simply looking at the Shipment.primaryOrderId
won't capture that... that field is only the PRIMARY orderId.
*But here the confusion is , Entries in ItemIssuance Entity is
not done when we do "Verify Pick" (only done when shipment is
created in Packed status). So Entries are not present in
ItemIssuance entity for Orders which have shipment in "Input",
"Picked", and "Scheduled" status. So IMO above given logic will
not help . Please let me know if I am wrong.*
Add a page that shows orders with the "pick sheet printed date"
field
---------------------------------------------------------------------
Key: OFBIZ-2388
URL: https://issues.apache.org/jira/browse/OFBIZ-2388
Project: OFBiz
Issue Type: Sub-task
Components: product
Affects Versions: SVN trunk
Reporter: Pranay Pandey
Assignee: Vikas Mayur
Fix For: SVN trunk
Attachments: ofbiz-2388.patch
* Add page that shows orders with the "pick sheet printed
date" field set that do not have a Shipment associated with
them that is in the "Input" or "Scheduled" statuses (should be
in Input status, but just in case Scheduled is eventually
used), sorted by the oldest date first to see the ones that
have gone the longest without being picked and verified.
* Link to new page from the PicklistOptions page.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
