I’ve created some locations for test purposes (I’m fixing a test case) with the JAVA Rest API.
I’d like to clean them and either manually or via a rest call, I can’t delete them (my location are named Location-xxxxxxx), why? Maybe the screenshot helps.
Thank you in advance
I assume this is because you have created other data (for example an
encounter) that references the location.
We generally have not included “force cascading delete” functionality in
the UI. (It’s only sometimes implemented in the API.)
-Darius (by phone)
Unfortunately I haven’t created any other data.
Does your location have any tags?
Neither, nothing guys.
Look at the following screenshot for details
Can you share the tomcat log at pastebin.com?
I’d like, I don’t know how to log on the qa-refapp server (I was trying my test against this server).
Can i look at the full REST call details?
sorry for my late delay, I’ve submitted the code that I used to create a location via REST API.
The method does nothing extraordinary, it calls the TestLocation class already available in TestBase.java
I’ve used the method in one of the test, actually since I can’t delete the location, I’ve commented it
Look at lines 42 - 47 in the following code
To delete a location, I’ve implemented the permanentDelete method in TestData class, which at least for the resource location fails.
Trying to recap:
- createLocation successfully create a location (this method is available to all test classes, like ManageProvideSchedulerTest)
- permanentDelete fails to delete the location previously created at point 1. This method comes in handy for the test teardown.
If you try to delete the location from the system administration page, you still have a failure.
This is the error which happens at the database level when you try to delete that location:
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (openmrs.appointmentscheduling_appointment_block, CONSTRAINT appointment_block_location_id FOREIGN KEY (location_id) REFERENCES location (`ocation_id))
Does that help?
Since I don’t know the database schema, the error is not clear to me.
It seems that the location I’m trying to delete (appointment_block_location_id) has a foreign key location_id. I have to delete location_id before deleting appointment_block_location, but I do not know how I created the location_id.
Another strange thing is that I manged to delete some locations created always in the same way
An hypothesis was that I was trying to delete a location used in an appointment, but for sure some ot them have no appointment (for instance TEST811579).
Can you check the tables, I mean the row?
Yes some locations have no appointments and hence are deletable.
This particular location has a row in the appointmentscheduling_appointment_block table where the provider_id is NULL, because this column is nullable.
And in turn this row is referenced by two rows in the “appointmentscheduling_block_type_map” table. So it also cannot be deleted until these two are deleted.
I think, I can reproduce the error.
- Create a new location from the page http://qa-refapp.openmrs.org/openmrs/admin/locations/location.list. Type only the name, no tags or other info.
- Go to http://qa-refapp.openmrs.org/openmrs/appointmentschedulingui/scheduleProviders.page
- Create an appointment with location at point 1
- Delete the appointment
- Go to the page http://qa-refapp.openmrs.org/openmrs/admin/locations/location.list
- Delete the location It should be possible because there are no appointments.
Unfortunately the test fails at step 6. My guess is when we delete an appointment, the
appointmentscheduling_block_type_map is not updated accordingly, thus we have a sort of
Maybe, you can verify my scenario by looking at the database while repeating the test scenario.
Additionally we should open an issue, shouldn’t I? if so, I’ll do it later on.
I was able to easily reproduce this locally using the steps you described. So yes go ahead and create a ticket. When an appointment is purged, it should delete the relevant rows from their related tables.
I moved it to the appointment module project. Do you wanna work on it?
thank you for your offer to work on the module application, to tell the truth
I have experience mostly on testing, in the past I worked as a sw developer, but
now I prefer to work on the verification side. Hence, if there are tasks in this
specific module project, you can count on me
By the way, pleas can you merge the branch RA-1320 (if my submission is fine with the reviewers)
I’d like to fix other things in the openmrs-distro-referenceapplication project during the next days.
There are a couple things that are going on here:
First, as stated, this is not a bug. Deleting an appointment should not affect the underlying appointment block. A appointment block specifies a range time a particular provider is available at a specific location is available for appointments. So, even if you delete a specific appointment in that time frame, the block is still available, and therefore you shouldn’t be able to delete location without first removing all associated blocks (which is set up on the Manage Provider Schedules page, I believe)
However, even doing this, you will probably see the same issue, because I suspect the appointment scheduling UI module only voids appointment blocks and appointments when you delete them, it does not purge them. A void is a “soft” delete that marks that element as “voided”, but keeps the row in the database, along with all it’s key connections. So you cannot (and should not) be able to purge a location from the DB if there are any voided metadata still linked to it. (You should be able to retire it though).
However, that being said, I don’t think there is any way to currently “purge” an appointment or an appointment block via the UI. We may want to look into adding this functionality.
@mogoodrich you are correct. There is no way to purge from UI. Only thing we can do is to void them. Or else, when user delete location, all related records should be deleted automatically. But according to my knowledge it’s impossible.