Track required-field mismatches between Dojo OpenAPI schema and Dojo Django models

[fopina]

In DefectDojo, there are several inconsistencies between Django model required fields and the required fields in OpenAPI schema provided.

Also, there are validators that enforce rules that are not met by the application.

These, not only prevent pushing data that is valid via UI/parsers but also completely breaks pulling data created by those (UI/parsers) as model parsing validations fail.

This is an open issue to track some of them and address them as possible.

Later, it can be used to try to address it in an issue (or PR) to DefectDojo.

[fopina]

Note to consider is the pagination "fix" done by tweak_openapi.py

[fopinappb]

Several items taken from patching these API models in a different project:

    # FIXME: monkey patch these types for pydantic validations - why isn't the schema aligned with actual data requirement??
    # notes added via UI do NOT get a note_type...
    ModelPatcher(Note).make_field_optional('note_type')
    ModelPatcher(NoteHistory).make_field_optional('note_type')
    # these were made optional also because of some API method that asks for a Note object to *create* one (id/etc all not existing)
    ModelPatcher(Note).make_field_optional("id")
    ModelPatcher(Note).make_field_optional("history")
    # patch cvssv3 regexp - enforcing something not met by any core parser
    ModelPatcher(Finding).disable_validator('cvssv3_validate_regular_expression')
    # this actually comes from being added in 2.46.2 schema - introduces the topic on how to deal with this "newly introduced required fields", even if they are really required in DB
    ModelPatcher(DeltaStatistics).make_field_optional('untouched')
    # FIXME: how does this happen? Dojo version or some serious inconsistency?
    # recommendation - Value error, must be one of enum values ('A', 'V', 'M', 'F', 'T') [type=value_error, input_value='Fix (The risk is eradicated)', input_type=str]
    # decision - Value error, must be one of enum values ('A', 'V', 'M', 'F', 'T') [type=value_error, input_value='Accept (The risk is acknowledged, yet remains)', input_type=str]
    p = ModelPatcher(RiskAcceptance)
    p.disable_validator('recommendation_validate_enum', apply=False)
    p.disable_validator('decision_validate_enum', apply=False)
    p.apply()
    # FIXME: disable enum validator as we have custom parsers - allow this in the upstream lib somehow...
    ModelPatcher(ImportScan).disable_validator('scan_type_validate_enum')
    ModelPatcher(ReImportScan).disable_validator('scan_type_validate_enum')
    ModelPatcher(FindingRelatedFields).make_field_optional('jira')
    # patch - why is '' an invalid status? should it be None instead? server side issue? migrations issues?
    ModelPatcher(Engagement).disable_validator('status_validate_enum')

[fopina]

This issue also related to #31

[fopina]

user_profile_api.retrieve() on demo.defectdojo.org with user admin

phone_number
  Value error, must validate the regular expression /^\+?1?\d{9,15}$/ [type=value_error, input_value='', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/value_error
cell_number
  Value error, must validate the regular expression /^\+?1?\d{9,15}$/ [type=value_error, input_value='', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/value_error

[fopina]

DefectDojo/django-DefectDojo#12440 solved cvss validator topic

And according to PR, these validations are meant to validate both form and API but not parsers?