Fix common spelling mistakes (#4956)

* add codespell

* first fixes

* doc fixes

* fix docstrings and comments

* functional changes

* docstrings again

* and docs again

* rename args

* add ignore

* use pre-commit for filtering instead

* ups

* fix typo in filter

docs/docs/extend/how_to_plugin.md

@@ -18,7 +18,7 @@ If you add a lot of code (over ~1000 LOC) maybe split it into multiple plugins t
 Great. Now please read the [plugin documentation](./plugins.md) to get an overview of the architecture. It is rather short as a the (builtin) mixins come with extensive docstrings.
 
 ### Pick your building blocks
-Consider the usecase for your plugin and define the exact function of the plugin, maybe wrtie it down in a short readme. Then pick the mixins you need (they help reduce custom code and keep the system reliable if internal calls change).
+Consider the usecase for your plugin and define the exact function of the plugin, maybe write it down in a short readme. Then pick the mixins you need (they help reduce custom code and keep the system reliable if internal calls change).
 
 - Is it just a simple REST-endpoint that runs a function ([ActionMixin](./plugins/action.md)) or a parser for a custom barcode format ([BarcodeMixin](./plugins/barcode.md))?
 - How does the user interact with the plugin? Is it a UI separate from the main InvenTree UI ([UrlsMixin](./plugins/urls.md)), does it need multiple pages with navigation-links ([NavigationMixin](./plugins/navigation.md)).
@@ -53,7 +53,7 @@ from plugin.mixins import APICallMixin, SettingsMixin, ScheduleMixin, BarcodeMix
 
 
 !!! tip "Package-Discovery can be tricky"
-    Most problems with packaging stem from problems with dicovery. [This guide](https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#automatic-discovery) by the PyPA contains a lot of information about discovery during packaging. Theses mechanisms generally apply to most discovery processes in InvenTree and the wider Django ecosystem.
+    Most problems with packaging stem from problems with discovery. [This guide](https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#automatic-discovery) by the PyPA contains a lot of information about discovery during packaging. These mechanisms generally apply to most discovery processes in InvenTree and the wider Django ecosystem.
 
 The recommended way of distribution is as a [PEP 561](https://peps.python.org/pep-0561/) compliant package. If you can use the official Package Index (PyPi - [official website](https://pypi.org/)) as a registry.
 Please follow PyPAs official [packaging guide](https://packaging.python.org/en/latest/tutorials/packaging-projects/) to ensure your package installs correctly suing InvenTrees install mechanisms.

docs/docs/extend/plugins/install.md

@@ -34,7 +34,7 @@ In certain container environments (such as docker), plugins are installed into a
 
 #### Builtin Plugins
 
-Builtin plugins ship in `src/InvenTree/plugin/builtin`. To achive full unit-testing for all mixins there are some sample implementations in `src/InvenTree/plugin/samples`.
+Builtin plugins ship in `src/InvenTree/plugin/builtin`. To achieve full unit-testing for all mixins there are some sample implementations in `src/InvenTree/plugin/samples`.
 
 !!! success "Builtin Plugins"
     Builtin plugins are always enabled, as they are required for core InvenTree functionality

docs/docs/extend/plugins/settings.md

@@ -77,4 +77,4 @@ This mixin defines the helper functions `plugin.get_setting` and `plugin.set_set
 api_url = self.get_setting('API_URL', cache = False)
 self.set_setting('API_URL', 'some value')
 ```
-`get_setting` has an additional parameter which lets control if the value is taken directly from the database or from the cache. If it is left away `False` ist the default that means the value is taken directly from the database.
+`get_setting` has an additional parameter which lets control if the value is taken directly from the database or from the cache. If it is left away `False` is the default that means the value is taken directly from the database.

docs/docs/extend/plugins/tags.md

@@ -4,7 +4,7 @@ title: Item Tags
 
 ## Tags
 
-Several models in InvenTree can be tagged with arbitrary tags. Tags are useful for grouping items together. This can be used to mark items with a plugin or to group items together for a particular theme. Tags are meant to be used by programms and are not visible to the end user.
+Several models in InvenTree can be tagged with arbitrary tags. Tags are useful for grouping items together. This can be used to mark items with a plugin or to group items together for a particular theme. Tags are meant to be used by programs and are not visible to the end user.
 Tags are shared between all models that can be tagged.
 
 The following models can be tagged:
@@ -52,7 +52,7 @@ Part.objects.filter(tags__name__in=["Tag1", "Tag 2"]).distinct()
 
 For models which provide tags, access is also provided via the API. The tags are exposed via the detail endpoint for the models starting from version 111.
 
-Tags can be cached via PATCH or POST requests. The tags are provided as a json formatted list of strings. The tags are note case sensitive and must be unique across the instance - else the exsisting tag gets assigned. The tags are not sorted and the order is not guaranteed.
+Tags can be cached via PATCH or POST requests. The tags are provided as a json formatted list of strings. The tags are note case sensitive and must be unique across the instance - else the existing tag gets assigned. The tags are not sorted and the order is not guaranteed.
 
 ```json
 {

docs/docs/extend/plugins/validation.md

@@ -16,7 +16,7 @@ Any of the methods described below can be implemented in a custom plugin to prov
 
 ### Part Name
 
-By default, part names are not subject to any particular naming conventions or requirements. However if custom validation is required, the `validate_part_name` method can be implement to ensure that a part name conforms to a required convention.
+By default, part names are not subject to any particular naming conventions or requirements. However if custom validation is required, the `validate_part_name` method can be implemented to ensure that a part name conforms to a required convention.
 
 If the custom method determines that the part name is *objectionable*, it should throw a `ValidationError` which will be handled upstream by parent calling methods.