Skip to content

[FIX] -- admin site queue choices now use user-defined settings instead of hardcoded values. #282

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: v1
Choose a base branch
from

Conversation

DhavalGojiya
Copy link
Contributor

@DhavalGojiya DhavalGojiya commented Jun 25, 2025

Fixes: Issue #278

This PR resolves a bug present in versions v1.3.3 and v1.3.4 of django-tasks-scheduler.

🛠️ What’s Fixed

The queue choices in the Django admin task creation form are now loaded dynamically from user-defined settings (RQ_QUEUES or SCHEDULER_QUEUES), instead of using hardcoded values like "default", "low", and "high".


✅ Working Screenshot

You can view the fix at:
/admin/scheduler/crontask/add/
/admin/scheduler/repeatabletask/add/
/admin/scheduler/scheduledtask/add/

Queue Choices Screenshot


⚠️ Validation Behavior

If a user attempts to submit a value that isn’t defined in their settings, a validation error will appear.
Validation Error Screenshot


🧪 Queue Execution Confirmation

The task scheduled under the "alerts" queue was successfully picked up and executed by the respective worker, confirming that dynamic queue selection is functioning as expected.
Worker Run Success


📌 What’s Next After This PR Is Merged

  • Update pyproject.toml version (e.g. 1.3.5) and update README.md if necessary
  • Create a new GitHub tag: v1.3.5
  • Publish a new PyPI release for v1.3.5

…ad of hardcoded values.

- Fixes issue django-commons#278.
- Replaces static choices like "default", "low", and "high" with dynamic values from RQ_QUEUES or SCHEDULER_QUEUES.
- Keeps the admin UI consistent with project-specific configuration.
@cunla
Copy link
Member

cunla commented Jul 1, 2025

Thanks for doing this, are you planning to do the additional work required to get it published?
I do not wish to maintain a v1.

@DhavalGojiya
Copy link
Contributor Author

Thanks a lot for the review and feedback!

Yes, I’m happy to help with the remaining work:

I can prepare a PR to update the pyproject.toml version and make any necessary README changes for v1.3.5.

However, since I’m working from a fork, I won’t be able to create or push tags (e.g. bumping the version to v1.3.5) or publish the PyPI release directly to the main repo. Would you prefer to handle the tagging and release after merging the PR?

Also, I’m open to helping with critical fixes for v1 if needed, although I understand your focus is on the latest version releases and not maintaining this one. Let me know how you’d like to proceed!

- Update pyproject.toml version to v1.3.5
- Add changelog entry for admin queue choices fix (django-commons#278)
@DhavalGojiya
Copy link
Contributor Author

@cunla

✅ Version bumped to v1.3.5 and changelog updated!

  • I’ve updated the version in pyproject.toml to 1.3.5.
  • I added a note in the changelog describing the fix for the admin queue choices issue.

Let me know if you’d like any further tweaks before tagging or releasing! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants