Make AUDITLOG_LOGENTRY_MODEL swappable

[Jackevansevo]

Fixes #804

See issue description:

Prevents a dangling auditlog_logentry from conflicting with the flush management command.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.33%. Comparing base (3f255a0) to head (b0c7600).
⚠️ Report is 16 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #805   +/-   ##
=======================================
  Coverage   96.33%   96.33%           
=======================================
  Files          35       35           
  Lines        1256     1256           
=======================================
  Hits         1210     1210           
  Misses         46       46           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[2ykwang]

Thanks @Jackevansevo for the PR! Looks like fresh installs are covered now.
do we also need to address existing users who already have an auditlog_logentry table?`

[Jackevansevo]

Thanks @Jackevansevo for the PR! Looks like fresh installs are covered now. do we also need to address existing users who already have an auditlog_logentry table?`

Is a good point.

I think our choices are either:

1. Attempt to delete / cleanup auditlog_logentry in apps where AbstractLogEntry is used
2. Do nothing

I was learning towards 2.

• Less risk / easier to review/test

• If users haven't been hit/effected by the behaviour until now their experience doesn't change.

• I imagine a lot of people effected would have generated their own one-off migrations to work around this anyway. We could advise/recommend this in the docs/release notes.

If I get a steer from a maintainer I'm happy to look at doing 1. and get this across the finish line.

I'd probably want some safety checks around the migration (i.e. only drop the table if there's no records present), to avoid a situation where upgrading the package inadvertently wipes data.

[yaakovLowenstein]

I'm having the same issue. Any chance this will be merged?

[2ykwang]

@Jackevansevo sorry for the delayed response.

I tested the scenarios below, and everything works as expected:

Setup	Result
Existing + default model	No changes
New + default model	Default table is created
New + custom model	Only the custom table is created; flush succeeds
Existing + custom model	Existing default table remains

I agree with 2.

Could you also add an entry to CHANGELOG.md for this change?

Thanks again for your contribution!