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

Fixes 572: validating uniqueness of a patient's friendly ID #706

Merged
merged 5 commits into from
Oct 11, 2016

Conversation

gnowoel
Copy link
Contributor

@gnowoel gnowoel commented Oct 2, 2016

I added a custom validator for dynamically showing if the display ID of a patient has already been taken. This should work when either adding or editing a patient. For the former case, we make sure the display ID is not used, and for the latter, we instead check if the display ID is only used by the current record.

screen shot 2016-10-02 at 11 46 38 pm

This is aiming to solve issue #572 partially. The remaining problem would be also validating the display ID on save, so that two people adding records simultaneously won't result in the same ID. I'll try to tackle that later as a separate task.

I added a custom validator because it seems ember-validations does not allow promises in an inline one.

Please correct me!

cc @HospitalRun/core-maintainers

@gnowoel
Copy link
Contributor Author

gnowoel commented Oct 5, 2016

If two users are adding patients at the same time, both records would get the same friendly ID. To prevent duplicates, I added a new commit to force revalidating before saving a patient. So, if the ID has been taken, we'll see an error message in a modal dialog.

screen shot 2016-10-05 at 9 24 37 pm

Some rare race conditions might still occur because the enforcement happens in the application level, not the database. But considering the friendly ID is not something we use to uniquely identify the records, perhaps the solution is good enough now.

What do you guys think?

@gnowoel gnowoel changed the title Validate uniqueness of patient display ID while editing the form Fixes 572: validate uniqueness of patient display ID while editing the form Oct 5, 2016
@gnowoel gnowoel changed the title Fixes 572: validate uniqueness of patient display ID while editing the form Fixes 572: validate uniqueness of patient friendly IDs Oct 5, 2016
@gnowoel gnowoel changed the title Fixes 572: validate uniqueness of patient friendly IDs Fixes 572: validating uniqueness of a patient's friendly ID Oct 5, 2016
@jkleinsc
Copy link
Member

jkleinsc commented Oct 5, 2016

@gnowoel thanks for the PR. I have been thinking about this a bit and I think we need to go in a slightly different direction. Here is what I am thinking:

  1. The patient id should not be an editable field. This reduces the complexity by not allowing users to pick an already used id and we do not need to check the id on updates.
  2. When saving a new record, in the beforeUpdate we need to validate if the id has already been used. If it has, grab the next available sequenced id and save the record with that.

cc @jglovier @tangollama

@gnowoel
Copy link
Contributor Author

gnowoel commented Oct 5, 2016

Sounds good to me :)

@gnowoel
Copy link
Contributor Author

gnowoel commented Oct 7, 2016

@jkleinsc Just added a new commit. When saving a patient, now it will automatically use the next available one if the suggested friendly ID has been taken (i.e. no error messages). The form field is not disabled, because I'm not sure about the UI part. Hope I'm at least in the correct direction.

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 Given the change in requirements, I would just move the uniqueness check to beforeUpdate in the controller.

@@ -547,6 +548,14 @@ export default AbstractEditController.extend(BloodTypes, ReturnTo, UserSession,
});
},

beforeUpdate: function() {
Copy link
Member

Choose a reason for hiding this comment

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

@gnowoel instead of validating through the model, you should just move the uniqueness code here. Also, it should only run when the model is new (eg if (this.get('model.isNew')

The problem with the code the way it is right now if the model is invalid for other reasons (say for example the user didn't enter a first name, it would change the id).

@@ -90,7 +90,8 @@ export default AbstractModel.extend(DOBDays, PatientName, {
}
},
friendlyId: {
presence: true
presence: true,
uniqueness: true
Copy link
Member

Choose a reason for hiding this comment

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

Remove the validation from the model and just do it in the controller instead.

};

this.set('isValidating', true);
database.queryMainDB(query, 'patient_by_display_id')
Copy link
Member

Choose a reason for hiding this comment

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

Move this code to the controller.

@gnowoel
Copy link
Contributor Author

gnowoel commented Oct 7, 2016

@jkleinsc Thanks for your guidance. I updated the code again. Please correct me.

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 Looks good to me.

@jkleinsc
Copy link
Member

@gnowoel I think this PR is complete if you make one more change. I mentioned disabling the friendly id from editing, but I realized all we need to do is remove the field from the form completely because it is already displayed in the header.

So, to complete this PR can you remove this line?
https://github.com/HospitalRun/hospitalrun-frontend/blob/master/app/patients/edit/template.hbs#L132
{{em-input property="friendlyId" label=(t 'labels.id') class="form-input-group required test-id"}}

@gnowoel
Copy link
Contributor Author

gnowoel commented Oct 11, 2016

@jkleinsc Thanks for your precise instruction. I have removed the ID field completely from the patient form in this follow-up commit.

@jkleinsc
Copy link
Member

@gnowoel thanks for finishing up this PR! Looks good to me, so I'll merge it in.

@jkleinsc jkleinsc merged commit cb5bb24 into HospitalRun:master Oct 11, 2016
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