Possible bug: internal linking to past pet-owner relationships

Submitted by Guest on Wed, 16/01/2013 - 00:47

General developer's discussion

Affects version 1.6.

This one is a little obscure, but will likely confuse some users. Here's the scenario:

Worklist task created for Owner A and Patient P at time 1.
Patient P owner changed to Owner B at time 2.
Worklist task attempted to be modified at time 3. <- problem here.

It appears that the status of the task won't change unless the current Patient-Owner relationship is represented in the task. It took me about a half hour to figure this out because there was nothing in the logs. To "correct" the situation, we simply updated the Worklist task to also contain Owner B and Patient P. However, that information is incorrect because the ownership change information happened on the very day of the endTime for the task (i.e. the task was more appropriate w/ Owner A and Patient P.)

Anyway, it's something to think about. Ideally, we would have been able to mark this task as closed without having to update to (B,P), but could have left it as (A,P).

Cheers, Paul

Re: Possible bug: internal linking to past pet-owner ...

Submitted by tanderson on Thu, 07/02/2013 - 16:50.

I suspect this will also occur for appointments and invoices.

When you attampt to save anything that has both a patient and customer, the patient must have an active association to the customer or validation will fail.

This is the desired behaviour most of the time; it only falls down when you change ownership and need to edit a task/appointment or invoice subsequently.

I guess I could change it to allow customer/patients that have any association i.e active or inactive. Not sure if that creates other issues though?

-Tim

Re: Possible bug: internal linking to past pet-owner ...

Submitted by pstadler (not verified) on Fri, 08/02/2013 - 00:09.

Interesting. I'm trying to imagine a scenario where this could be detrimental. My first instinct is that allowing validation on inactive relationships at least preserves the need for some relationship. Can you think of a real-world scenario where this should not be permitted? None come to mind for me after thinking on it for a few minutes.

Cheers, Paul