1👍
It’s the responsibility of the view to check that the user (in request.user) has sufficient privilege to perform the requested operation. There’s no standard way for a Django object method to obtain the current user, and a programmer with access through the Django shell >>> obj.delete() has to be prevented by other means (such as the risk of losing his job). There simply is no Django logged-in user in that context, but the DB to which it has access ought not to be a production one.
Out on a limb, it is possible to disable the object’s delete() method completely by subclassing it to a no-op or to raise an exception. Deleting such an object would then require other means. Either relying on a CASCADE when some other object was deleted, or using raw SQL (the psql command, if PostgreSQL) to remove its data row from the DB table.
(I haven’t done the latter, but there are certain objects in the project I am working on which should never require deletion under any normal circumstances, and for which there are no delete views or similar. They will accumulate at the rate of around one per week in production, and removing ones which are completely stale is a problem which can safely be deferred until the year 2100 or later 🙂