You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/development/application-registry.md
+18-25
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,14 @@ The registry can be inspected by importing `registry` from `extras.registry`.
8
8
9
9
## Stores
10
10
11
+
### `data_backends`
12
+
13
+
A dictionary mapping data backend types to their respective classes. These are used to interact with [remote data sources](../models/core/datasource.md).
14
+
15
+
### `denormalized_fields`
16
+
17
+
Stores registration made using `netbox.denormalized.register()`. For each model, a list of related models and their field mappings is maintained to facilitate automatic updates.
18
+
11
19
### `model_features`
12
20
13
21
A dictionary of particular features (e.g. custom fields) mapped to the NetBox models which support them, arranged by app. For example:
@@ -20,38 +28,23 @@ A dictionary of particular features (e.g. custom fields) mapped to the NetBox mo
20
28
...
21
29
},
22
30
'webhooks': {
23
-
...
31
+
'extras': ['configcontext', 'tag', ...],
32
+
'dcim': ['site', 'rack', 'devicetype', ...],
24
33
},
25
34
...
26
35
}
27
36
```
28
37
29
-
### `plugin_menu_items`
38
+
Supported model features are listed in the [features matrix](./models.md#features-matrix).
30
39
31
-
Navigation menu items provided by NetBox plugins. Each plugin is registered as a key with the list of menu items it provides. An example:
40
+
### `plugins`
32
41
33
-
```python
34
-
{
35
-
'Plugin A': (
36
-
<MenuItem>, <MenuItem>, <MenuItem>,
37
-
),
38
-
'Plugin B': (
39
-
<MenuItem>, <MenuItem>, <MenuItem>,
40
-
),
41
-
}
42
-
```
42
+
This store maintains all registered items for plugins, such as navigation menus, template extensions, etc.
43
43
44
-
### `plugin_template_extensions`
44
+
### `search`
45
45
46
-
Plugin content that gets embedded into core NetBox templates. The store comprises NetBox models registered as dictionary keys, each pointing to a list of applicable template extension classes that exist. An example:
46
+
A dictionary mapping each model (identified by its app and label) to its search index class, if one has been registered for it.
A hierarchical mapping of registered views for each model. Mappings are added using the `register_model_view()` decorator, and URLs paths can be generated from these using `get_model_urls()`.
Copy file name to clipboardExpand all lines: docs/development/models.md
+34-18
Original file line number
Diff line number
Diff line change
@@ -2,38 +2,43 @@
2
2
3
3
## Model Types
4
4
5
-
A NetBox model represents a discrete object type such as a device or IP address. Per [Django convention](https://docs.djangoproject.com/en/stable/topics/db/models/), each model is defined as a Python class and has its own SQL table. All NetBox data models can be categorized by type.
5
+
A NetBox model represents a discrete object type such as a device or IP address. Per [Django convention](https://docs.djangoproject.com/en/stable/topics/db/models/), each model is defined as a Python class and has its own table in the PostgreSQL database. All NetBox data models can be categorized by type.
6
6
7
-
The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/contenttypes/) framework can be used to reference models within the database. A ContentType instance references a model by its `app_label` and `name`: For example, the Site model is referred to as `dcim.site`. The content type combined with an object's primary key form a globally unique identifier for the object (e.g. `dcim.site:123`).
7
+
The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/contenttypes/) framework is used to map Django models to database tables. A ContentType instance references a model by its `app_label` and `name`: For example, the Site model within the DCIM app is referred to as `dcim.site`. The content type combined with an object's primary key form a globally unique identifier for the object (e.g. `dcim.site:123`).
8
8
9
9
### Features Matrix
10
10
11
-
*[Change logging](../features/change-logging.md) - Changes to these objects are automatically recorded in the change log
12
-
*[Webhooks](../integrations/webhooks.md) - NetBox is capable of generating outgoing webhooks for these objects
13
-
*[Custom fields](../customization/custom-fields.md) - These models support the addition of user-defined fields
14
-
*[Export templates](../customization/export-templates.md) - Users can create custom export templates for these models
15
-
*[Tagging](../models/extras/tag.md)- The models can be tagged with user-defined tags
16
-
*[Journaling](../features/journaling.md) - These models support persistent historical commentary
17
-
* Nesting - These models can be nested recursively to create a hierarchy
Depending on its classification, each NetBox model may support various features which enhance its operation. Each feature is enabled by inheriting from its designated mixin class, and some features also make use of the [application registry](./application-registry.md#model_features).
|[Change logging](../features/change-logging.md)|`ChangeLoggingMixin`| - | Changes to these objects are automatically recorded in the change log |
16
+
| Cloning |`CloningMixin`| - | Provides the `clone()` method to prepare a copy |
17
+
|[Custom fields](../customization/custom-fields.md)|`CustomFieldsMixin`|`custom_fields`|These models support the addition of user-defined fields |
18
+
|[Custom links](../customization/custom-links.md)|`CustomLinksMixin`|`custom_links`| These models support the assignment of custom links |
19
+
|[Custom validation](../customization/custom-validation.md)|`CustomValidationMixin`| - | Supports the enforcement of custom validation rules|
20
+
|[Export templates](../customization/export-templates.md)|`ExportTemplatesMixin`|`export_templates`|Users can create custom export templates for these models |
21
+
|[Job results](../features/background-jobs.md)|`JobResultsMixin`|`job_results`| Users can create custom export templates for these models |
22
+
|[Journaling](../features/journaling.md)|`JournalingMixin`|`journaling`| These models support persistent historical commentary|
23
+
|[Synchronized data](../integrations/synchronized-data.md)|`SyncedDataMixin`|`synced_data`| Certain model data can be automatically synchronized from a remote data source|
24
+
|[Tagging](../models/extras/tag.md)|`TagsMixin`|`tags`| The models can be tagged with user-defined tags|
25
+
|[Webhooks](../integrations/webhooks.md)|`WebhooksMixin`|`webhooks`| NetBox is capable of generating outgoing webhooks for these objects|
26
26
27
27
## Models Index
28
28
29
29
### Primary Models
30
30
31
+
These are considered the "core" application models which are used to model network infrastructure.
@@ -76,6 +83,8 @@ The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/
76
83
77
84
### Nested Group Models
78
85
86
+
Nested group models behave like organizational model, but self-nest within a recursive hierarchy. For example, the Region model can be used to represent a hierarchy of countries, states, and cities.
These function as templates to effect the replication of device and virtual machine components. Component template models support a limited feature set, including change logging, custom validation, and webhooks.
* Synchronization of [remote data sources](../integrations/synchronized-data.md)
8
+
9
+
Additionally, NetBox plugins can enqueue their own background tasks. This is accomplished using the [JobResult model](../models/extras/jobresult.md). Background tasks are executed by the `rqworker` process(es).
10
+
11
+
## Scheduled Jobs
12
+
13
+
Background jobs can be configured to run immediately, or at a set time in the future. Scheduled jobs can also be configured to repeat at a set interval.
Some NetBox models support automatic synchronization of certain attributes from remote [data sources](../models/core/datasource.md), such as a git repository hosted on GitHub or GitLab. Data from the authoritative remote source is synchronized locally in NetBox as [data files](../models/core/datafile.md).
4
+
5
+
The following features support the use of synchronized data:
0 commit comments