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

_________________________________________

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]

Reply via email to