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 > _________________________________________ 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]
