wbcore 2.2.1__tar.gz → 2.2.4__tar.gz

wbcore-2.2.4/.coveragerc

@@ -0,0 +1,25 @@
+[report]
+exclude_lines =
+    print()
+    def api_endpoints_root
+    def get_or_create_model_sql
+    def profile_check
+    if hasattr
+    raise Exception
+    raise Http404
+    except:
+    if TYPE_CHECKING:
+
+
+[run]
+omit = */migrations/*
+    manage.py
+    */tests/*
+    */test_project/*
+    */config/*
+    */apps.py
+    */docs/*
+    */dynamic_preferences_registry.py
+    */permissions.py
+    */preferences/*
+    */.venv/*

wbcore-2.2.4/.gitlab-ci.yml

@@ -0,0 +1,29 @@
+deploy-example-app:
+  image: ubuntu
+  stage: deploy
+  variables:
+    GIT_DEPTH: 0
+  only:
+    refs:
+      - dev
+    changes:
+      - "modules/wbcore/**/*"
+      - "modules/wbcore/*"
+  before_script:
+    - apt-get update -y && apt-get install openssh-client git -y
+    - eval $(ssh-agent -s)
+    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
+    - mkdir -p ~/.ssh
+    - chmod 700 ~/.ssh
+    - ssh-keyscan example.stainly.com >> ~/.ssh/known_hosts
+    - chmod 644 ~/.ssh/known_hosts
+    - git config --global user.email "admin@stainly.com"
+    - git config --global user.name "Gitlab Runner"
+    - git config --global init.defaultBranch dev
+  script:
+    - cd modules/wbcore
+    - git init
+    - git add .
+    - git commit -m "initial commit"
+    - git remote add dokku dokku@example.stainly.com:example
+    - git push dokku $CI_COMMIT_REF_NAME --force

wbcore-2.2.4/.python-version

@@ -0,0 +1 @@
+3.12.0

{wbcore-2.2.1 → wbcore-2.2.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: wbcore
-Version: 2.2.1
+Version: 2.2.4
 Author-email: Christopher Wittlinger <c.wittlinger@stainly.com>
 Requires-Dist: boto3==1.*
 Requires-Dist: celery[redis]==5.*

wbcore-2.2.4/Procfile

@@ -0,0 +1,2 @@
+web: gunicorn wbcore_config.wsgi:application --bind 0.0.0.0:$PORT -c gunicorn_conf.py
+release: python manage.py migrate && python manage.py collectstatic --no-input

wbcore-2.2.4/check_release_notes.py

@@ -0,0 +1,26 @@
+import glob
+from pathlib import Path
+
+from wbcore.release_notes.utils import parse_release_note
+
+if __name__ == "__main__":
+    base_path = "../"
+    errors = {}
+    for release_note_folder in [
+        *glob.glob(f"{base_path}**/**/release_notes"),
+        "wbcore/release_notes/release_notes",
+        "wbcore/release_notes/frontend_release_notes",
+    ]:
+        if release_note_folder != "../wbcore/wbcore/release_notes":
+            for release_note in Path(release_note_folder).iterdir():
+                if not release_note.is_dir():
+                    with open(release_note, "r") as markdown_file:
+                        try:
+                            parse_release_note(markdown_file.read())
+                        except Exception as e:
+                            errors[str(release_note).replace("../", "")] = e
+
+    if errors:
+        raise ValueError(f"These release notes trigger an error {errors}")
+    else:
+        print("ok")  # noqa: T201

wbcore-2.2.4/docs/buttons.md

@@ -0,0 +1,49 @@
+# Buttons
+
+There are different kinds of buttons that can be implemented through the wbcore, system buttons and custom buttons.
+
+## System Buttons
+
+System buttons are buttons reoccurring buttons with a default behaviour:
+
+* save
+    * Saves an instance (`wbcore.enums.Button.SAVE`)
+* saveandnew
+    * Saves an instance and opens a new instance (`wbcore.enums.Button.SAVE_AND_NEW`)
+* saveandclose
+    * Saves an instance and closes the instance (`wbcore.enums.Button.SAVE_AND_CLOSE`)
+* delete
+    * Deletes and instance (`wbcore.enums.Button.DELETE`)
+* new
+    * Opens a new instance (`wbcore.enums.Button.NEW`)
+* refresh
+    * Refreshes a list/instance (`wbcore.enums.Button.REFRESH`)
+* reset
+    * Resets a new instance (`wbcore.enums.Button.RESET`)
+
+## Custom Buttons
+
+Custom buttons have a custom behaviour and can be attached to a list or an instance. There are four different custom buttons:
+
+* Hyperlink
+    * Creates a hyperlink to an url (`wbcore.metadata.configs.buttons.HyperlinkButton`)
+* Widget
+    * Opens a widget (`wbcore.metadata.configs.buttons.WidgetButton`)
+* Dropdown
+    * Nests other buttons in a dropdown menu (`wbcore.metadata.configs.buttons.DropdownButton`)
+* Action
+    * Creates a custom action (`wbcore.metadata.configs.buttons.ActionButton`)
+
+The defaulf properties are as following:
+
+| Property | Required                | Value                                    |
+|----------|-------------------------|------------------------------------------|
+| label    | yes, if icon is None    | A string that is rendered on the button  |
+| icon     | yes, if label is None   | A string that represents an icon class   |
+| title    | no                      | A string that is used as the hover title |
+| key      | yes if endpoint is None | A string that matches against an url     |
+| endpoint | yes if key is None      | A url                                    |
+
+## Remote Buttons
+
+<Placeholder>

wbcore-2.2.4/docs/concept.md

@@ -0,0 +1,12 @@
+The main concept of django wbcore is to leverage preflight OPTION requests and automatically assemble a frontend, based on the model, the serializer and the viewset.
+
+### Frontend
+
+The frontend is a react based desktop like application that populates itself with OPTION requests. Each OPTION requests describes the upcoming request:
+
+* Is it a list or an instance?
+* What fields are available?
+* What filters are available?
+* Can something be searched?
+* Can something be ordered?
+* Are there buttons that should open something?

wbcore-2.2.4/docs/display.md

@@ -0,0 +1,68 @@
+# Display
+
+## Legend
+
+A table can have numerous legends, where each legend has a number of legend items.
+
+### LegendItem
+
+Each legend item has a label and an icon.
+
+## Formatting
+
+Table Formatting can be applied to the whole row, by altering the style or by adding an icon in front of the row, or it can be applied to a single cell. Applying formatting to a whole row happens through `RowFormatting` and formatting a single cell happens through `ColumnFormatting`.
+
+### RowFormatting
+
+Applying formatting to a whole row through `RowFormatting` is always conditional on the value of a column and accepts two arguments: column and conditions, where column is the name of the column and conditions is a list of conditions, which are either `RowIconCondition` or `RowStyleCondition` and can be used interchangable. Each condition is checked, and if it validates, then it is applied.
+
+### RowIconCondition
+
+The `RowIconCondition` accepts two arguments, icon and condition. Icon is a string that the frontend can use to determine the icon class and condition is a tuple that is checked against the column specified in the `RowFormatting`. (More on conditions below)
+
+### RowStyleCondition
+
+The `RowStyleCondition` works analogous to the `RowIconCondition`, except that it does not accept icon as an argument, but rather a style, which is a dictionairy, which holds css classes and their values. (*Note: If the Frontend is based on React, css class name are written like backgroundColor and not background_color*)
+
+### Conditions
+
+The condition is represented by a tuple of an operator and a value. For example: (">", 5) verifies that the value of the column has to be greater than 5. For convenience all operators are accessible through the `wbcore.enums.Operator` enum. The above example can be written as (Operator.GREATER.value, 5) with the enum. A list of all possible operator and how to use them are found below:
+
+| Operator | Values            | Explanation                                                  | Enum                   |
+|----------|-------------------|--------------------------------------------------------------|------------------------|
+| ∃        | True, False       | Checks wether the column exists or not (e.g. is null or not) | Operator.EXISTS        |
+| >        | [int, float]      | Checks wether the column is greater than a value             | Operator.GREATER       |
+| >=       | [int, float]      | Checks wether the column is greater or equal than a value    | Operator.GREATER_EQUAL |
+| <        | [int, float]      | Checks wether the column is less than a value                | Operator.LESS          |
+| <=       | [int, float]      | Checks wether the column is less or equal than a value       | Operator.LESS_EQUAL    |
+| ==       | [int, float, str] | Checks wether the column is equal to a value                 | Operator.EQUAL         |
+| !=       | [int, float, str] | Checks wether the column is unequal to a value               | Operator.UNEQUAL       |
+
+### Example
+
+The below Example does two things:
+
+1. If `number` is greater than 5, then the row gets a star icon.
+2. If `number` is greater than 10, then the row gets a blue background color.
+
+```python
+from wbcore.metadata.configs import display as dp
+from wbcore.enums import Condition
+
+LIST_DISPLAY = [
+    formatting=[
+        dp.RowFormatting(
+            column="number",
+            conditions=[
+                dp.RowIconCondition(
+                    icon="icon-star", condition=(Condition.GREATER.value, 5)
+                ),
+                dp.RowStyleCondition(
+                    style={"backgroundColor": "rgb(13, 28, 189)",
+                    condition=(Condition.GREATER.value, 10)
+                )
+            ]
+        )
+    ]
+]
+```

wbcore-2.2.4/docs/filters.md

@@ -0,0 +1,127 @@
+Filters are based on Django-Filters and can mostly be autogenerated from a simple dictionary when using a `wbcore.viewsets.ModelViewSet`. All customized parameters are taken from the attached model and are applied to the filter. When the completely autogenerated filter is not sufficient, a custom `wbcore.filters.FilterSet` can be provided to overwrite filters or set custom filters.
+
+### Setup
+
+Below are two examples on how to set up a rudimentary filter, where both examples yield exactly the same result: Two filters for the field `first_field`, one which filters for exact values, and one which filters for similar values (`SQL: LIKE`).
+
+```python
+from wbcore.filters import DjangoFilterBackend
+from wbcore.viewsets import ModelViewSet
+
+class XYZModelViewSet(ModelViewSet):
+    filter_backends = [DjangoFilterBackend]
+    filterset_fields = {
+        "first_field": ["exact", "icontains"]
+    }
+```
+
+```python
+from wbcore.filters import DjangoFilterBackend, FilterSet
+from wbcore.viewsets import ModelViewSet
+
+class XYZFilterSet(FilterSet):
+    class Meta:
+        model = XYZ
+        fields = {
+            "first_field": ["exact", "icontains"]
+        }
+
+class XYZModelViewSet(ModelViewSet):
+    filter_backends = [DjangoFilterBackend]
+    filter_class = XYZFilterSet
+```
+
+### Lookup Expressions
+
+!!! warning
+    Not all field lookups from [Django](https://docs.djangoproject.com/en/3.0/ref/models/querysets/#field-lookups) are supported yet.
+
+The different lookup expressions that are currently available are:
+
+* `exact`: An exact match against the filtered value (for Text, Number, Dropdown). In SQL `=`
+* `icontains`: A loose match against the filtered value (for Text, Number). In SQL `LIKE`
+* `gt`: Greater than a value (for Number). In SQL `>`
+* `gte`: Greater than or equal to a value (for Number). In SQL `>=`
+* `lt`: Less than a value (for Number). In SQL `<`
+* `lte`: Less than or equal to a value (for Number). In SQL `<=`
+
+### Custom Filter
+
+As mentioned previously, custom filters are specified in a `wbcore.filters.FilterSet`. There are two different reasons for custom filters:
+
+1. Overwrite the filter method behind a filter
+2. Specify filters that are not part of a field of the model
+
+When implementing a custom filter, it is really important that this filter is specified the same as the other filters, as a dictionairy.
+
+``` python
+from wbcore.filters import FilterSet, BooleanFilter
+
+class XYZFilterSet(FilterSet):
+    non_field_filter = BooleanFilter(label="Non Field", method="get_non_field_filter")
+
+    def get_non_field_filter(self, queryset, name, value):
+        if value:
+            return qs.filter(some_field=True)
+        return qs
+
+    class Meta:
+        model = XYZ
+        fields = {
+            "non_field_filter": ["exact"]
+        }
+
+```
+
+Any dedicated model filter fields can take an extra `filter_params` argument (either as a dictionary or a callable) which returns the
+dictionary to url encode. Let's recall that the resulting endpoint (and its potential query parameters) are returned to the frontend
+and will be used by it to fetch the filter field representation.
+
+Example:
+
+```python
+def get_filter_params(request, view):
+    return {}
+
+class XXXFilter(wb_filters.FilterSet):
+    dedicated_filter = wb_filters.ModelChoiceFilter(
+        label="A filter",
+        queryset=Model.objects.all(),
+        endpoint=Model.get_representation_endpoint(),
+        value_key=Model.get_representation_value_key(),
+        label_key=Model.get_representation_label_key(),
+        filter_params=get_filter_params # or {'key': value},
+    )
+```
+### Remote Filters
+
+In case a viewset needs to define extra filters proposed by another module (dependency), remote filters can be defined using a received to `add_filters`
+
+Example: We have a module XXX and another YYY. YYY introduces a new field (e.g ForeignKey) on XXX and as such, we would like to define
+a new filter on XXX viewset (from within YYY module) to avoid circular module dependency from XXX and YYY.
+
+Do not forget to register/import the file where the signals receiver are defined
+```python
+# YYY.filters.signals
+from wbcore.signals.filters import (
+    add_filters
+)
+from wbcore import filters as wb_filters
+from django.dispatch import receiver
+from xxx.filters import XXXFilter
+
+@receiver(add_filters, sender=CompanyFilter)
+def add_xxx_filter(sender, *args, **kwargs):
+    def method_x(queryset, name, value):
+        if value:
+            # do something with the field introduced by the module YYY on XXX
+            return queryset # Do something
+        return queryset
+    return {
+        'xxx_filter': wb_filters.BooleanFilter(
+            field_name="fitler_name", # important!
+            label="XXX filter",
+            method=method_x
+        )
+    }
+```

wbcore-2.2.4/docs/getting_started.md

@@ -0,0 +1,122 @@
+### Installation
+
+To install wbcore use pip:
+
+    pip install wbcore
+
+Afterwards add wbcore to the project by:
+
+```python
+INSTALLED_APPS = [
+    ...
+    "wbcore",
+    ...
+]
+```
+
+### Install Development Environment
+
+#### Cloning the repository
+
+    git clone git@github.com:intellineers/wbcore.git
+
+#### Installing system dependencies
+
+* [Poetry](https://python-poetry.org/docs/#installation)
+    * For pypi depenendency management / package building
+* [Docker](https://docs.docker.com/get-docker/)
+    * For running external containerized services
+* [Docker-Compose](https://docs.docker.com/compose/install/)
+    * For orchestrating containerized services
+
+
+#### Setup environment variables
+
+The url for the database has to be stored as a environment variable:
+
+    export DATABASE_URL=postgres://root:root@localhost:5432/wbcore
+
+!!! hint
+    The management of environment variables is not automatically handled in poetry (opposed to pipenv), therefore you as a developer has to take care of this.
+    **Tip:** Use [direnv](https://direnv.net/) and store the environment variables in a `.envrc` file.
+
+#### Setup initial system
+
+In order to make the system work the following steps have to be taken:
+
+1. Get the latest version of the repository
+1. Install all dependencies through poetry
+1. Startup docker containers which run external services (Postgres, Redis, S3 Minio)
+    * Postgres and S3 Minio are setup to have persistant data stored in the folder `~/DockerVolumes/`
+1. Create a database
+1. Migrate the database
+1. **Optionally** insert fixtures into the database
+
+To ease and speedup the process of setting up the development environment the last 6 steps can be done automatically by running the following script
+
+    ./scripts/startup
+
+### Useful Scripts
+
+#### Development Server
+
+Two development servers are available, one for the web-worker:
+
+    ./scripts/dev-server
+
+The other one is a celery consumer:
+
+    ./scripts/celery
+
+
+#### Testing
+
+In order to run all tests with pytest:
+
+    ./scripts/pytest
+
+If you want to run all tests without the pytest-cache:
+
+    ./scripts/pytest_full
+
+If you want to deploy changes, you need to make sure that running the tests in an isolated environment with tox do not fail:
+
+    poetry run tox
+
+
+#### Documentation
+
+The documentation is available locally under `http://localhost:8000`:
+
+    ./scripts/docs
+
+#### Interactive Shell and Notebooks
+
+The shell with a preloaded django environment is available under:
+
+    ./scripts/django_shell
+
+The same django environment is also available as a notebook:
+
+    ./scripts/notebook
+
+#### Database (PSQL)
+
+Quick access to a psql shell:
+
+    ./scripts/psql
+
+#### Misc.
+
+Apply isort, then black to all files:
+
+    ./scripts/format
+
+### Formatting Rules
+
+The whole codebase has to be formatted with isort and black with the following parameters:
+
+    isort -m 3 -w 128 --tc .
+    black --line-length 128 .
+
+This is automatically done by calling the formatting script (See [Misc.](#misc))

wbcore-2.2.4/docs/index.md

@@ -0,0 +1,4 @@
+Django WBCore is a framework to streamline the development of django enterprise applications by providing means to create a desktop like experience in the browser without having to program a single line of HTML.
+
+The main concept is to leverage pre-request `OPTIONS` requests where all information about the upcoming request are provided.
+These information can afterwards be used in order to build a frontend automatically.

wbcore-2.2.4/docs/menu.md

@@ -0,0 +1,105 @@
+The wbcore has the capability to return menus by adding menus to a registry. By default there is a `wbcore.menus.default_registry` where menus can be added which in return can be retrieved through the `wbcore:menu` endpoint.
+
+Usually the menu of an app is added to the `__init__.py` of the root directory of each app, but it could be placed at any location that is loaded upon starting the server.
+
+# Structure
+
+blockdiag {
+    registry [label="MenuRegistry"];
+    menu1 [label="Menu"];
+    menu2 [label="Menu"];
+    menu3 [label="Menu"];
+    menuitem1 [label="MenuItem"];
+    menuitem2 [label="MenuItem"];
+    menuitem3 [label="MenuItem"];
+    menuitem4 [label="MenuItem"];
+    menuitem5 [label="MenuItem"];
+    menuitem6 [label="MenuItem"];
+    itempermission [label="ItemPermission"];
+    registry -> menu1;
+    registry -> menu2;
+                menu1 -> menuitem1;
+                menu1 -> menuitem2;
+                menu1 -> menu3;
+                menu2 -> menuitem3;
+                menu2 -> menuitem4;
+                         menuitem3 -> itempermission;
+                menu3 -> menuitem5;
+                menu3 -> menuitem6;
+}
+
+# MenuRegistry
+
+Each registry represents one menu group. A registry can register a menu through the `register(menu)` method.
+
+# Menu
+
+Each menu represents one menu that contains several items or nested menus.
+
+# MenuItem
+
+Each menu item represents one actionable item inside of a menu. The action that is run depends on the endpoint of the menu item.
+
+For each menu item a create button can be defined. This is useful if a user should be able to create an instance of a model from the menu (e.g. open a form to create the instance). For this, another menu item has to be attached to the field `add`.
+
+# ItemPermission
+
+Each menu item can have an ItemPermission to determine if the current user that retrieves the menu can retrieve the menuitem.
+
+To determine whether the current user can retrieve the menuitem has to fields that can be evaluated:
+
+1. `permissions`: A list of django permissions that are checked against the current user. Returns `True` if all permissions are valid for the current user, otherwise `False`
+2. `method`: A callable that has to accepts the request as a parameter. The callable has to return `True` or `False`
+
+If the current user is a `superuser` the ItemPermission always returns `True`.
+
+# Example
+
+blockdiag {
+    registry [label="MenuRegistry"];
+    menu1 [label="Menu1"];
+    menu2 [label="Menu2"];
+    menuitem1 [label="MenuItem1"];
+    menuitem2 [label="MenuItem2"];
+    menuitem3 [label="MenuItem3"];
+    menuitem4 [label="MenuItem4"];
+    menuitem4_add [label="Add MenuItem4"];
+    itempermission [label="ItemPermission"];
+    registry -> menu1;
+    registry -> menu2;
+                menu1 -> menuitem1;
+                menu1 -> menuitem2;
+                menu2 -> menuitem3;
+                menu2 -> menuitem4;
+                         menuitem4 -> menuitem4_add;
+                         menuitem3 -> itempermission;
+}
+
+```python
+# __init__.py
+from wbcore.menus import default_registry, Menu, MenuItem, ItemPermissions
+
+default_registry.register(
+    Menu(label="Menu1", items=[
+        MenuItem(label="MenuItem1", endpoint="app:endpoint1"),
+        MenuItem(label="MenuItem2", endpoint="app:endpoint2"),
+    ])
+)
+
+default_registry.register(
+    Menu(label="Menu2", items=[
+        MenuItem(
+            label="MenuItem3",
+            endpoint="app:endpoint3",
+            permission=ItemPermission(
+                method=lambda request: request.user.is_staff
+            )
+        ),
+        MenuItem(
+            label="MenuItem4",
+            endpoint="app:endpoint4",
+            add=MenuItem(label="Add MenuItem4", endpoint="app:endpoint4")
+        ),
+    ])
+)
+```

wbcore-2.2.4/docs/metadata/concept.md

@@ -0,0 +1,32 @@
+# Concept
+
+The metadata is the heart of workbench. It is the glue between the backend and the frontend and what allows the developer to streamline the development and UI-Generation. In its essence the metadata takes configurations from python classes and parses them through the `OPTIONS` request in a predetermined format in order to tell the frontend what to display and how. Currently the following configurations are supported:
+
+- [`fields`](configs/fields.md): The fields with their properties
+- [`filter_fields`](configs/filter_fields.md): The available filters with their properties
+- [`ordering_fields`](configs/ordering_fields.md): Which field can be ordered/sorted
+- [`search_fields`](configs/search_fields.md): The fields that are used for searching
+- [`pagination`](configs/pagination.md): The pagination method that is used
+- [`identifiers`](configs/identifiers.md): How to uniquely identify something
+- [`type`](configs/type.md): What is displayed (chart, form, table, ...)
+- [`titles`](configs/titles.md): What title should be displayed
+- [`endpoints`](configs/endpoints.md): What endpoint should be used for what action
+- [`buttons`](configs/buttons.md): What additional button should be displayed where
+- [`display`](configs/display.md): How to display the data
+- [`primary_key`](configs/primary_key.md): What is the primary key
+
+The general workflow mostly looks like this:
+
+```mermaid
+sequenceDiagram
+    Frontend->>Backend: OPTIONS
+    Note right of Backend: Assemble all metadata
+    Backend->>Frontend: Response[OPTIONS]
+    Note left of Frontend: Parse metadata and build UI
+    Frontend->>Backend: GET
+    Note right of Backend: DB Access and build response
+    Backend->>Frontend: Response[GET]
+    Note left of Frontend: Display data into UI
+```
+
+Since the instructions are rather generic and agnostic, the UI can be build on any device, such as a browser or a mobile app.

wbcore-2.2.4/docs/metadata/configs/endpoints.md

@@ -0,0 +1,56 @@
+# Endpoints
+
+The endpoint config class is in charge of defining some actions on the current resource. For example an `instance_endpoint` when looking at a list will make it possible to open an item in a list.
+
+The default behaviour is:
+- `instance_endpoint`:
+    - In a list: Make it possible to open/change an item
+    - In a form: Make it possible to change an item
+- `list_endpoint`:
+    - ???
+- `delete_endpoint`:
+    - Make it possible to delete an item
+- `create_endpoint`:
+    - Make it possible to create a new item
+
+Usually, the developer does not have to customize this class, as it auto-generates itself with the help of some parameters:
+
+1. For each endpoint it checks if the user has the necessary permissions, e.g. `create_endpoint` -> `<app_label>.add_<model>`
+2. It gets the default endpoint from the model class: `Model.get_endpoint_basename()`
+
+
+## Customizing the config class
+
+If, for some reason, the developer does not to override and customize his mechanism, it can be done by subclassing `wbcore.metadata.configs.endpoints.EndpointViewConfig` and set it as an attribute on your view `endpoint_config_class = MyEndpointViewConfig`.
+
+=== "endpoints.py"
+
+    ``` py
+    from wbcore.metadata.configs.endpoints import EndpointViewConfig
+
+
+    class MyEndpointViewConfig(EndpointViewConfig):
+
+        # Override this method to customize the base endpoint
+        # that is used by all other methods
+        def get_endpoint(self, **kwargs):
+            return "some-endpoint"
+
+        # Override this method to customize only the instance
+        # endpoint
+        def get_instance_endpoint(self, **kwargs):
+            return "some-instance-endpoint"
+
+    ```
+
+=== "viewsets.py"
+
+    ``` py
+    from wbcore import viewsets
+    from endpoints import MyEndpointViewConfig
+
+
+    class MyModelViewSet(viewsets.ModelViewSet):
+        endpoint_config_class = MyEndpointViewConfig
+
+    ```