fix(access): Give the entity Base serializers unique schema component names

[louzolo123]

📚 Summary

First slice of #361, scoped to the Entity serializer group as suggested by @jon-nfc.

The BaseSerializer classes in entity_company, entity_person and entity_contact had no explicit component_name, so drf-spectacular resolved them to the same EntityBaseBase component as access.serializers.entity.BaseSerializer, producing "identical names, different identities" warnings. Each now carries a model-suffixed component_name (CompanyEntityBaseSerializer, PersonEntityBaseSerializer, ContactEntityBaseSerializer), matching the existing Model/View serializer naming in these files.

• python manage.py spectacular --api-version v2 warnings: 71 -> 68 (the three EntityBaseBase collisions removed, no new warnings introduced).
• No runtime behaviour change - schema component naming only.
• Deliberately does not touch the feature-locked itam.* / assistance.* serializers.

🔗 Links / References

• Part of fix drf spectacular warnings #361 (scoped per the "one PR per model / group of serializers" approach discussed there).

👷 Tasks

• 🔍 spectacular warnings reduced 71 -> 68, no new warnings introduced
• 🧪 Existing entity serializer unit tests pass (36 passed, 0 failed) - schema-metadata-only change, no new behaviour to cover

• 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]

there are tasks missing from the pr template that specifically state dont delete. those tasks are for the PR reviewer to use as a checklist. please re-add them. Any additional task you require go above them.

Also dont forget to enable actions in your fork as the pr is un-meragable withou the tests.

PR template

### :books: Summary
<!-- your summary here emojis ref: https://github.com/yodamad/gitlab-emoji -->



### :link: Links / References
<!-- 

    using a list as any links to other references or links as required. if relevant, describe the link/reference

    Include any issues or related merge requests. Note: dependent MR's also to be added to "Merge request dependencies"

-->



### :construction_worker: Tasks

 - [ ] Add your tasks here if required (delete)

<!-- dont remove tasks below strike through including the checkbox by enclosing in double tidle '~~' -->

 - [ ] **Feature Release ONLY** :red_square: [Squash migration files](https://docs.djangoproject.com/en/5.2/topics/migrations/#squashing-migrations) :red_square: 
    _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_ 

- [ ] :firecracker: Contains breaking-change Any Breaking change(s)?

    _Breaking Change must also be notated in the commit that introduces it and in [Conventional Commit Format](https://www.conventionalcommits.org/en/v1.0.0/)._

    - [ ] :notebook: Release notes updated

- [ ] :blue_book: Documentation written

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

- [ ] :checkered_flag: Milestone assigned

- [ ] :gear: :test_tube: [Functional Test(s) Written](https://nofusscomputing.com/projects/centurion_erp/development/testing/)

- [ ] :test_tube: [Unit Test(s) Written](https://nofusscomputing.com/projects/centurion_erp/development/testing/)

    _ensure test coverage delta is not less than zero_

- [ ] :page_facing_up: Roadmap updated

[jon-nfc]

FYI, Randomly failing CI jobs have been addressed now. So any failing job needs to be rectified.

[louzolo123]

FYI, Randomly failing CI jobs have been addressed now. So any failing job needs to be rectified.

Okay, noted, I'll check back on my task
Don't worry

[louzolo123]

there are tasks missing from the pr template that specifically state dont delete. those tasks are for the PR reviewer to use as a checklist. please re-add them. Any additional task you require go above them.

Also dont forget to enable actions in your fork as the pr is un-meragable withou the tests.

PR template

Thanks @jon-nfc I've re-added the reviewer task checklist, rebased onto the current feat-next-release (the "require rebase" check now passes), and enabled Actions on my fork.

The fork's CI workflow still can't run though it ends in startup_failure. From ci.yaml, the workflow-level env: references org secrets (GITLAB_USERNAME_ROBOT / GITLAB_TOKEN_ROBOT) and the jobs call reusable workflows from other repos (nofusscomputing/action_python|action_docker|action_mkdocs), none of which are available on a contributor's fork so the required Integration/Docker checks never report.

How would you like fork contributors to get those checks to pass? Happy to adjust anything on my side.

[jon-nfc]

Thanks for correcting OP.

The fork's CI workflow still can't run though it ends in startup_failure. From ci.yaml, the workflow-level env: references org secrets (GITLAB_USERNAME_ROBOT / GITLAB_TOKEN_ROBOT) and the jobs call reusable workflows from other repos (nofusscomputing/action_python|action_docker|action_mkdocs), none of which are available on a contributor's fork so the required Integration/Docker checks never report.

The reusable workflows are public and are working. If they weren't, you wouldn't see anything.

The failing job is here:

• centurion_erp/.github/workflows/ci.yaml

  Lines 132 to 135 in 48570ba

  	gitlab-mirror:
  	if: ${{ github.repository == 'nofusscomputing/centurion_erp' }}
  	runs-on: ubuntu-latest
  	steps:

I'll fix this in the morning. That job is for syncing to my gitlab org and doesnt need to run on a fork.

[jon-nfc]

Github reports there's merge conflicts when I attempt to rebase, even though there shouldn't be.... So I cant rebase on your behalf.

CI workflows updated now. so you shouldn't have any issues with them running now.

[louzolo123]

Github reports there's merge conflicts when I attempt to rebase, even though there shouldn't be.... So I cant rebase on your behalf.

CI workflows updated now. so you shouldn't have any issues with them running now.

Okay, I'll check it. I'm at work right now, sir. Sorry about that, and don't worry.

[jon-nfc]

Okay, I'll check it. I'm at work right now, sir. Sorry about that, and don't worry.

Don't feel rushed. I understand you have a life.

[louzolo123]

Okay, I'll check it. I'm at work right now, sir. Sorry about that, and don't worry.

Don't feel rushed. I understand you have a life.

Don't worry, I love programming. It's my passion, and I really enjoy contributing to your Centurion project. I'll check it again later.

[louzolo123]

Rebased onto the latest feat-next-release — thanks, the Mirror job is skipped correctly now.

The fork CI still ends in startup_failure though (empty annotation, generic "workflow file issue"). I suspect one of the secrets: blocks passed to the reusable action_python / action_docker workflows requires an org secret that a fork doesn't have, so it fails validation at startup on forks only (it would pass on upstream where the secrets exist). Anything I can do on my side, or is it a CI-side tweak?

[jon-nfc]

The fork CI still ends in startup_failure though (empty annotation, generic "workflow file issue"). I suspect one of the secrets: blocks passed to the reusable action_python / action_docker workflows requires an org secret that a fork doesn't have, so it fails validation at startup on forks only (it would pass on upstream where the secrets exist). Anything I can do on my side, or is it a CI-side tweak?

taking a look now

[jon-nfc]

The fork CI still ends in startup_failure though (empty annotation, generic "workflow file issue"). I suspect one of the secrets: blocks passed to the reusable action_python / action_docker workflows requires an org secret that a fork doesn't have, so it fails validation at startup on forks only (it would pass on upstream where the secrets exist). Anything I can do on my side, or is it a CI-side tweak?

taking a look now

Looking at the error, The nested job 'vulnerability-scan' is requesting 'security-events: write', but is only allowed 'security-events: none'. its permissions.

That's required to upload the scan results to the security tab. Shit. looks like I'll need to figure out how to make forks to have their CI triggered by PR and not by push which is what I have now.

That's what I get I suppose, I started on gitlab so naturally assumed it would be the same on github. "read the bloody docs jon."

What I'll do is merge this anyway. there's nothing major in it.

[jon-nfc]

I was clearly paaying attention here. I've imported the base, just to define another empty base that inherits from the imported base. when i could have just done

from access.serializers.entity import (
    BaseSerializer
    ModelSerializer as BaseModelSerializer,
)

and achieved the same thing. Although not to phased, as the serializers down the track will become meta classes. So these files will eventually be deleted.