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] <mailto:[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
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[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]
