-
-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User defined states #7862
User defined states #7862
Conversation
…custom-user-defined-states
This is technically done, I will try to finish the docs by the end of the week. |
@SchrodingersGat this is ready for review and merge. I don't know if we should backport it though as I am unsure how the API revision should be ported to 0.16.x. It would be cool if we could get it into 0.16.x but probably more hassle than it is worth. |
@matmair I think that given the amount of significant change here, we should let it have a round of testing in the |
@SchrodingersGat i have changed the target |
I have adjusted the api_version so that this can be merged after #7520 |
…ir/InvenTree into custom-user-defined-states
Thanks for the hard work on this one @matmair - due to the large number of changes here we will need to monitor closely until the 0.17.x release |
This PR adds the option to use user-defined states to models that use generic states.
For this, the model must be adapted to use the new
InvenTreeCustomStatusModelField
and the model's serializers must inheritInvenTreeCustomStatusSerializerMixin
. The default behaviour of the serializer field is not changed but a new field is made available:{field_name}_custom_key
. Custom states must always map to alogical
key that points to the business logic. Custom states require unique keys that can not shadow logical keys. In theory, a model could make use of multiple fields with multiple custom states. This is not unit-tested with this PR but the code is developed with it in mind.This PR does not change business logic but contains various frontend changes to render the custom field value instead of the (business) logic value. Both CUI and PUI were adapted to support the states. Colours for states now support enums (I would encourage usage of the enum)
Most API calls to serializers that use custom states experience 1-2 more DB calls due to the lookup of custom states. There is no caching in this PR implemented as consistency checks between different workers presented to be difficult.
ToDo
Included changes that are not strictly custom states:
Closes #4289