[Enhancement] Add a soft delete button to locations.

[dubdabasoduba]

Add a delete button to locations. If we can determine that a location is a parent or a leaf node, hide or show the delete button respectively. Attempt to delete locations when users click this button. Inform users if location cannot be deleted. Research on possibility of cascading deletes to deal with data integrity errors when attempting to delete a location that is a parent of other locations

Edit:
Changing this to be a soft delete, so we just need to change the status to inactive. A few considerations for this case:

• Adding a filter on web that filters for locations based on the status. Check fhir spec for possible values for status.
• Handling soft deletion of parent locations. Do we need to cascade the status change to children. Where to handle this on the web or on the backend? Also what should be the behavior once a parent location is activated?

[peterMuriuki]

Since we want to implement soft deletion

Possible quick wins alternatives:

• automatically hide inactive resources (on query)
• Use table sort
• scoped table filters Add single filter for active/iinactive resources

Long term fixes:

• Add table filters

[AnnieMungai]

Soft deletion - discussions with @peterMuriuki @dubdabasoduba
Option 1: - cascade delete - remove the resource from the backend. Fhir supports this cascade - delete location and everything related to it including child locations, products, etc.
QQ: Can cascade delete work for only locations.
Option 2: Do not delete - have a filter to show only active locations. Active/in-active toggle. Caveats - how would this work for a location hierarchy? Location hierarchy does not do this - we can add it as part of the server-side work.
QQ: How do we define the behavior for the nested child locations?
How does this translate to the data - when we have a deactivated parent and an active child?
Option 3: Add this to the back-end - add custom stuff to the gateway. We must be clear about the custom stuff and how it affects things.

Way forward

• Implement the de-activating option. We still need to understand the data quality impact on this. Highlight the potential problems with this and how we are going to deal with them.
• Deactivate the resource and not care about the trickle-down effect.
• Review the impact of deactivating any resource on the web- e.g. products and how other modules are going to react to this.