Open lboeman opened 5 years ago
I think I'm OK with just orphaning any forecast/obs. Any new thoughts @lboeman?
That sounds fine to me. I think protecting against deleting an in-use site is probably worth while, either through a check at the API or just with a confirmation message on the dashboard. I think maybe assuming someone programming against the API would know to check is fine.
I guess the problem with checking if a site is in use is that the person deleting said site may not have permission to view whatever is using it. So maybe we should just make the warning message when deleting the site in the dashboard say that other forecasts/obs will be orphaned
Ahh good point. I agree.
While working on data sharing updates I discovered an issue with organization deletion Steps to reproduce:
Organization A grants read access to a site for some user in Organization B
A user from another organization submits a forecast for that site.
Attempt to delete Organization A fails due to the Foreign Key constraint created by the forecast added by Organization B.
It seems that an Organization should always be able to remove themselves from the framework. With that in mind, here are some possible solutions:
When deleting a site, delete all observations and forecasts related to that site, regardless of owner. We'd need to establish some End User documentation that clearly defines the permission implications of submitting data to a site owned by another organization. It does seem difficult to reflect the ability to delete these objects with permissions, e.g. might need a new role and permission need to be made for the Site's organization for Each provided forecast/observation.
If other organizations have forecasts or observations for the site, create a copy of that site, perhaps under the 'Unaffiliated' organization.
Orphan the Observations and Forecasts from other organizations. It seems like orphaned observations and forecasts are otherwise useless without the metadata provided by their associated site.