Refactor tables and API for reports and labels

[SchrodingersGat]

• Move all reports into single table (add "report type" column)
• Move all labels into single table (add "label type" column)
• Consolidate API endpoints for reports
• Consolidate API endpoints for labels
• Ensure report context is determined based on report type

[matmair]

Supporting generic model relations would be nice, that way plugins could use reports easily.

[github-actions]

This issue seems stale. Please react to show this is still important.

[wolflu05]

Still relevant

[matmair]

Related #5884 #2777

[matmair]

Maybe this could be structured as a generic similar to states - consistent code docstrings, fully covered with tests within the module. I would also remove the backend distinction between labels and reports and move everything into one new table to reduce duplications.

[matmair]

Could also be part of #6417

[SchrodingersGat]

Regarding comments on other threads: I would like to see reports and labels kept separate. They are functionally different enough to warrant separate models and handling

• Labels can be sent to specific external printers
• Labels use width and height parameters
• Reports specify page size i.e. A4 / Letter
• Labels can be grouped together when printing (e.g. array onto a single sheet)

Happy to look at merging existing label tables together, as with merging existing report tables

[matmair]

@SchrodingersGat do you think this should also apply to the code/database level? We have a lot of duplication in this area currently. Nearly half of our Python code-duplication is between the label and report app and the differences in the API and database make it more difficult than it needs to be. All the things you describe could also be flags on the merged definition - that would also make it possible to use the templating functions more flexibly and document contexts, variables etc dynamically. The amount of support we have around this area is significant.

[wolflu05]

I would be for having all in one generic table and adding flags. Having different apis that have different interfaces leads to a lot of codeduplication and messy code on the frontend.

While implementing the template editor in the frontend I came up with a collection of things that we should consider now if we refactor that.

1. I think we should call them from now on templates that exist in different types (label, report), each having some different variants (e.g. labels: stock item, location, ... and report: bom, location, ...)
2. template attributes like width, height for labels and page size, orientation for reports (also at frontend level, how do we want to expose them via the api?)
3. it would be nice to have a generic interface that can later be extended by plugins to add custom types/variants
4. how do we handle template assets
5. how do we handle snippets generically, maybe we just add them as a third type next to labels, reports, ...?
6. we shouldn't store templates as files on the server, it would be good to keep them in the database
7. we should not differentiate between InvenTree templates and user defined templates like the current folder structure does. IMHO it is enough to just add the predefined templates on the first startup and then don't care what the user does with it. (currently if the user changes them they get added again on the next startup because they now no longer exist)
8. each variant should be able to define a custom context (later we should somehow be able to integrate that with the codeeditor), default template that will be used for each new template and some info about it that can be accessed via api
9. we should be able to render a template for a variant without uploading it as a template first, but instead use the post body (useful for previews)

[matmair]

Maybe this should be a dev call and a task list

[SchrodingersGat]

I'm keen to address this properly - a good target for the 0.15.0 release I think. Let's revisit after 0.14.0 is out - I'd like to focus on that :)

[matmair]

Regarding templates in database we could either use https://django-dbtemplates.readthedocs.io/en/latest/; it is not Dj 4.2 ready but looks nice otherwise or roll our own based on it's idea https://github.com/jazzband/django-dbtemplates/blob/233a401e75d9b6133dd4c9fdc17bf85d2660cc41/dbtemplates/loader.py

[SchrodingersGat]

@matmair interesting find!