Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Fixes #485: Suggest next patient ID based on the largest number used #667

Merged
merged 2 commits into from
Sep 28, 2016

Conversation

gnowoel
Copy link
Contributor

@gnowoel gnowoel commented Sep 24, 2016

The suggested patient ID keeps getting incremented even if we cancelled the new patient form. This problem should be related to issue #485 and more info can be found in #485 (comment).

I try to solve the problem by saving the current sequence rather than the next available one. We start checking from the current sequence when preparing a new patient form. The value would be incremented and saved only if it has already been taken. So, no matter how many times we click the cancel button, the suggested patient ID would always be the same.

Please correct me!

cc @HospitalRun/core-maintainers

This happens only when the patient `friendlyId` is larger than the
saved sequence value.
@gnowoel
Copy link
Contributor Author

gnowoel commented Sep 25, 2016

Added a commit to solve the first half of the problem mentioned in #485 (comment). That is, when saving a patient, update the sequence accordingly if the patient friendlyId is larger.

@gnowoel gnowoel changed the title Keep track of the current friendlyId rather than the next available… Fixes #485: Suggest next patient ID based on the largest number used Sep 25, 2016
Copy link
Member

@jkleinsc jkleinsc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnowoel thanks for the PR! Looks good to me. Changing to this approach introduces the issue that two users could concurrently get the same sequence, but I think perhaps we should address that in #572.

I also like the fact that this addresses the issue of users canceling new patient creation which was eating up sequences.

@jkleinsc jkleinsc merged commit ad0e405 into HospitalRun:master Sep 28, 2016
@gnowoel
Copy link
Contributor Author

gnowoel commented Sep 28, 2016

@jkleinsc Thanks! You're correct. We don't lock the sequence any more, so it's required to also address #572 to prevent duplicates.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants