That would make the most sense, and in our 1.10 refactoring of OrderService, I'm sure we'll do something like that. But our goal here is just to fix one specific bug in the least intrusive way possible. (We don't want to have Mykola drastically refactor everything, do a lot of work to backport that, and then throw all that work away in the 1.10 OrderService rewrite.)
To be very specific, there are two options on the table: 1. Change the meaning of CURRENT (in the spectrum of ANY, CURRENT, COMPLETE, NONVOIDED) so that CURRENT also includes scheduled future orders. 2. Add one more option for CURRENT_AND_FUTURE. Given people's feedback so far, I'd lean towards #2. But mainly the question is: is anybody on this list currently using the OrderService methods that take that enum, in some module of theirs, who has an active preference? -Darius On Tue, Feb 28, 2012 at 6:49 PM, Burke Mamlin <[email protected]>wrote: > Are discontinued orders considered COMPLETE? > > Why not PAST, CURRENT, and FUTURE with the ability to ask for any > combination of the three? > > -Burke > > > On Tue, Feb 28, 2012 at 5:15 PM, Michael Seaton <[email protected]> wrote: > >> ** >> I don't think I agree with this. My normal expectation would be that >> CURRENT means any orders with a startDate <= today and a discontinuedDate >> or autoExpireDate > today. And I don't see why changing this behavior >> (which is what people currently expect) is better / less intrusive than >> adding another CURRENT_AND_FUTURE enum value that handles this use case. >> So I would advocate for the new enum option. >> >> Mike >> >> >> >> On 02/28/2012 03:17 PM, Darius Jazayeri wrote: >> >> As a bit of background, the current enum options are: >> ANY >> CURRENT >> COMPLETE >> NOTVOIDED // I sure hope that the other three do not include voided >> orders... >> >> Given that, it seems fair to reinterpret CURRENT as "not completed", >> and include existing orders that are scheduled to start in the future. >> >> (Also, the whole OrderService is set to be completely refactored soon, >> so we're looking for an easy solution, not a huge one.) >> >> -Darius >> >> On Tue, Feb 28, 2012 at 11:59 AM, Mykola Vorobey <[email protected] >> > wrote: >> >>> Hi devs, >>> >>> After a long design discussion on >>> TRUNK-2619<https://tickets.openmrs.org/browse/TRUNK-2619>issue, I hasten to >>> inform all of you who are working with core >>> *org.openmrs.api.OrderService* class, that we're planning to slightly >>> change the meaning of ORDER_STATUS.CURRENT enum value. For now, this >>> element means that the patient is considered to be currently on given >>> order. So, if you fetch patient's orders, with passing ORDER_STATUS.CURRENT >>> as parameter, you receive only current orders of given patient. >>> But, we are planning a bit extend the meaning of this element. >>> Thereafter you will receive current both orders and future scheduled >>> orders, when use ORDER_STATUS.CURRENT as parameter within methods of >>> OrderService. >>> We ask all of you *if that change can break things for your modules*? >>> And if this can break out your modules logic, please, report me directly >>> right here. >>> Also, as alternative way we are considering adding of new order status - >>> CURRENT_AND_FEATURE. It can be treated as safer way, but it has a bunch of >>> peculiarities and we do not think it's necessary to add it. >>> >>> Best, Mykola Vorobey >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
