[WIP] API Forms

[SchrodingersGat]

This PR implements "forms" across the API.

The eventual goal here is to eliminate the current duplication of code which renders web forms from the django server, and also (separately) defines the API.

The DRF API will (when this PR is complete) provide all (or at least most) of the modal forms.

Form Features

• Field selection
• Ignore certain fields
• Set custom field ordering
• Custom "grouping" of form fields
• Custom form elements
• Use pagination for select2 API requests - speed up results!
• Launch "secondary" modals (and handle the results)
• Allow "infinite" stacking modals (created at run-time)
• Callbacks when fields are edited
• Option for custom client-side field validation (before sending data to the server)
• Support custom filtering for foreign-key fields
• Render optional "prefix" elements to form fields
• Inter min_value from numerical django model fields
• Infer max_value from numerical django model fields
• Allow (non required) select2 fields to be cleared
• Correctly render file fields which already have a file, in "edit" mode (e.g. StockItemAttachment)
• Framework form for "deleting" objects
• Display "warning" screens for deletion - i.e. "these things will also be deleted"
• Allow non-required file / image fields to be cleared
• Insertion of fields defined completely at "run time"
• Run custom code before the form is displayed, but after data is fetched
• Run custom code before form is submitted
• Focus on a particular field when opening the modal (if desired)
• Detect if user does not have required permissions and hide secondary buttons accordingly
• Record user when creating a PurchaseOrder
• Record user when creating a SalesOrder
• Migrate settings forms to the API

Bugs

• Launching a secondary modal with a select2 attached strips the select2 features from the first modal...
• Python bindings unit tests are broken - need to submit a PR there once this one is merged.

Other Items

• Ensure that all "attachment" tables use the REST API

Supported Input Types

• Model reference ForeignKey fields (probably the most complex one!)
• Boolean fields
• String fields
• Integer fields
• Float fields
• URL fields
• email fields
• decimal field
• date field
• datetime field
• time field
• choice field
• multiple choice field
• file upload
• image upload

Ref: django DRF metadata

Python Integration

• Python support

TODO: Add support to the python bindings to allow dynamic lookup of "queryset" for a given ForeignKey field.

Unit Testing

• Increase unit testing for the new OPTIONs endpoints
• Ensure that the OPTIONS endpoints returns correct information for "related" fields
• Test that the OPTIONS endpoint correctly returns 'default' values for fields with specified defaults
• Ensure the OPTIONS endpoint correctly returns 'filters' for model fields
• Ensure the OPTIONS endpoint correctly returns min_value and max_value for fields
• Ensure that OPTIONS includes 'help_text' for related fields
• Correctly handle invalid inputs for all MPTT fields (e.g. setting invalid parent node)
• Automatically remove invalid choices from MPTT fields (e.g. don't let user select invalid "parent" items)
• Save user information when creating or updating an attachment
• Save user information when creating or editing a StockItem
• Ensure that the 'required' property is getting set correctly - both for fields and relations
• Ensure that 'read_only' property is getting set correctly - both for fields and relations - e.g. looks like this might not be the case for StockItemSerializer

Documentation

• Add API docs for OPTIONS endpoints

References

• Front End Roadmap #1683
• Fixes Investigate DRF Forms #1213
• Fixes Stock "adjustment" actions should be ported to the API #707
• Requires Observe "default" values for blank fields when creating objects via API #1687 to be fixed
• Waiting on Propagate 'default' from model_field to serializer field encode/django-rest-framework#8002
• Waiting on OPTIONS could easily return the default of a serializer encode/django-rest-framework#8003

[matmair]

@SchrodingersGat a few things that I develop rn will need rewriting when this gets merged, when do you think it will be ready? Should I already pull this into my PRs?

yes this PR has grown a lot, and touches a lot of code! I am thinking I will merge this in sooner, rather than waiting until every wishlist item is implemented, otherwise it will be a nightmare to merge.

@SchrodingersGat loots of great stuff in here, will make adding new forms more seamless. I will keep doing small stuff while you work on this and then finish the wishlist for pricing. Everything left there needs form rendering.

[SchrodingersGat]

@matmair enough for now - remaining outstanding issues / features are documented here: #1755

[eeintech]

@SchrodingersGat For the moment the "API-ready" forms are only for companies and orders? I've tried Parts, Categories and Stock location/items and still getting GET requests.

[eeintech]

It's so quick btw 😃

[SchrodingersGat]

@SchrodingersGat For the moment the "API-ready" forms are only for companies and orders? I've tried Parts, Categories and Stock location/items and still getting GET requests.

I have only migrated a handful of the existing forms - basically the ones without any complex server-side logic. Those will require some closer attention.

[eeintech]

Sounds good!