I've recently started working on a legacy application that frankly doesn't do all that it should. It's lacking a lot of features, has barely any administration capacities and doesn't check half the data it should.
As such, it's very easy for users to do something stupid and get stuck. "Oops, I added this item of the wrong type to this thingie and now it won't let me remove it". Indeed, the application should have checked for this, but allowed adding the wrong item. And now, when it comes to deleting the wrong item, it becomes extremely protective and refuses that anything be removed.
Problem is, the clients (who are actually users within the company) don't care much for that. They need the application to hold the real-world data as it should be, so they ask the developers to "fix it" by changing the data. In this example, deleting the wrong item. In other cases, it will be reassigning items to different parents, fixing various values, etc...
Since the application has almost no admin GUI, everything ends up being done directly in the database (augh!), risking even more issues down-the-line unless you know exactly how it works (which no one really does considering the massive application).
Ultimately, it feels like the database has become a huge Excel file that devs edit day by day at the whims of the clients, because of failures of the application.
It's obvious to me that fixing the application to avoid such situations should be top priority, but it seems the clients prefer asking for a lot of new features instead and it's accepted as such.
What can a developer do in such a situation? Is it even possible to refuse DB edits in favor of fixing things? There are so many bugs that it feels like they're never going to wait that long...