Merge branch 'feature' into 6651-plugins-rq-queues

docs/additional-features/caching.md

@@ -1,25 +0,0 @@
-# Caching
-
-NetBox supports database query caching using [django-cacheops](https://github.com/Suor/django-cacheops) and Redis. When a query is made, the results are cached in Redis for a short period of time, as defined by the [CACHE_TIMEOUT](../configuration/optional-settings.md#cache_timeout) parameter (15 minutes by default). Within that time, all recurrences of that specific query will return the pre-fetched results from the cache.
-
-If a change is made to any of the objects returned by the query within that time, or if the timeout expires, the results are automatically invalidated and the next request for those results will be sent to the database.
-
-## Invalidating Cached Data
-
-Although caching is performed automatically and rarely requires administrative intervention, NetBox provides the `invalidate` management command to force invalidation of cached results. This command can reference a specific object by its type and numeric ID:
-
-```no-highlight
-$ python netbox/manage.py invalidate dcim.Device.34
-```
-
-Alternatively, it can also delete all cached results for an object type:
-
-```no-highlight
-$ python netbox/manage.py invalidate dcim.Device
-```
-
-Finally, calling it with the `all` argument will force invalidation of the entire cache database:
-
-```no-highlight
-$ python netbox/manage.py invalidate all
-```

docs/additional-features/webhooks.md

@@ -1,6 +1,6 @@
 # Webhooks
 
-A webhook is a mechanism for conveying to some external system a change that took place in NetBox. For example, you may want to notify a monitoring system whenever the status of a device is updated in NetBox. This can be done by creating a webhook for the device model in NetBox and identifying the webhook receiver. When NetBox detects a change to a device, an HTTP request containing the details of the change and who made it be sent to the specified receiver. Webhooks are configured in the admin UI under Extras > Webhooks.
+A webhook is a mechanism for conveying to some external system a change that took place in NetBox. For example, you may want to notify a monitoring system whenever the status of a device is updated in NetBox. This can be done by creating a webhook for the device model in NetBox and identifying the webhook receiver. When NetBox detects a change to a device, an HTTP request containing the details of the change and who made it be sent to the specified receiver. Webhooks are managed under Logging > Webhooks.
 
 ## Configuration
 

docs/administration/housekeeping.md

@@ -0,0 +1,10 @@
+# Housekeeping
+
+NetBox includes a `housekeeping` management command that should be run nightly. This command handles:
+
+* Clearing expired authentication sessions from the database
+* Deleting changelog records older than the configured [retention time](../configuration/optional-settings.md#changelog_retention)
+
+This command can be invoked directly, or by using the shell script provided at `/opt/netbox/contrib/netbox-housekeeping.sh`. This script can be copied into your cron scheduler's daily jobs directory (e.g. `/etc/cron.daily`) or referenced directly within the cron configuration file.
+
+The `housekeeping` command can also be run manually at any time: Running the command outside of scheduled execution times will not interfere with its operation.

docs/administration/netbox-shell.md

@@ -194,7 +194,7 @@ To delete multiple objects at once, call `delete()` on a filtered queryset. It's
 >>> Device.objects.filter(name__icontains='test').count()
 27
 >>> Device.objects.filter(name__icontains='test').delete()
-(35, {'dcim.DeviceBay': 0, 'secrets.Secret': 0, 'dcim.InterfaceConnection': 4,
+(35, {'dcim.DeviceBay': 0, 'dcim.InterfaceConnection': 4,
 'extras.ImageAttachment': 0, 'dcim.Device': 27, 'dcim.Interface': 4,
 'dcim.ConsolePort': 0, 'dcim.PowerPort': 0})
 ```

docs/configuration/optional-settings.md

@@ -52,14 +52,6 @@ BASE_PATH = 'netbox/'
 
 ---
 
-## CACHE_TIMEOUT
-
-Default: 900
-
-The number of seconds that cache entries will be retained before expiring.
-
----
-
 ## CHANGELOG_RETENTION
 
 Default: 90
@@ -96,6 +88,12 @@ CORS_ORIGIN_WHITELIST = [
 
 ---
 
+## CUSTOM_VALIDATORS
+
+This is a mapping of models to [custom validators](../customization/custom-validation.md) that have been defined locally to enforce custom validation logic.
+
+---
+
 ## DEBUG
 
 Default: False
@@ -144,7 +142,7 @@ In order to send email, NetBox needs an email server configured. The following i
 !!! note
     The `USE_SSL` and `USE_TLS` parameters are mutually exclusive.
 
-Email is sent from NetBox only for critical events or if configured for [logging](#logging). If you would like to test the email server configuration, Django provides a convenient [send_mail()](https://docs.djangoproject.com/en/stable/topics/email/#send-mail) fuction accessible within the NetBox shell:
+Email is sent from NetBox only for critical events or if configured for [logging](#logging). If you would like to test the email server configuration, Django provides a convenient [send_mail()](https://docs.djangoproject.com/en/stable/topics/email/#send-mail) function accessible within the NetBox shell:
 
 ```no-highlight
 # python ./manage.py nbshell
@@ -195,6 +193,14 @@ EXEMPT_VIEW_PERMISSIONS = ['*']
 
 ---
 
+## GRAPHQL_ENABLED
+
+Default: True
+
+Setting this to False will disable the GraphQL API.
+
+---
+
 ## HTTP_PROXIES
 
 Default: None
@@ -261,7 +267,7 @@ LOGGING = {
 
 Default: False
 
-Setting this to True will permit only authenticated users to access any part of NetBox. By default, anonymous users are permitted to access most data in NetBox (excluding secrets) but not make any changes.
+Setting this to True will permit only authenticated users to access any part of NetBox. By default, anonymous users are permitted to access most data in NetBox but not make any changes.
 
 ---
 
@@ -472,19 +478,11 @@ When remote user authentication is in use, this is the name of the HTTP header w
 
 ---
 
-## RELEASE_CHECK_TIMEOUT
-
-Default: 86,400 (24 hours)
-
-The number of seconds to retain the latest version that is fetched from the GitHub API before automatically invalidating it and fetching it from the API again. This must be set to at least one hour (3600 seconds).
-
----
-
 ## RELEASE_CHECK_URL
 
 Default: None (disabled)
 
-This parameter defines the URL of the repository that will be checked periodically for new NetBox releases. When a new release is detected, a message will be displayed to administrative users on the home page. This can be set to the official repository (`'https://api.github.com/repos/netbox-community/netbox/releases'`) or a custom fork. Set this to `None` to disable automatic update checks.
+This parameter defines the URL of the repository that will be checked for new NetBox releases. When a new release is detected, a message will be displayed to administrative users on the home page. This can be set to the official repository (`'https://api.github.com/repos/netbox-community/netbox/releases'`) or a custom fork. Set this to `None` to disable automatic update checks.
 
 !!! note
     The URL provided **must** be compatible with the [GitHub REST API](https://docs.github.com/en/rest).
@@ -495,7 +493,7 @@ This parameter defines the URL of the repository that will be checked periodical
 
 Default: `$INSTALL_ROOT/netbox/reports/`
 
-The file path to the location where custom reports will be kept. By default, this is the `netbox/reports/` directory within the base NetBox installation path.
+The file path to the location where [custom reports](../customization/reports.md) will be kept. By default, this is the `netbox/reports/` directory within the base NetBox installation path.
 
 ---
 
@@ -511,7 +509,7 @@ The maximum execution time of a background task (such as running a custom script
 
 Default: `$INSTALL_ROOT/netbox/scripts/`
 
-The file path to the location where custom scripts will be kept. By default, this is the `netbox/scripts/` directory within the base NetBox installation path.
+The file path to the location where [custom scripts](../customization/custom-scripts.md) will be kept. By default, this is the `netbox/scripts/` directory within the base NetBox installation path.
 
 ---
 

docs/core-functionality/secrets.md

@@ -1,8 +0,0 @@
-# Secrets
-
-{!docs/models/secrets/secret.md!}
-{!docs/models/secrets/secretrole.md!}
-
----
-
-{!docs/models/secrets/userkey.md!}

docs/customization/custom-fields.md

@@ -8,7 +8,7 @@ Within the database, custom fields are stored as JSON data directly alongside ea
 
 ## Creating Custom Fields
 
-Custom fields must be created through the admin UI under Extras > Custom Fields. NetBox supports six types of custom field:
+Custom fields may be created by navigating to Customization > Custom Fields. NetBox supports six types of custom field:
 
 * Text: Free-form text (up to 255 characters)
 * Integer: A whole number (positive or negative)

docs/customization/custom-links.md

@@ -1,8 +1,8 @@
 # Custom Links
 
-Custom links allow users to display arbitrary hyperlinks to external content within NetBox object views. These are helpful for cross-referencing related records in systems outside of NetBox. For example, you might create a custom link on the device view which links to the current device in a network monitoring system.
+Custom links allow users to display arbitrary hyperlinks to external content within NetBox object views. These are helpful for cross-referencing related records in systems outside NetBox. For example, you might create a custom link on the device view which links to the current device in a network monitoring system.
 
-Custom links are created under the admin UI. Each link is associated with a particular NetBox object type (site, device, prefix, etc.) and will be displayed on relevant views. Each link is assigned text and a URL, both of which support Jinja2 templating. The text and URL are rendered with the context variable `obj` representing the current object.
+Custom links are created by navigating to Customization > Custom Links. Each link is associated with a particular NetBox object type (site, device, prefix, etc.) and will be displayed on relevant views. Each link is assigned text and a URL, both of which support Jinja2 templating. The text and URL are rendered with the context variable `obj` representing the current object.
 
 For example, you might define a link like this:
 
@@ -15,7 +15,7 @@ When viewing a device named Router4, this link would render as:
 <a href="https://nms.example.com/nodes/?name=Router4">View NMS</a>
 ```
 
-Custom links appear as buttons at the top right corner of the page. Numeric weighting can be used to influence the ordering of links.
+Custom links appear as buttons in the top right corner of the page. Numeric weighting can be used to influence the ordering of links.
 
 ## Context Data
 

docs/customization/custom-scripts.md

@@ -170,14 +170,9 @@ Similar to `ChoiceVar`, but allows for the selection of multiple choices.
 A particular object within NetBox. Each ObjectVar must specify a particular model, and allows the user to select one of the available instances. ObjectVar accepts several arguments, listed below.
 
 * `model` - The model class
-* `display_field` - The name of the REST API object field to display in the selection list (default: `'display'`)
 * `query_params` - A dictionary of query parameters to use when retrieving available options (optional)
 * `null_option` - A label representing a "null" or empty choice (optional)
 
-!!! warning
-    The `display_field` parameter is now deprecated, and will be removed in NetBox v3.0. All ObjectVar instances will
-    instead use the new standard `display` field for all serializers (introduced in NetBox v2.11).
-
 To limit the selections available within the list, additional query parameters can be passed as the `query_params` dictionary. For example, to show only devices with an "active" status:
 
 ```python
@@ -288,7 +283,6 @@ class NewBranchScript(Script):
     switch_model = ObjectVar(
         description="Access switch model",
         model=DeviceType,
-        display_field='model',
         query_params={
             'manufacturer_id': '$manufacturer'
         }

docs/customization/custom-validation.md

@@ -0,0 +1,86 @@
+# Custom Validation
+
+NetBox validates every object prior to it being written to the database to ensure data integrity. This validation includes things like checking for proper formatting and that references to related objects are valid. However, you may wish to supplement this validation with some rules of your own. For example, perhaps you require that every site's name conforms to a specific pattern.  This can be done using NetBox's `CustomValidator` class.
+
+## CustomValidator
+
+### Validation Rules
+
+A custom validator can be instantiated by passing a mapping of attributes to a set of rules to which that attribute must conform. For example:
+
+```python
+from extras.validators import CustomValidator
+
+CustomValidator({
+    'name': {
+        'min_length': 5,
+        'max_length': 30,
+    }
+})
+```
+
+This defines a custom validator which checks that the length of the `name` attribute for an object is at least five characters long, and no longer than 30 characters. This validation is executed _after_ NetBox has performed its own internal validation.
+
+The `CustomValidator` class supports several validation types:
+
+* `min`: Minimum value
+* `max`: Maximum value
+* `min_length`: Minimum string length
+* `max_length`: Maximum string length
+* `regex`: Application of a [regular expression](https://en.wikipedia.org/wiki/Regular_expression)
+* `required`: A value must be specified
+* `prohibited`: A value must _not_ be specified
+
+The `min` and `max` types should be defined for numeric values, whereas `min_length`, `max_length`, and `regex` are suitable for character strings (text values). The `required` and `prohibited` validators may be used for any field, and should be passed a value of `True`.
+
+!!! warning
+    Bear in mind that these validators merely supplement NetBox's own validation: They will not override it. For example, if a certain model field is required by NetBox, setting a validator for it with `{'prohibited': True}` will not work.
+
+### Custom Validation Logic
+
+There may be instances where the provided validation types are insufficient. The `CustomValidator` class can be extended to enforce arbitrary validation logic by overriding its `validate()` method, and calling `fail()` when an unsatisfactory condition is detected.
+
+```python
+from extras.validators import CustomValidator
+
+class MyValidator(CustomValidator):
+    def validate(self, instance):
+        if instance.status == 'active' and not instance.description:
+            self.fail("Active sites must have a description set!", field='status')
+```
+
+The `fail()` method may optionally specify a field with which to associate the supplied error message. If specified, the error message will appear to the user as associated with this field. If omitted, the error message will not be associated with any field.
+
+## Assigning Custom Validators
+
+Custom validators are associated with specific NetBox models under the [CUSTOM_VALIDATORS](../configuration/optional-settings.md#custom_validators) configuration parameter, as such:
+
+```python
+CUSTOM_VALIDATORS = {
+    'dcim.site': (
+        Validator1,
+        Validator2,
+        Validator3
+    )
+}
+```
+
+!!! note
+    Even if defining only a single validator, it must be passed as an iterable.
+
+When it is not necessary to define a custom `validate()` method, you may opt to pass a `CustomValidator` instance directly:
+
+```python
+from extras.validators import CustomValidator
+
+CUSTOM_VALIDATORS = {
+    'dcim.site': (
+        CustomValidator({
+            'name': {
+                'min_length': 5,
+                'max_length': 30,
+            }
+        }),
+    )
+}
+```

docs/customization/export-templates.md

@@ -1,6 +1,6 @@
 # Export Templates
 
-NetBox allows users to define custom templates that can be used when exporting objects. To create an export template, navigate to Extras > Export Templates under the admin interface.
+NetBox allows users to define custom templates that can be used when exporting objects. To create an export template, navigate to Customization > Export Templates.
 
 Each export template is associated with a certain type of object. For instance, if you create an export template for VLANs, your custom template will appear under the "Export" button on the VLANs list. Each export template must have a name, and may optionally designate a specific export [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) and/or file extension.
 
@@ -33,6 +33,16 @@ The `as_attachment` attribute of an export template controls its behavior when r
 
 A MIME type and file extension can optionally be defined for each export template. The default MIME type is `text/plain`.
 
+## REST API Integration
+
+When it is necessary to provide authentication credentials (such as when [`LOGIN_REQUIRED`](../configuration/optional-settings.md#login_required) has been enabled), it is recommended to render export templates via the REST API. This allows the client to specify an authentication token. To render an export template via the REST API, make a `GET` request to the model's list endpoint and append the `export` parameter specifying the export template name. For example:
+
+```
+GET /api/dcim/sites/?export=MyTemplateName
+```
+
+Note that the body of the response will contain only the rendered export template content, as opposed to a JSON object or list.
+
 ## Example
 
 Here's an example device export template that will generate a simple Nagios configuration from a list of devices.

docs/development/extending-models.md

@@ -32,19 +32,15 @@ class Foo(models.Model):
             raise ValidationError()
 ```
 
-## 3. Add CSV helpers
-
-Add the name of the new field to `csv_headers` and included a CSV-friendly representation of its data in the model's `to_csv()` method. These will be used when exporting objects in CSV format.
-
-## 4. Update relevant querysets
+## 3. Update relevant querysets
 
 If you're adding a relational field (e.g. `ForeignKey`) and intend to include the data when retreiving a list of objects, be sure to include the field using `prefetch_related()` as appropriate. This will optimize the view and avoid extraneous database queries.
 
-## 5. Update API serializer
+## 4. Update API serializer
 
 Extend the model's API serializer in `<app>.api.serializers` to include the new field. In most cases, it will not be necessary to also extend the nested serializer, which produces a minimal represenation of the model.
 
-## 6. Add field to forms
+## 5. Add field to forms
 
 Extend any forms to include the new field as appropriate. Common forms include:
 
@@ -53,19 +49,19 @@ Extend any forms to include the new field as appropriate. Common forms include:
 * **CSV import** - The form used when bulk importing objects in CSV format
 * **Filter** - Displays the options available for filtering a list of objects (both UI and API)
 
-## 7. Extend object filter set
+## 6. Extend object filter set
 
 If the new field should be filterable, add it to the `FilterSet` for the model. If the field should be searchable, remember to reference it in the FilterSet's `search()` method.
 
-## 8. Add column to object table
+## 7. Add column to object table
 
 If the new field will be included in the object list view, add a column to the model's table. For simple fields, adding the field name to `Meta.fields` will be sufficient. More complex fields may require declaring a custom column.
 
-## 9. Update the UI templates
+## 8. Update the UI templates
 
 Edit the object's view template to display the new field. There may also be a custom add/edit form template that needs to be updated.
 
-## 10. Create/extend test cases
+## 9. Create/extend test cases
 
 Create or extend the relevant test cases to verify that the new field and any accompanying validation logic perform as expected. This is especially important for relational fields. NetBox incorporates various test suites, including:
 
@@ -77,6 +73,6 @@ Create or extend the relevant test cases to verify that the new field and any ac
 
 Be diligent to ensure all of the relevant test suites are adapted or extended as necessary to test any new functionality.
 
-## 11. Update the model's documentation
+## 10. Update the model's documentation
 
 Each model has a dedicated page in the documentation, at `models/<app>/<model>.md`. Update this file to include any relevant information about the new field.

docs/development/index.md

@@ -25,7 +25,6 @@ NetBox components are arranged into functional subsections called _apps_ (a carr
 * `dcim`: Datacenter infrastructure management (sites, racks, and devices)
 * `extras`: Additional features not considered part of the core data model
 * `ipam`: IP address management (VRFs, prefixes, IP addresses, and VLANs)
-* `secrets`: Encrypted storage of sensitive data (e.g. login credentials)
 * `tenancy`: Tenants (such as customers) to which NetBox objects may be assigned
 * `users`: Authentication and user preferences
 * `utilities`: Resources which are not user-facing (extendable classes, etc.)

docs/development/models.md

@@ -10,8 +10,8 @@ The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/
 
 * [Change logging](../additional-features/change-logging.md) - Changes to these objects are automatically recorded in the change log
 * [Webhooks](../additional-features/webhooks.md) - NetBox is capable of generating outgoing webhooks for these objects
-* [Custom fields](../additional-features/custom-fields.md) - These models support the addition of user-defined fields
-* [Export templates](../additional-features/export-templates.md) - Users can create custom export templates for these models
+* [Custom fields](../customization/custom-fields.md) - These models support the addition of user-defined fields
+* [Export templates](../customization/export-templates.md) - Users can create custom export templates for these models
 * [Tagging](../models/extras/tag.md) - The models can be tagged with user-defined tags
 * [Journaling](../additional-features/journaling.md) - These models support persistent historical commentary
 * Nesting - These models can be nested recursively to create a hierarchy
@@ -47,7 +47,6 @@ The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/
 * [ipam.Service](../models/ipam/service.md)
 * [ipam.VLAN](../models/ipam/vlan.md)
 * [ipam.VRF](../models/ipam/vrf.md)
-* [secrets.Secret](../models/secrets/secret.md)
 * [tenancy.Tenant](../models/tenancy/tenant.md)
 * [virtualization.Cluster](../models/virtualization/cluster.md)
 * [virtualization.VirtualMachine](../models/virtualization/virtualmachine.md)
@@ -62,7 +61,6 @@ The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/
 * [ipam.RIR](../models/ipam/rir.md)
 * [ipam.Role](../models/ipam/role.md)
 * [ipam.VLANGroup](../models/ipam/vlangroup.md)
-* [secrets.SecretRole](../models/secrets/secretrole.md)
 * [virtualization.ClusterGroup](../models/virtualization/clustergroup.md)
 * [virtualization.ClusterType](../models/virtualization/clustertype.md)
 

docs/development/signals.md

@@ -0,0 +1,11 @@
+# Signals
+
+In addition to [Django's built-in signals](https://docs.djangoproject.com/en/stable/topics/signals/), NetBox defines some of its own, listed below.
+
+## post_clean
+
+This signal is sent by models which inherit from `CustomValidationMixin` at the end of their `clean()` method.
+
+### Receivers
+
+* `extras.signals.run_custom_validators()`

docs/graphql-api/overview.md

@@ -0,0 +1,70 @@
+# GraphQL API Overview
+
+NetBox provides a read-only [GraphQL](https://graphql.org/) API to complement its REST API. This API is powered by the [Graphene](https://graphene-python.org/) library and [Graphene-Django](https://docs.graphene-python.org/projects/django/en/latest/).
+
+## Queries
+
+GraphQL enables the client to specify an arbitrary nested list of fields to include in the response. All queries are made to the root `/graphql` API endpoint. For example, to return the circuit ID and provider name of each circuit with an active status, you can issue a request such as the following:
+
+```
+curl -H "Authorization: Token $TOKEN" \
+-H "Content-Type: application/json" \
+-H "Accept: application/json" \
+http://netbox/graphql/ \
+--data '{"query": "query {circuits(status:\"active\" {cid provider {name}}}"}'
+```
+
+The response will include the requested data formatted as JSON:
+
+```json
+{
+  "data": {
+    "circuits": [
+      {
+        "cid": "1002840283",
+        "provider": {
+          "name": "CenturyLink"
+        }
+      },
+      {
+        "cid": "1002840457",
+        "provider": {
+          "name": "CenturyLink"
+        }
+      }
+    ]
+  }
+}
+```
+
+!!! note
+    It's recommended to pass the return data through a JSON parser such as `jq` for better readability.
+
+NetBox provides both a singular and plural query field for each object type:
+
+* `$OBJECT`: Returns a single object. Must specify the object's unique ID as `(id: 123)`.
+* `$OBJECT_list`: Returns a list of objects, optionally filtered by given parameters.
+
+For example, query `device(id:123)` to fetch a specific device (identified by its unique ID), and query `device_list` (with an optional set of fitlers) to fetch all devices.
+
+For more detail on constructing GraphQL queries, see the [Graphene documentation](https://docs.graphene-python.org/en/latest/).
+
+## Filtering
+
+The GraphQL API employs the same filtering logic as the UI and REST API. Filters can be specified as key-value pairs within parentheses immediately following the query name. For example, the following will return only sites within the North Carolina region with a status of active:
+
+```
+{"query": "query {sites(region:\"north-carolina\", status:\"active\") {name}}"}
+```
+
+## Authentication
+
+NetBox's GraphQL API uses the same API authentication tokens as its REST API. Authentication tokens are included with requests by attaching an `Authorization` HTTP header in the following form:
+
+```
+Authorization: Token $TOKEN
+```
+
+## Disabling the GraphQL API
+
+If not needed, the GraphQL API can be disabled by setting the [`GRAPHQL_ENABLED`](../configuration/optional-settings.md#graphql_enabled) configuration parameter to False and restarting NetBox.

docs/installation/3-netbox.md

@@ -247,6 +247,18 @@ Password (again):
 Superuser created successfully.
 ```
 
+## Schedule the Housekeeping Task
+
+NetBox includes a `housekeeping` management command that handles some recurring cleanup tasks, such as clearing out old sessions and expired change records. Although this command may be run manually, it is recommended to configure a scheduled job using the system's `cron` daemon or a similar utility.
+
+A shell script which invokes this command is included at `contrib/netbox-housekeeping.sh`. It can be copied to your system's daily cron task directory, or included within the crontab directly. (If installing NetBox into a nonstandard path, be sure to update the system paths within this script first.)
+
+```shell
+cp /opt/netbox/contrib/netbox-housekeeping.sh /etc/cron.daily/
+```
+
+See the [housekeeping documentation](../administration/housekeeping.md) for further details.
+
 ## Test the Application
 
 At this point, we should be able to run NetBox's development server for testing. We can check by starting a development instance:

docs/installation/upgrading.md

@@ -102,5 +102,12 @@ Finally, restart the gunicorn and RQ services:
 sudo systemctl restart netbox netbox-rq
 ```
 
-!!! note
-    If upgrading from an installation that uses supervisord, please see the instructions for [migrating to systemd](migrating-to-systemd.md). The use of supervisord is no longer supported.
+## Verify Housekeeping Scheduling
+
+If upgrading from a release prior to NetBox v3.0, check that a cron task (or similar scheduled process) has been configured to run NetBox's nightly housekeeping command. A shell script which invokes this command is included at `contrib/netbox-housekeeping.sh`. It can be copied to your system's daily cron task directory, or included within the crontab directly. (If NetBox has been installed in a nonstandard path, be sure to update the system paths within this script first.)
+
+```shell
+cp /opt/netbox/contrib/netbox-housekeeping.sh /etc/cron.daily/
+```
+
+See the [housekeeping documentation](../administration/housekeeping.md) for further details.

docs/models/dcim/virtualchassis.md

@@ -2,7 +2,7 @@
 
 A virtual chassis represents a set of devices which share a common control plane. A common example of this is a stack of switches which are connected and configured to operate as a single device. A virtual chassis must be assigned a name and may be assigned a domain.
 
-Each device in the virtual chassis is referred to as a VC member, and assigned a position and (optionally) a priority. VC member devices commonly reside within the same rack, though this is not a requirement. One of the devices may be designated as the VC master: This device will typically be assigned a name, secrets, services, and other attributes related to managing the VC.
+Each device in the virtual chassis is referred to as a VC member, and assigned a position and (optionally) a priority. VC member devices commonly reside within the same rack, though this is not a requirement. One of the devices may be designated as the VC master: This device will typically be assigned a name, services, and other attributes related to managing the VC.
 
 !!! note
     It's important to recognize the distinction between a virtual chassis and a chassis-based device. A virtual chassis is **not** suitable for modeling a chassis-based switch with removable line cards (such as the Juniper EX9208), as its line cards are _not_ physically autonomous devices.

docs/models/secrets/secret.md

@@ -1,5 +0,0 @@
-# Secrets
-
-A secret represents a single credential or other sensitive string of characters which must be stored securely. Each secret is assigned to a device within NetBox. The plaintext value of a secret is encrypted to a ciphertext immediately prior to storage within the database using a 256-bit AES master key. A SHA256 hash of the plaintext is also stored along with each ciphertext to validate the decrypted plaintext.
-
-Each secret can also store an optional name parameter, which is not encrypted. This may be useful for storing user names.

docs/models/secrets/secretrole.md

@@ -1,9 +0,0 @@
-# Secret Roles
-
-Each secret is assigned a functional role which indicates what it is used for. Secret roles are customizable. Typical roles might include:
-
-* Login credentials
-* SNMP community strings
-* RADIUS/TACACS+ keys
-* IKE key strings
-* Routing protocol shared secrets

docs/models/secrets/userkey.md

@@ -1,35 +0,0 @@
-# User Keys
-
-Each user within NetBox can associate his or her account with an RSA public key. If activated by an administrator, this user key will contain a unique, encrypted copy of the AES master key needed to retrieve secret data.
-
-User keys may be created by users individually, however they are of no use until they have been activated by a user who already possesses an active user key.
-
-## Supported Key Format
-
-Public key formats supported
-
-- PKCS#1 RSAPublicKey* (PEM header: BEGIN RSA PUBLIC KEY)
-- X.509 SubjectPublicKeyInfo** (PEM header: BEGIN PUBLIC KEY)
-- **OpenSSH line format is not supported.**
-
-Private key formats supported (unencrypted)
-
-- PKCS#1 RSAPrivateKey** (PEM header: BEGIN RSA PRIVATE KEY)
-- PKCS#8 PrivateKeyInfo* (PEM header: BEGIN PRIVATE KEY)
-
-
-## Creating the First User Key
-
-When NetBox is first installed, it contains no encryption keys. Before it can store secrets, a user (typically the superuser) must create a user key. This can be done by navigating to Profile > User Key.
-
-To create a user key, you can either generate a new RSA key pair, or upload the public key belonging to a pair you already have. If generating a new key pair, **you must save the private key** locally before saving your new user key. Once your user key has been created, its public key will be displayed under your profile.
-
-When the first user key is created in NetBox, a random master encryption key is generated automatically. This key is then encrypted using the public key provided and stored as part of your user key. **The master key cannot be recovered** without your private key.
-
-Once a user key has been assigned an encrypted copy of the master key, it is considered activated and can now be used to encrypt and decrypt secrets.
-
-## Creating Additional User Keys
-
-Any user can create his or her user key by generating or uploading a public RSA key. However, a user key cannot be used to encrypt or decrypt secrets until it has been activated with an encrypted copy of the master key.
-
-Only an administrator with an active user key can activate other user keys. To do so, access the NetBox admin UI and navigate to Secrets > User Keys. Select the user key(s) to be activated, and select "activate selected user keys" from the actions dropdown. You will need to provide your private key in order to decrypt the master key. A copy of the master key is then encrypted using the public key associated with the user key being activated.

docs/plugins/development.md

@@ -113,7 +113,6 @@ NetBox looks for the `config` variable within a plugin's `__init__.py` to load i
 | `min_version` | Minimum version of NetBox with which the plugin is compatible |
 | `max_version` | Maximum version of NetBox with which the plugin is compatible |
 | `middleware` | A list of middleware classes to append after NetBox's build-in middleware |
-| `caching_config` | Plugin-specific cache configuration
 | `template_extensions` | The dotted path to the list of template extension classes (default: `template_content.template_extensions`) |
 | `menu_items` | The dotted path to the list of menu items provided by the plugin (default: `navigation.menu_items`) |
 
@@ -386,34 +385,6 @@ class SiteAnimalCount(PluginTemplateExtension):
 template_extensions = [SiteAnimalCount]
 ```
 
-## Caching Configuration
-
-By default, all query operations within a plugin are cached. To change this, define a caching configuration under the PluginConfig class' `caching_config` attribute. All configuration keys will be applied within the context of the plugin; there is no need to include the plugin name. An example configuration is below:
-
-```python
-class MyPluginConfig(PluginConfig):
-    ...
-    caching_config = {
-        'foo': {
-            'ops': 'get',
-            'timeout': 60 * 15,
-        },
-        '*': {
-            'ops': 'all',
-        }
-    }
-```
-
-To disable caching for your plugin entirely, set:
-
-```python
-caching_config = {
-    '*': None
-}
-```
-
-See the [django-cacheops](https://github.com/Suor/django-cacheops) documentation for more detail on configuring caching.
-
 ## Background Tasks
 
 By default, Netbox provides 3 differents [RQ](https://python-rq.org/) queues to run background jobs : *high*, *default* and *low*.
@@ -440,4 +411,4 @@ In case you create dedicated queues for your plugin, it is strongly advised to a
 
 ```
 python manage.py rqworker myplugin.queue1 myplugin.queue2 myplugin.queue-whatever-the-name
-```
+```

docs/release-notes/index.md

@@ -1 +1 @@
-version-2.11.md
+version-3.0.md

docs/release-notes/version-2.11.md

@@ -1,10 +1,26 @@
 # NetBox v2.11
 
-## v2.11.8 (FUTURE)
+## v2.11.9 (2021-07-08)
+
+### Bug Fixes
+
+* [#6456](https://github.com/netbox-community/netbox/issues/6456) - API schema type should be boolean for `_occupied` on cable termination models
+* [#6710](https://github.com/netbox-community/netbox/issues/6710) - Fix assignment of VM interface parent via REST API
+* [#6714](https://github.com/netbox-community/netbox/issues/6714) - Fix rendering of device type component creation forms
+
+---
+
+## v2.11.8 (2021-07-06)
 
 ### Enhancements
 
+* [#5503](https://github.com/netbox-community/netbox/issues/5503) - Annotate short date & time fields with their longer form
+* [#6138](https://github.com/netbox-community/netbox/issues/6138) - Add an `empty` filter modifier for character fields
+* [#6200](https://github.com/netbox-community/netbox/issues/6200) - Add rack reservations to global search
+* [#6368](https://github.com/netbox-community/netbox/issues/6368) - Enable virtual chassis assignment during bulk import of devices
 * [#6620](https://github.com/netbox-community/netbox/issues/6620) - Show assigned VMs count under device role view
+* [#6666](https://github.com/netbox-community/netbox/issues/6666) - Show management-only status under interface detail view
+* [#6667](https://github.com/netbox-community/netbox/issues/6667) - Display VM memory as GB/TB as appropriate
 
 ### Bug Fixes
 
@@ -12,6 +28,9 @@
 * [#6637](https://github.com/netbox-community/netbox/issues/6637) - Fix group assignment in "available VLANs" link under VLAN group view
 * [#6640](https://github.com/netbox-community/netbox/issues/6640) - Disallow numeric values in custom text fields
 * [#6652](https://github.com/netbox-community/netbox/issues/6652) - Fix exception when adding components in bulk to multiple devices
+* [#6676](https://github.com/netbox-community/netbox/issues/6676) - Fix device/VM counts per cluster under cluster type/group views
+* [#6680](https://github.com/netbox-community/netbox/issues/6680) - Allow setting custom field values for VM interfaces on initial creation
+* [#6695](https://github.com/netbox-community/netbox/issues/6695) - Fix exception when importing device type with invalid front port definition
 
 ---
 

docs/release-notes/version-2.6.md

@@ -218,7 +218,7 @@
 
 #### Custom Scripts ([#3415](https://github.com/netbox-community/netbox/issues/3415))
 
-Custom scripts allow for the execution of arbitrary code via the NetBox UI. They can be used to automatically create, manipulate, or clean up objects or perform other tasks within NetBox. Scripts are defined as Python files which contain one or more subclasses of `extras.scripts.Script`. Variable fields can be defined within scripts, which render as form fields within the web UI to prompt the user for input data. Scripts are executed and information is logged via the web UI. Please see [the docs](https://netbox.readthedocs.io/en/stable/additional-features/custom-scripts/) for more detail.
+Custom scripts allow for the execution of arbitrary code via the NetBox UI. They can be used to automatically create, manipulate, or clean up objects or perform other tasks within NetBox. Scripts are defined as Python files which contain one or more subclasses of `extras.scripts.Script`. Variable fields can be defined within scripts, which render as form fields within the web UI to prompt the user for input data. Scripts are executed and information is logged via the web UI. Please see [the docs](https://netbox.readthedocs.io/en/stable/customization/custom-scripts/) for more detail.
 
 Note: There are currently no API endpoints for this feature. These are planned for the upcoming v2.7 release.
 

docs/release-notes/version-3.0.md

@@ -0,0 +1,115 @@
+# NetBox v3.0
+
+## v3.0-beta1 (FUTURE)
+
+### Breaking Changes
+
+* The default CSV export format for all objects now includes all available data. Additionally, the CSV headers now use human-friendly titles rather than the raw field names.
+* Support for queryset caching configuration (`caching_config`) has been removed from the plugins API (see [#6639](https://github.com/netbox-community/netbox/issues/6639)).
+* The `cacheops_*` metrics have been removed from the Prometheus exporter (see [#6639](https://github.com/netbox-community/netbox/issues/6639)).
+* The `invalidate` management command has been removed.
+* The redundant REST API endpoints for console, power, and interface connections have been removed. The same data can be retrieved using the respective model endpoints with the `?connected=True` filter applied.
+
+### New Features
+
+### REST API Token Provisioning ([#5264](https://github.com/netbox-community/netbox/issues/5264))
+
+This release introduces the `/api/users/tokens/` REST API endpoint, which includes a child endpoint that can be employed by a user to provision a new REST API token. This allows a user to gain REST API access without needing to first create a token via the web UI.
+
+```
+$ curl -X POST \
+-H "Content-Type: application/json" \
+-H "Accept: application/json; indent=4" \
+https://netbox/api/users/tokens/provision/
+{
+    "username": "hankhill",
+    "password: "I<3C3H8",
+}
+```
+
+If the supplied credentials are valid, NetBox will create and return a new token for the user.
+
+#### Custom Model Validation ([#5963](https://github.com/netbox-community/netbox/issues/5963))
+
+This release introduces the [`CUSTOM_VALIDATORS`](../configuration/optional-settings.md#custom_validators) configuration parameter, which allows administrators to map NetBox models to custom validator classes to enforce custom validation logic. For example, the following configuration requires every site to have a name of at least ten characters and a description:
+
+```python
+from extras.validators import CustomValidator
+
+CUSTOM_VALIDATORS = {
+    'dcim.site': (
+        CustomValidator({
+            'name': {
+                'min_length': 10,
+            },
+            'description': {
+                'required': True,
+            }
+        }),
+    )
+}
+```
+
+CustomValidator can also be subclassed to enforce more complex logic by overriding its `validate()` method. See the [custom validation](../customization/custom-validation.md) documentation for more details.
+
+### Enhancements
+
+* [#2434](https://github.com/netbox-community/netbox/issues/2434) - Add option to assign IP address upon creating a new interface
+* [#3665](https://github.com/netbox-community/netbox/issues/3665) - Enable rendering export templates via REST API
+* [#3682](https://github.com/netbox-community/netbox/issues/3682) - Add `color` field to front and rear ports
+* [#4609](https://github.com/netbox-community/netbox/issues/4609) - Allow marking prefixes as fully utilized
+* [#5806](https://github.com/netbox-community/netbox/issues/5806) - Add kilometer and mile as choices for cable length unit
+* [#6154](https://github.com/netbox-community/netbox/issues/6154) - Allow decimal values for cable lengths
+* [#6590](https://github.com/netbox-community/netbox/issues/6590) - Introduce a nightly housekeeping command to clear expired sessions and change records
+
+### Other Changes
+
+* [#5223](https://github.com/netbox-community/netbox/issues/5223) - Remove the console/power/interface connections REST API endpoints
+* [#5532](https://github.com/netbox-community/netbox/issues/5532) - Drop support for Python 3.6
+* [#5994](https://github.com/netbox-community/netbox/issues/5994) - Drop support for `display_field` argument on ObjectVar
+* [#6068](https://github.com/netbox-community/netbox/issues/6068) - Drop support for legacy static CSV export
+* [#6338](https://github.com/netbox-community/netbox/issues/6338) - Decimal fields are no longer coerced to strings in REST API
+* [#6639](https://github.com/netbox-community/netbox/issues/6639) - Drop support for queryset caching (django-cacheops)
+* [#6713](https://github.com/netbox-community/netbox/issues/6713) - Checking for new releases is now done as part of the housekeeping routine
+
+### Configuration Changes
+
+* The `CACHE_TIMEOUT` configuration parameter has been removed.
+* The `RELEASE_CHECK_TIMEOUT` configuration parameter has been removed.
+
+### REST API Changes
+
+* Added the `/api/users/tokens/` endpoint
+    * The `provision/` child endpoint can be used to provision new REST API tokens by supplying a valid username and password
+* Removed the following "connections" endpoints:
+    * `/api/dcim/console-connections`
+    * `/api/dcim/power-connections`
+    * `/api/dcim/interface-connections`
+* dcim.Cable
+    * `length` is now a decimal value
+* dcim.Device
+    * Removed the `display_name` attribute (use `display` instead)
+* dcim.DeviceType
+    * Removed the `display_name` attribute (use `display` instead)
+* dcim.FrontPort
+    * Added `color` field
+* dcim.FrontPortTemplate
+    * Added `color` field
+* dcim.Rack
+    * Removed the `display_name` attribute (use `display` instead)
+* dcim.RearPort
+    * Added `color` field
+* dcim.RearPortTemplate
+    * Added `color` field
+* dcim.Site
+    * `latitude` and `longitude` are now decimal fields rather than strings
+* extras.ContentType
+    * Removed the `display_name` attribute (use `display` instead)
+* ipam.Prefix
+    * Added the `mark_utilized` boolean field
+* ipam.VLAN
+    * Removed the `display_name` attribute (use `display` instead)
+* ipam.VRF
+    * Removed the `display_name` attribute (use `display` instead)
+* virtualization.VirtualMachine
+    * `vcpus` is now a decimal field rather than a string

docs/rest-api/authentication.md

@@ -11,7 +11,7 @@ An authentication token is attached to a request by setting the `Authorization`
 ```
 $ curl -H "Authorization: Token $TOKEN" \
 -H "Accept: application/json; indent=4" \
-http://netbox/api/dcim/sites/
+https://netbox/api/dcim/sites/
 {
     "count": 10,
     "next": null,
@@ -23,8 +23,46 @@ http://netbox/api/dcim/sites/
 A token is not required for read-only operations which have been exempted from permissions enforcement (using the [`EXEMPT_VIEW_PERMISSIONS`](../configuration/optional-settings.md#exempt_view_permissions) configuration parameter). However, if a token _is_ required but not present in a request, the API will return a 403 (Forbidden) response:
 
 ```
-$ curl http://netbox/api/dcim/sites/
+$ curl https://netbox/api/dcim/sites/
 {
     "detail": "Authentication credentials were not provided."
 }
 ```
+
+## Initial Token Provisioning
+
+Ideally, each user should provision his or her own REST API token(s) via the web UI. However, you may encounter where a token must be created by a user via the REST API itself. NetBox provides a special endpoint to provision tokens using a valid username and password combination.
+
+To provision a token via the REST API, make a `POST` request to the `/api/users/tokens/provision/` endpoint:
+
+```
+$ curl -X POST \
+-H "Content-Type: application/json" \
+-H "Accept: application/json; indent=4" \
+https://netbox/api/users/tokens/provision/
+{
+    "username": "hankhill",
+    "password: "I<3C3H8",
+}
+```
+
+Note that we are _not_ passing an existing REST API token with this request. If the supplied credentials are valid, a new REST API token will be automatically created for the user. Note that the key will be automatically generated, and write ability will be enabled.
+
+```json
+{
+    "id": 6,
+    "url": "https://netbox/api/users/tokens/6/",
+    "display": "3c9cb9 (hankhill)",
+    "user": {
+        "id": 2,
+        "url": "https://netbox/api/users/users/2/",
+        "display": "hankhill",
+        "username": "hankhill"
+    },
+    "created": "2021-06-11T20:09:13.339367Z",
+    "expires": null,
+    "key": "9fc9b897abec9ada2da6aec9dbc34596293c9cb9",
+    "write_enabled": true,
+    "description": ""
+}
+```

docs/rest-api/filtering.md

@@ -61,25 +61,30 @@ These lookup expressions can be applied by adding a suffix to the desired field'
 
 Numeric based fields (ASN, VLAN ID, etc) support these lookup expressions:
 
-- `n` - not equal to (negation)
-- `lt` - less than
-- `lte` - less than or equal
-- `gt` - greater than
-- `gte` - greater than or equal
+| Filter | Description |
+|--------|-------------|
+| `n` | Not equal to |
+| `lt` | Less than |
+| `lte` | Less than or equal to |
+| `gt` | Greater than |
+| `gte` | Greater than or equal to |
 
 ### String Fields
 
 String based (char) fields (Name, Address, etc) support these lookup expressions:
 
-- `n` - not equal to (negation)
-- `ic` - case insensitive contains
-- `nic` - negated case insensitive contains
-- `isw` - case insensitive starts with
-- `nisw` - negated case insensitive starts with
-- `iew` - case insensitive ends with
-- `niew` - negated case insensitive ends with
-- `ie` - case insensitive exact match
-- `nie` - negated case insensitive exact match
+| Filter | Description |
+|--------|-------------|
+| `n` | Not equal to |
+| `ic` | Contains (case-insensitive) |
+| `nic` | Does not contain (case-insensitive) |
+| `isw` | Starts with (case-insensitive) |
+| `nisw` | Does not start with (case-insensitive) |
+| `iew` | Ends with (case-insensitive) |
+| `niew` | Does not end with (case-insensitive) |
+| `ie` | Exact match (case-insensitive) |
+| `nie` | Inverse exact match (case-insensitive) |
+| `empty` | Is empty (boolean) |
 
 ### Foreign Keys & Other Fields
 

docs/rest-api/overview.md

@@ -67,7 +67,7 @@ Comprehensive, interactive documentation of all REST API endpoints is available
 
 ## Endpoint Hierarchy
 
-NetBox's entire REST API is housed under the API root at `https://<hostname>/api/`. The URL structure is divided at the root level by application: circuits, DCIM, extras, IPAM, plugins, secrets, tenancy, users, and virtualization. Within each application exists a separate path for each model. For example, the provider and circuit objects are located under the "circuits" application:
+NetBox's entire REST API is housed under the API root at `https://<hostname>/api/`. The URL structure is divided at the root level by application: circuits, DCIM, extras, IPAM, plugins, tenancy, users, and virtualization. Within each application exists a separate path for each model. For example, the provider and circuit objects are located under the "circuits" application:
 
 * `/api/circuits/providers/`
 * `/api/circuits/circuits/`

docs/rest-api/working-with-secrets.md

@@ -1,172 +0,0 @@
-# Working with Secrets
-
-As with most other objects, the REST API can be used to view, create, modify, and delete secrets. However, additional steps are needed to encrypt or decrypt secret data.
-
-## Generating a Session Key
-
-In order to encrypt or decrypt secret data, a session key must be attached to the API request. To generate a session key, send an authenticated request to the `/api/secrets/get-session-key/` endpoint with the private RSA key which matches your [UserKey](../core-functionality/secrets.md#user-keys). The private key must be POSTed with the name `private_key`.
-
-```no-highlight
-$ curl -X POST http://netbox/api/secrets/get-session-key/ \
--H "Authorization: Token $TOKEN" \
--H "Accept: application/json; indent=4" \
---data-urlencode "private_key@<filename>"
-```
-
-```json
-{
-    "session_key": "dyEnxlc9lnGzaOAV1dV/xqYPV63njIbdZYOgnAlGPHk="
-}
-```
-
-!!! note
-    To read the private key from a file, use the convention above. Alternatively, the private key can be read from an environment variable using `--data-urlencode "private_key=$PRIVATE_KEY"`.
-
-The request uses the provided private key to unlock your stored copy of the master key and generate a temporary session key, which can be attached in the `X-Session-Key` header of future API requests.
-
-## Retrieving Secrets
-
-A session key is not needed to retrieve unencrypted secrets: The secret is returned like any normal object with its `plaintext` field set to null.
-
-```no-highlight
-$ curl http://netbox/api/secrets/secrets/2587/ \
--H "Authorization: Token $TOKEN" \
--H "Accept: application/json; indent=4"
-```
-
-```json
-{
-    "id": 2587,
-    "url": "http://netbox/api/secrets/secrets/2587/",
-    "device": {
-        "id": 1827,
-        "url": "http://netbox/api/dcim/devices/1827/",
-        "name": "MyTestDevice",
-        "display_name": "MyTestDevice"
-    },
-    "role": {
-        "id": 1,
-        "url": "http://netbox/api/secrets/secret-roles/1/",
-        "name": "Login Credentials",
-        "slug": "login-creds"
-    },
-    "name": "admin",
-    "plaintext": null,
-    "hash": "pbkdf2_sha256$1000$G6mMFe4FetZQ$f+0itZbAoUqW5pd8+NH8W5rdp/2QNLIBb+LGdt4OSKA=",
-    "tags": [],
-    "custom_fields": {},
-    "created": "2017-03-21",
-    "last_updated": "2017-03-21T19:28:44.265582Z"
-}
-```
-
-To decrypt a secret, we must include our session key in the `X-Session-Key` header when sending the `GET` request:
-
-```no-highlight
-$ curl http://netbox/api/secrets/secrets/2587/ \
--H "Authorization: Token $TOKEN" \
--H "Accept: application/json; indent=4" \
--H "X-Session-Key: dyEnxlc9lnGzaOAV1dV/xqYPV63njIbdZYOgnAlGPHk="
-```
-
-```json
-{
-    "id": 2587,
-    "url": "http://netbox/api/secrets/secrets/2587/",
-    "device": {
-        "id": 1827,
-        "url": "http://netbox/api/dcim/devices/1827/",
-        "name": "MyTestDevice",
-        "display_name": "MyTestDevice"
-    },
-    "role": {
-        "id": 1,
-        "url": "http://netbox/api/secrets/secret-roles/1/",
-        "name": "Login Credentials",
-        "slug": "login-creds"
-    },
-    "name": "admin",
-    "plaintext": "foobar",
-    "hash": "pbkdf2_sha256$1000$G6mMFe4FetZQ$f+0itZbAoUqW5pd8+NH8W5rdp/2QNLIBb+LGdt4OSKA=",
-    "tags": [],
-    "custom_fields": {},
-    "created": "2017-03-21",
-    "last_updated": "2017-03-21T19:28:44.265582Z"
-}
-```
-
-Multiple secrets within a list can be decrypted in this manner as well:
-
-```no-highlight
-$ curl http://netbox/api/secrets/secrets/?limit=3 \
--H "Authorization: Token $TOKEN" \
--H "Accept: application/json; indent=4" \
--H "X-Session-Key: dyEnxlc9lnGzaOAV1dV/xqYPV63njIbdZYOgnAlGPHk="
-```
-
-```json
-{
-    "count": 3482,
-    "next": "http://netbox/api/secrets/secrets/?limit=3&offset=3",
-    "previous": null,
-    "results": [
-        {
-            "id": 2587,
-            "plaintext": "foobar",
-            ...
-        },
-        {
-            "id": 2588,
-            "plaintext": "MyP@ssw0rd!",
-            ...
-        },
-        {
-            "id": 2589,
-            "plaintext": "AnotherSecret!",
-            ...
-        },
-    ]
-}
-```
-
-## Creating and Updating Secrets
-
-Session keys are required when creating or modifying secrets. The secret's `plaintext` attribute is set to its non-encrypted value, and NetBox uses the session key to compute and store the encrypted value.
-
-```no-highlight
-$ curl -X POST http://netbox/api/secrets/secrets/ \
--H "Content-Type: application/json" \
--H "Authorization: Token $TOKEN" \
--H "Accept: application/json; indent=4" \
--H "X-Session-Key: dyEnxlc9lnGzaOAV1dV/xqYPV63njIbdZYOgnAlGPHk=" \
---data '{"device": 1827, "role": 1, "name": "backup", "plaintext": "Drowssap1"}'
-```
-
-```json
-{
-    "id": 6194,
-    "url": "http://netbox/api/secrets/secrets/9194/",
-    "device": {
-        "id": 1827,
-        "url": "http://netbox/api/dcim/devices/1827/",
-        "name": "device43",
-        "display_name": "device43"
-    },
-    "role": {
-        "id": 1,
-        "url": "http://netbox/api/secrets/secret-roles/1/",
-        "name": "Login Credentials",
-        "slug": "login-creds"
-    },
-    "name": "backup",
-    "plaintext": "Drowssap1",
-    "hash": "pbkdf2_sha256$1000$J9db8sI5vBrd$IK6nFXnFl+K+nR5/KY8RSDxU1skYL8G69T5N3jZxM7c=",
-    "tags": [],
-    "custom_fields": {},
-    "created": "2020-08-05",
-    "last_updated": "2020-08-05T16:51:14.990506Z"
-}
-```
-
-!!! note
-    Don't forget to include the `Content-Type: application/json` header when making a POST or PATCH request.

docs/screenshots/index.md

@@ -0,0 +1,36 @@
+# Screenshots
+
+## Light Mode
+
+### Home Page
+
+![Home Page](../media/home-light.png)
+
+### Rack Elevation
+
+![Rack Elevation](../media/rack-light.png)
+
+### Prefixes
+
+![Prefixes](../media/prefixes-light.png)
+
+### Cable Trace
+![Cable Trace](../media/cable-light.png)
+
+## Dark Mode
+
+### Home Page
+
+![Home Page](../media/home-dark.png)
+
+### Rack Elevation
+
+![Rack Elevation](../media/rack-dark.png)
+
+### Prefixes
+
+![Prefixes](../media/prefixes-dark.png)
+
+### Cable Trace
+![Cable Trace](../media/cable-dark.png)
+