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

Deleting visit breaks any associated invoice to that visit #1439

Closed
MatthewDorner opened this issue May 20, 2018 · 5 comments
Closed

Deleting visit breaks any associated invoice to that visit #1439

MatthewDorner opened this issue May 20, 2018 · 5 comments
Labels
🐛bug issue/pull request that documents/fixes a bug in progress indicates that issue/pull request is currently being worked on wontfix indicates an issue/pull request will not be worked on

Comments

@MatthewDorner
Copy link
Contributor

Expected behavior:
Not sure.

Actual behavior:
Similar to #383. If you add an invoice, you must associate a visit to the invoice. If you then delete that visit, any listing at /invoices that would have included your invoice just won't render. You will get this error:
invoice visit relationship error

OS and Browser:
Ubuntu 16.04, Chromium

@MatthewDorner
Copy link
Contributor Author

MatthewDorner commented May 20, 2018

Oh, this also happens when you delete the "blank" location from an inventory item. By "blank" location, I mean the one that has no name that all your items go to when you first add / purchase them. Here, the solution may just be to not let you delete that location.

In the image below, if you click on that button and then update your inventory item, go out and try to view inventory items again, you'll have the error in this image and similar issues as above with /inventory list not rendering.

location relationship

@stukalin stukalin added the 🐛bug issue/pull request that documents/fixes a bug label May 20, 2018
@ghobs91
Copy link

ghobs91 commented Aug 19, 2018

Is the objective to delete the invoice along with the deleted visit, or to keep the invoice but have it not break?

@MatthewDorner
Copy link
Contributor Author

We wouldn't want to simply delete the invoice. Maybe a message warning like "Invoice _____ attached to this visit will also be deleted. Do you want to continue with deletion?" or refuse to delete and say "Cannot delete visit while attached invoice _____ exists." I think I prefer the latter.

We should review other models that have a similar relationship and see how it's handled there. I suspect that since there are these two, there may be a couple more that have this problem.

I also noticed the model for invoice has a belongsTo for visit, but the model for visit doesn't have any association for invoice. I wonder if that is related to the behavior.

@MatthewDorner
Copy link
Contributor Author

MatthewDorner commented Oct 19, 2018

Working on this. There's code for cascading deletions when deleting patient records, #457, but there needs to be similar code for visits.

I wouldn't have thought to delete invoices automatically when deleting visit/patient but that's how we handle it already when deleting a patient. It's not supposed to delete things entirely though, just archive them #381, but there are issues around this as well. I think some record types are being deleted entirely instead of archived.

Anyway working on it here: https://github.com/MatthewDorner/hospitalrun-frontend/tree/deletions-fix

@MatthewDorner MatthewDorner added the in progress indicates that issue/pull request is currently being worked on label Oct 19, 2018
@stale
Copy link

stale bot commented Aug 7, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix indicates an issue/pull request will not be worked on label Aug 7, 2019
@stale stale bot closed this as completed Nov 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🐛bug issue/pull request that documents/fixes a bug in progress indicates that issue/pull request is currently being worked on wontfix indicates an issue/pull request will not be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants