✨ Request: v1.3.5 (Final Django < 5 Version) with Dynamic Queue Choices in Admin Site

[DhavalGojiya]

Hi team 👋

First of all — thank you for maintaining this excellent library 🙏

I’d like to propose a small enhancement for users on Django < 5 that improves the admin interface. Currently, users can only select from static queues (default, low, high) — even if they’ve defined completely different queues in settings.py. This change would not affect the models or trigger any new migrations.

---

🧠 Context

In v1.3.4 and v1.3.3, the queue field in BaseTask is defined like this:

QUEUES = [("default", "default"), ("low", "low"), ("high", "high")]

queue = models.CharField(
    _('queue'), max_length=255, choices=QUEUES,
    help_text=_('Queue name'),
)

Previously, the queues were populated dynamically from settings.SCHEDULER_QUEUES. But that led to frequent migrations whenever queue names changed — especially problematic inside site-packages.

To solve this, static choices were introduced in v1.3.3 and v1.3.4 (👍 smart move!).

---

👥 Real-world Use Case

I’m currently working across 6 Django projects with an international team, all using your library (v1.3.4) with Django 4.2 LTS.

However, everyone on the team is facing a consistent issue:

When adding Cron Jobs or Repeated Jobs from the Django admin panel, we only see the static queues — "default", "low", and "high" — not the dynamic ones we’ve defined in settings.SCHEDULER_QUEUES.

We can’t migrate to Django 5.2 LTS immediately due to project timelines and upgrade risks. And it’s not just us — many developers in the community who rely on this library and are still on Django < 5 face the same limitation in the admin interface.

Releasing v1.3.5 with this small enhancement would be a boon for many teams, offering a smooth developer experience while staying on stable Django 4.x versions.

---

💡 Suggested Improvement (for v1.3.5)

Would you consider releasing a patch version v1.3.5 that includes:

• ✅ No changes to models (no migrations)
• ✅ Override the Django Admin form for CronTask, ScheduledTask, and RepeatableTask to load queue choices dynamically from settings.SCHEDULER_QUEUES
• ✅ Keeps the model safe and stable for Django < 5 users

---

🔧 Code Changes

Admin Class Changes

Override the get_form method in the TaskAdmin class to dynamically set the queue field choices:

# Location: scheduler/admin/task_models.py
from scheduler.settings import QUEUES

def get_queue_choices():
    return [(queue, queue) for queue in QUEUES.keys()]

@admin.register(CronTask, ScheduledTask, RepeatableTask)
class TaskAdmin(admin.ModelAdmin):
    # Rest of the admin code...

    def get_form(self, request, obj=None, change=False, **kwargs):
        queue_field = self.model._meta.get_field('queue')
        queue_field.choices = get_queue_choices()  # Dynamically set choices in model field
        return super(TaskAdmin, self).get_form(request, obj=obj, change=change, **kwargs)

Note:
No need to worry about users manually modifying the HTML <select> element to choose unsupported queue values. The library already has validation in place in the model, which ensures that only queues defined in settings.SCHEDULER_QUEUES are accepted.

---

✅ Benefits of This Approach

1. No More Migrations: The queue field with static choices (default, low, high) remains unchanged. Since the choices attribute is a Django-level feature applied to a CharField, it doesn't affect the actual database schema. Also, changes to the SCHEDULER_QUEUES dictionary in settings.py won’t trigger a database migration.
2. Dynamic Updates: The admin interface will always reflect the latest queue values from settings, ensuring better flexibility and maintainability.
3. Backward Compatibility: This change does not affect the existing database schema, making it completely safe for existing projects.
4. No Forced Upgrade: No need to upgrade to Django 5 or django-tasks-scheduler v2.x.x just yet.

---

I’d be happy to contribute a PR for this if needed. Thanks again for all your hard work and for maintaining this useful scheduler ❤️

Best regards,
Dhaval

[cunla]

This creates an additional migration

[cunla]

See past issues about it.

[DhavalGojiya]

This creates an additional migration

What I explained above has been fully tested by myself.
No new migrations are created.
We are not changing anything in models.py.

[cunla]

Please create a PR for me to review

[DhavalGojiya]

Please create a PR for me to review

Sure.

Could you please create a maintenance branch named v1.3.x from the v1.3.4 tag?
I’d like to create a new branch from it and raise a pull request.

[cunla]

done