Add schema generation hints to resolve warning

[1337joe]

As a path to understanding the schema generator for #9045, I'm trying to address at least some of the warnings it currently produces.

/git/inventree/InvenTree/src/backend/InvenTree/company/serializers.py:107: Warning [CompanyList > CompanySerializer]: unable to resolve type hint for function "address". Consider using a type hint or @extend_schema_field. Defaulting to string.

String is actually the correct type in this case, but the field also needs to be nullable to be fully correct.

The two changes in this pull request accomplish the same goal: providing the nullable string type hint to the schema generator.

Adding a line to the serializer to explicitly define address produces:

address:
  type: string
  readOnly: true
  nullable: true

while simply adding the return type hint to the model produces:

address:
  type: string
  nullable: true
  description: |-
    Return the string representation for the primary address.

    This property exists for backwards compatibility
  readOnly: true

I would argue that the second option (adding type hints to the model) is the better way to go:

1. It's less serializer-specific code that has to be maintained moving forward for simple fields like this one.
2. The type definition is in the same place as the value that it matches for ease of maintenance.
3. It displays the relevant documentation comment in the schema.

It's entirely possible that I'm missing something since I'm just focused on the schema, but the one (admittedly major) downside that I see to adding the hint to the model is that it doesn't match the way the existing serializers are set up.

Which route is preferable moving forward?

[netlify]

✅ Deploy Preview for inventree-web-pui-preview canceled.

Name	Link
🔨 Latest commit	a7018b9
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/67a56fb25406c400087ff77e

[SchrodingersGat]

Adding a return type hint to the model seems like the better solution to me. It is a "deeper" solution allowing higher level code (such as the serializers) to introspect. I suspect there are probably a number of other models which will need this attention

[1337joe]

Adding a return type hint to the model seems like the better solution to me.

Perfect. I'll prefer that way when it's an option and I'll migrate from serializer to model where I'm already touching it.

Is this the best way to ask questions about coding direction?

[SchrodingersGat]

Is this the best way to ask questions about coding direction?

GitHub is the best place for these discussions so we can keep everything in the same place :)

[SchrodingersGat]

@1337joe are you still taking charge of this one?

[1337joe]

That's my intent but I started work on it right before I'm going out of town for a week so I haven't had time to dig into all I wanted to. I'll try to get a first pass pushed tonight or tomorrow with the intent of cleaning it up more when I'm back home.