Thanks for this patch 👍 Simon's comment is not addressed.

@felixxm created autodetect for changing bases but found another issue with model bases, which is kinda blocking some of AlterModelBases functionality. I can't find a ticket for that, should I address it in that PR?

Steps to reproduce:

1. Create 2 models that have models.Model in bases:

class A(models.Model):
    pass
class B(models.Model):
    pass

2. Try to apply multi-table inheritance to one of them:

 class B(A):
    pass

Results:
You will get exception:
django.core.exceptions.FieldError: Local field 'id' in class 'B' clashes with field of the same name from base class 'A'.
btw, if you have more than one model in bases, you will get the error also, even if it's a freshly created model.

I can see 2 possible solutions:

1. Rename ID field, change it to models.OneToOne with primary_key and make sure the user will prepopulate that field somehow.
2. Just raise the exception and ask the user to write migration manually.

hiya @Zorking and happy new year. Distinct issue deserve distinct tickets! 👍🏻 This allows folks who monitor tickets a chance to vet your issue and accept it or ask for clarification. If your issue is accepted you can claim it and fix here; or if your fix is lightweight you might choose to fix in a separate PR that can get merged fast. Best, Jacob

hiya @Zorking and happy new year. Distinct issue deserve distinct tickets! 👍🏻 This allows folks who monitor tickets a chance to vet your issue and accept it or ask for clarification. If your issue is accepted you can claim it and fix here; or if your fix is lightweight you might choose to fix in a separate PR that can get merged fast. Best, Jacob

Hi, @jacobtylerwalls !

The issue was created 6 years ago and the ticket is in detail of the PR.

I already tested the fix in the production of the project that I worked on, worked great.

Should I change the PR name to something different or add some tags?

Ah, I was referring to the comment directly above where you said you identified a second issue without a ticket.

@jacobtylerwalls got it!

Is it worth spending time with? Maybe I didn't get the workflow right, but the PR and the ticket look kinda dead.

Short answer is yes. Long answer is that some new Django contributors have some trouble getting used to the setting Needs... flags on the ticket to No to get in the patch review queue. I can recommend you set those flags once we get this other issue to no longer be blocking! Cheers.

@jacobtylerwalls I created the ticket.

once we get this other issue to no longer be blocking!

The issue is not blocking the current fix, it's just limiting it a bit. AlterModelBases will remove model inheritance, but can't be used in order to actually alter all possible model bases (add new, patch, etc.). That is what I meant by blocking some of the functionality.

Super. Then if in your judgment this patch is ready for review please set all the Needs... flags in the ticket to no.

Closing due to inactivity.

What? No, please reopen this, this is an insanely important thing to fix =(

Even if the original PR author isn't available anymore, this is the kind of thing that deserves going "let's fix up the last bits ourselves and land it". The thing it fixes has been a problem for every single Django installation at one point or another, and no one should have to do this.

@Pomax Feel-free to check comments and prepare a new patch.

If I had the skill, I would, but this is exactly the thing I don't have the skills for to the point where I had to bounty off 500 rep on Stackoverflow just to get help even getting a workaround. Having the team take this one on instead of relying on external contributor at this point in the PR is most definitely worth the team's time given what it fixes (and how long that bug's been the case).

I'd pay you to do that, but Django does not accept funds for specific issues, so the only agency I have here was an SO bounty reward, and SO rep is not a currency I can throw at people to actually finish this PR even if I wanted to (which I do).

Having the team take this one on instead of relying on external contributor at this point in the PR is most definitely worth the team's time given what it fixes

The team is external contributors and your feeling about the urgency of fixing this particular issue is shared amongst all Django users affected a particular issue disrupting their workflow. In other words nothing makes this issue special compared to the hundreds of confirmed bugs and the most productive way of getting it fixed it to commit time to making the few remaining adjustments brought up above as their is no paid contributors actively fixing bugs that aren't issues affecting Django releases (regressions, security issues)

Closing inactive PRs is just a way for fellows to manage the large number of changes requests received by the community in a way that ensures the sustainability of the project in terms of code quality and maintainability. If a developer proposing non-trivial changes is not responsive during the review process it's likely that they also won't be if their changes happen to introduce a regression that the limited number of volunteers and the fellows will have to figure out a solution for or simply revert the patch.

While true, what does make it special is the fact that there already is a PR that's 95% of the way there, based on the comments? As opposed to hundreds of confirmed bugs that don't have any patch code written yet.

@Zorking are you still on github at all? If so, could I convince you to finish this PR?