docs(devops): Name the feature flag serializer schema components uniquely

[louzolo123]

📚 Summary

Continues #361 with the devops feature-flag serializers (the Entity group is already merged), prioritising the non-feature-flagged /feature_flag routes as you asked.

These serializers resolved to colliding OpenAPI component names:

• feature_flag, public_feature_flag and software_enable_feature_flag shared the generic View / Model (and the derived PaginatedViewList);
• centurionaudit_featureflag and centurionmodelnote_featureflag both declared FeatureFlagView / FeatureFlagModel, so they collided with each other.

Each serializer now has an explicit component_name following the <model class name><type>Serializer convention:

Serializer file	Model	Names
feature_flag.py	FeatureFlag	FeatureFlagBase/Model/ViewSerializer
public_feature_flag.py	FeatureFlag (public)	PublicFeatureFlagViewSerializer
software_enable_feature_flag.py	SoftwareEnableFeatureFlag	SoftwareEnableFeatureFlagBase/Model/ViewSerializer
centurionaudit_featureflag.py	FeatureFlagAuditHistory	FeatureFlagAuditHistoryModel/ViewSerializer
centurionmodelnote_featureflag.py	FeatureFlagCenturionModelNote	FeatureFlagCenturionModelNoteModel/ViewSerializer

python manage.py spectacular --api-version v2 warnings drop from 226 to 209 (67 -> 60 unique), with no new collisions.

One naming call I'd like to confirm: public_feature_flag serialises FeatureFlag too, so I named it PublicFeatureFlagViewSerializer to keep it distinct from the main one - happy to change if you'd prefer something else.

The Git-repository serializers (behind the 2025-00001 flag) are left for a follow-up PR.

🔗 Links / References

• Part of fix drf spectacular warnings #361

👷 Tasks

• 🔍 spectacular warnings reduced (226 -> 209), no new collisions
• 🧪 devops feature-flag serializer tests pass locally (schema-metadata-only change; no test references the old component names)

🔍 Code Reviewer Tasks

• Feature Release ONLY 🟥 Squash migration files 🟥
  Multiple migration files created as part of this release are to be sqauashed into a few files as possible so as to limit the number of migrations

• 🧨 Contains breaking-change Any Breaking change(s)?

  Breaking Change must also be notated in the commit that introduces it and in Conventional Commit Format.

  • 📓 Release notes updated

• 📘 Documentation written

  All features to be documented within the correct section(s). Administration, Development and/or User

• 🏁 Milestone assigned

• ⚙️ 🧪 Functional Test(s) Written

• 🧪 Unit Test(s) Written

  ensure test coverage delta is not less than zero

• 📄 Roadmap updated

[jon-nfc]

I'll properly review tomorrow as I'm about to finish up for the day.

Of note, is the commit. We use Conventional Commit formatting which is used to build the change log (see CHANGELOG.md) and bump per SemVer. As such, one thing is one commit. not one category of things is one commit as you have done here. When doing a commit its always from the perspective of the end-user.

In the case of this PR, I would expect to see one commit per file (per serializer). the noun to use in this case will be docs not feat or fix as what is actually being added is for the swagger UI.

[jon-nfc]

One naming call I'd like to confirm: public_feature_flag serialises FeatureFlag too, so I named it PublicFeatureFlagViewSerializer to keep it distinct from the main one - happy to change if you'd prefer something else.

Key here is that you understood intent, which ultimately enabled you to move forward without having to wait on me. Happy with that and you have used what could be easily extended for all public serializers.

Code work is GTG, however the commits issue needs to be resolved.

FYI, additionally for the commits, the description/body section should not be used to describe the work done. It's intent is to provide further info if required in relation to the context of the commit. The work that was done as part of the commit is the diff and reasoning/planning is recorded in the PR and any task tickets, hence the requirement for the footer refs.

I'll run the CI jobs now, so at least by the time you are next working on this PR, you'll know if there are any major errors.

update: Unable to run ci.yaml as no job exists, so I'll have to wait till post your next push.

[louzolo123]

@jon-nfc thanks for the review and the guidance on the commits.

Reworked the history and force-pushed:

• One commit per serializer (5 in total) instead of one lumped commit.
• Changed the noun to docs, since the change is metadata for the Swagger UI rather than a behavioural fix/feat.
• Dropped the descriptive body; each commit now carries only the ref: #361 footer.

Good to know on the public serializer naming being extendable to the other public serializers - I'll keep that pattern in mind.

Ready for another look when you get a chance.

[jon-nfc]

GTG, pending the CI run.

I'll merge when CI passes.