- Notifications
You must be signed in to change notification settings - Fork152
Deprecation fixes and changes to the admin#308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Open
ex5 wants to merge1 commit intodjango-background-tasks:masterChoose a base branch fromex5:master
base:master
Could not load branches
Branch not found:{{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline, and old review comments may become outdated.
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
RemovedInDjango40Warning: providing_args argument is deprecatedhttps://docs.djangoproject.com/en/4.2/releases/4.0/#:~:text=providing_args%20argument%20for%20django.dispatch.Signal%20is%20removed. RemovedInDjango41Warning: default_app_confighttps://docs.djangoproject.com/en/4.2/internals/deprecation/#:~:text=default_app_config%20module%20variable%20will%20be%20removed. Admin: show creator in the task list Admin: make error icon red when there is **actually** an error, not the other way around Set default_auto_field on app level This is necessary to avoid generating unexpected migrations in projects that have a `DEFAULT_AUTO_FIELD` that differs from data type of generated `id` columns. E.g. if `default_auto_field` is omitted here and `DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'` in a project's `settings.py`, then `makemigrations` will generate a migration that will attempt to change `id` column to a new data type, recreating a table and copying its data, which is undesirable.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading.Please reload this page.
We've been using
background_tasksfor some years, after having to fork it at some point due to it being incompatible with some Django version or some deprecation.Over the years a few changes accumulated, and now that the project is actively maintained again, maybe those changes could be useful to someone else.
(Also, not having a fork and simply using the published package would be swell too.)
The changes consist of the following:
RemovedInDjango40Warning:providing_args argument is deprecated (same asFix RemovedInDjango40Warning in signals.py #252);RemovedInDjango41Warning:default_app_config (same asUpdate __init__.py #284);Admin: filter by various fields;
Admin: make error icon red when there isactually an error;
There was some confusion around the green checkmark 🟢 ✔️ being displayed when there's an error, and a red 🔴 ✖️ cross displayed when it's actually business as usual:
Set default_auto_field on app level (same asExplicitly set default_auto_field. #302);
This was necessary to avoid generating unexpected migrations
in projects that have a
DEFAULT_AUTO_FIELDthat differsfrom data type of generated
idcolumns.E.g. if
default_auto_fieldis omitted here andDEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'in a project'ssettings.py,then
makemigrationswill generate a migration that will attempt tochange
idcolumn to a new data type, recreating a table and copyingits data, which is undesirable.
If the squashed PR is problematic, I could try splitting these into separate patches.
Upd: found existing PRs about the same deprecation fixes, but since they didn't get any attention, I'll leave this one as is for now.