Make extra JIRA Issue Type work without database schema migrations (DD_JIRA_EXTRA_ISSUE_TYPES )

[valentijnscholten]

Is your feature request related to a problem? Please describe
Currently changing the list of available JIRA Issue types via DD_JIRA_EXTRA_ISSUE_TYPES will trigger database schema migration in Django. This is not ideal, especially since #11638.

Describe the solution you'd like
This least if configuration data and should not be tied to the database schema. I suggest to put the issues types in their own table where they can be managed via the UI/API. A foreign key can be used to guard integrity.
This change may involve a (one-time?) data migration that reads the DD_JIRA_EXTRA_ISSUE_TYPES and puts them into the new table.

Describe alternatives you've considered
Adding back in the makemigrations will sometimes solve it, but will leave users with a migration chain that diverges from the official builds.

Additional context
A workaround for users wanting to add extra JIRA issue types is to:

• set DD_JIRA_EXTRA_ISSUE_TYPES as documented
• also add the extra issue type(s) to the list in 0182_alter_jira_instance_default_issue_type and to 0027_jira_issue_type_settings.py. This requires a rebuild of the django container / services using that, i.e. uwsgi, celerybeat, celeryworker, initializer.

Raised on Slack recently: https://owasp.slack.com/archives/C2P5BA8MN/p1739483830256399

[valentijnscholten]

Maybe something like this could be a temporary quickfix:

    operations = [
        migrations.AlterField(
            model_name='jira_instance',
            name='default_issue_type',
            field=models.CharField(choices=settings.JIRA_ISSUE_TYPE_CHOICES_CONFIG, default='Bug', help_text='You can define extra issue types in settings.py', max_length=255),
        ),
    ]

[valentijnscholten]

Discussed with @Maffooch we might as well remove the choices from the model and validate in code. The choices aren't passed on to the database as enums/constraints anyway, so all this migration stuff is just a bit of a show.

[izcoN]

At the moment the workaround for that issue is to comment line with your custom field in DefectDojo/docker/extra_settings/local_settings.py make docker compose build with new change, after that migration will work, you can again uncomment your custom field and build again and it works in our case