Reverting a model rename in an environment with pre-Django 6.0 permission records leaves wrong users & groups associated

[Jacob Walls]

• Checkout Django 5.2
• Assign user 1 to have view permissions on FooModel
• Rename the model to BarModel
• Migrate

(Result: no permissions transfer to BarModel, FooModel permissions left behind in the db).

• Assign user 2 to have view permissions on BarModel
• Checkout Django 6.0
• Rename the model back to FooModel and migrate forward

Expected: ?
What user should have view permissions on FooModel now, 1 or 2?

As of #27489, which makes the permissions tag along with RenameModel operations, I think we would expect user 2. (Proposed fix PR makes it Users 1 *and* 2, but I'm interested to hear more on that.)

Actual result: User 1 has the permission on FooModel, and BarModel permissions for User 2 are left behind in the db.

Bug in f02b49d2f3bf84f5225de920ca510149f1f9f1da.

[Jacob Walls]

​PR

[Antoliny]

I think only user 2 should have the permission, and raising an error would be appropriate.
From the perspective of the person performing this operation, they would naturally expect user 2 to have the permission (considering the intent of #27489).
It feels strange that ghost data created by a bug would come back into play.
Since this issue is related to a bug in a previous version, I think being explicit would be better in this case.
When an error occurs, it would help the developer become aware of the issue.

I'm also curious to hear others opinions :)

[Clifford Gama]

I share your position, Jacob and Antoliny.

That user 2 does not have the permissions is definitely a bug in 6.0, so that needs to be fixed and backported.

Whether user 1 also ends up having the permissions should depend on whether that was the behavior before the patch in #27489 landed. If it wasn't then it would need a new-feature-like release note, meaning it cannot be backported. If it was, then it should be fixed as a regression in a new feature.

[Jacob Walls]

Thanks for the gut checks. So my understanding is that #27489 fixed the bug where permissions for a model being renamed were left stranded. So when un-renaming in Django 6, if we choose to overwrite any records stranded before Django 6, that's a bugfix and not something subject to the backward compat guarantee, since they shouldn't have been there at all. 🤔

[Clifford Gama]

All right, that makes sense. In that case maybe we want user 1 to also have the permission, since it possibly was never explicitly deleted and it should have been carried over in the model renaming. But I don't have a strong opinion about it.

[Jacob Walls]

I think my hesitation there is that if you've done a model rename in Django 5, you've started over on your permissions, and you could have made N edits. If on Django 6 you then do a model un-rename, you'd probably be pretty surprised to see some random edits from N edits ago merged in.

[Clifford Gama]

Let's make it user 2 only, then. Its the safer option. We don't want to surprise folks by giving users outdated permissions.

[Jacob Walls]

Alternative PR with PR comments annotating salient behavior changes:
​https://github.com/django/django/pull/20481

Also, some remarks about prior precedents in this area:
​https://github.com/django/django/pull/20339#issuecomment-3702832303