netbox v3.1.7 update

.gitattributes

@@ -1,5 +1,5 @@
 *.sh text eol=lf
-# Treat minified or packed JS/CSS files as binary, as they're not meant to be human-readable
+# Treat compiled JS/CSS files as binary, as they're not meant to be human-readable
-*.min.* binary
+netbox/project-static/dist/*.css binary
-*.map binary
+netbox/project-static/dist/*.js binary
-*.pack.js binary
+netbox/project-static/dist/*.js.map binary

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -13,11 +13,8 @@ body:
   - type: input
     attributes:
       label: NetBox version
-      description: >
+      description: What version of NetBox are you currently running?
-        What version of NetBox are you currently running? (If you don't have access to the most
+      placeholder: v3.1.7
-        recent NetBox release, consider testing on our [demo instance](https://demo.netbox.dev/)
-        before opening a bug report to see if your issue has already been addressed.)
-      placeholder: v2.11.12
     validations:
       required: true
   - type: dropdown
@@ -25,10 +22,9 @@ body:
       label: Python version
       description: What version of Python are you currently running?
       options:
-        - 3.6
+        - "3.7"
-        - 3.7
+        - "3.8"
-        - 3.8
+        - "3.9"
-        - 3.9
     validations:
       required: true
   - type: textarea

.github/ISSUE_TEMPLATE/feature_request.yaml

@@ -14,7 +14,7 @@ body:
     attributes:
       label: NetBox version
       description: What version of NetBox are you currently running?
-      placeholder: v2.11.12
+      placeholder: v3.1.7
     validations:
       required: true
   - type: dropdown
@@ -30,8 +30,10 @@ body:
     attributes:
       label: Proposed functionality
       description: >
-        Describe in detail the new feature or behavior you'd like to propose. Include any specific
+        Describe in detail the new feature or behavior you are proposing. Include any specific changes
-        changes to work flows, data models, or the user interface.
+        to work flows, data models, and/or the user interface. The more detail you provide here, the
+        greater chance your proposal has of being discussed. Feature requests which don't include an
+        actionable implementation plan will be rejected.
     validations:
       required: true
   - type: textarea

.github/workflows/ci.yml

@@ -5,7 +5,8 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        python-version: [3.6, 3.7, 3.8]
+        python-version: [3.7, 3.8, 3.9]
+        node-version: [14.x]
     services:
       redis:
         image: redis
@@ -33,15 +34,33 @@ jobs:
       with:
         python-version: ${{ matrix.python-version }}
 
+    - name: Use Node.js ${{ matrix.node-version }}
+      uses: actions/setup-node@v2
+      with:
+        node-version: ${{ matrix.node-version }}
+
     - name: Install dependencies & set up configuration
       run: |
         python -m pip install --upgrade pip
         pip install -r requirements.txt
         pip install pycodestyle coverage
         ln -s configuration.testing.py netbox/netbox/configuration.py
+        yarn --cwd netbox/project-static
+
+    - name: Build documentation
+      run: mkdocs build
+
+    - name: Collect static files
+      run: python netbox/manage.py collectstatic --no-input
 
     - name: Check PEP8 compliance
-      run: pycodestyle --ignore=W504,E501 netbox/
+      run: pycodestyle --ignore=W504,E501 --exclude=node_modules netbox/
+
+    - name: Check UI ESLint, TypeScript, and Prettier Compliance
+      run: yarn --cwd netbox/project-static validate
+    
+    - name: Validate Static Asset Integrity
+      run: scripts/verify-bundles.sh
 
     - name: Run tests
       run: coverage run --source="netbox/" netbox/manage.py test netbox/

.gitignore

@@ -1,9 +1,14 @@
 *.pyc
 *.swp
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+/netbox/project-static/node_modules
+/netbox/project-static/docs/*
+!/netbox/project-static/docs/.info
 /netbox/netbox/configuration.py
 /netbox/netbox/ldap_config.py
-/netbox/project-static/.cache
+/netbox/local/*
-/netbox/project-static/node_modules
 /netbox/reports/*
 !/netbox/reports/__init__.py
 /netbox/scripts/*
@@ -18,10 +23,6 @@ gunicorn.py
 netbox.log
 netbox.pid
 .DS_Store
-.vscode
-.venv
-.tox
-!docker_old/configuration/gunicorn_config.py
 .idea
 .coverage
 .vscode

CONTRIBUTING.md

@@ -76,14 +76,10 @@ free to add a comment with any additional justification for the feature.
 (However, note that comments with no substance other than a "+1" will be
 deleted. Please use GitHub's reactions feature to indicate your support.)
 
-* Due to a large backlog of feature requests, we are not currently accepting
+* Before filing a new feature request, consider raising your idea in a
-any proposals which substantially extend NetBox's functionality beyond its
+[GitHub discussion](https://github.com/netbox-community/netbox/discussions)
-current feature set. This includes the introduction of any new views or models
+first. Feedback you receive there will help validate and shape the proposed
-which have not already been proposed in an existing feature request.
+feature before filing a formal issue.
-
-* Before filing a new feature request, consider raising your idea on the
-mailing list first. Feedback you receive there will help validate and shape the
-proposed feature before filing a formal issue.
 
 * Good feature requests are very narrowly defined. Be sure to thoroughly
 describe the functionality and data model(s) being proposed. The more effort

Dockerfile

@@ -1,18 +1,21 @@
-FROM alpine:3.13 as builder
+FROM alpine:3.14 as builder
 
 RUN apk add --no-cache \
       bash \
       build-base \
       cargo \
       ca-certificates \
+      cmake \
       cyrus-sasl-dev \
+      git \
       graphviz \
       jpeg-dev \
       libevent-dev \
       libffi-dev \
-      libressl-dev \
       libxslt-dev \
+      make \
       musl-dev \
+      openssh \
       openldap-dev \
       postgresql-dev \
       py3-pip \
@@ -23,6 +26,27 @@ RUN apk add --no-cache \
       setuptools \
       wheel
 
+# Build libcrc32c for google-crc32c python module
+RUN git clone https://github.com/google/crc32c \
+    && cd crc32c \
+    && git submodule update --init --recursive \
+    && mkdir build \
+    && cd build \
+    && cmake \
+        -DCMAKE_BUILD_TYPE=Release \
+        -DCRC32C_BUILD_TESTS=no \
+        -DCRC32C_BUILD_BENCHMARKS=no \
+        -DBUILD_SHARED_LIBS=yes \
+        .. \
+    && make all install
+
+#ARG NETBOX_PATH=.
+#COPY ${NETBOX_PATH}/requirements.txt requirements.extras.txt /
+#RUN mkdir -p /root/.ssh \
+#    && chmod -R 0700 /root/.ssh \
+#    && ssh-keyscan -t rsa github.com > ~/.ssh/known_hosts
+#RUN --mount=type=ssh,id=github /opt/netbox/venv/bin/pip install --prefix=/build -r /requirements.txt -r /requirements.extras.txt --no-warn-script-location\
+#    && rm -rf /root/.cache
 ARG NETBOX_PATH=.
 COPY ${NETBOX_PATH}/requirements.txt requirements.extras.txt /
 RUN /opt/netbox/venv/bin/pip install \
@@ -33,8 +57,7 @@ RUN /opt/netbox/venv/bin/pip install \
 # Main stage
 ###
 
-FROM alpine:3.13 as main
+FROM alpine:3.14 as main
-
 
 RUN apk add --no-cache \
       bash \
@@ -44,24 +67,29 @@ RUN apk add --no-cache \
       libevent \
       libffi \
       libjpeg-turbo \
-      libressl \
       libxslt \
+      openssl \
+      postgresql-client \
       postgresql-libs \
-      python3 \
       py3-pip \
-      ttf-ubuntu-font-family \
+      python3 \
+      tini \
       unit \
       unit-python3
 
 WORKDIR /opt
 
+COPY --from=builder /usr/local/lib/libcrc32c.* /usr/local/lib/
+COPY --from=builder /usr/local/include/crc32c /usr/local/include
+COPY --from=builder /usr/local/lib/cmake/Crc32c /usr/local/lib/cmake/
 COPY --from=builder /opt/netbox/venv /opt/netbox/venv
 
-ARG NETBOX_PATH=.
+ARG NETBOX_PATH
 COPY ${NETBOX_PATH} /opt/netbox
 
 COPY docker/configuration.docker.py /opt/netbox/netbox/netbox/configuration.py
 COPY docker/docker-entrypoint.sh /opt/netbox/docker-entrypoint.sh
+COPY docker/housekeeping.sh /opt/netbox/housekeeping.sh
 COPY docker/launch-netbox.sh /opt/netbox/launch-netbox.sh
 COPY docker/startup_scripts/ /opt/netbox/startup_scripts/
 COPY docker/initializers/ /opt/netbox/initializers/
@@ -73,12 +101,16 @@ WORKDIR /opt/netbox/netbox
 # Must set permissions for '/opt/netbox/netbox/media' directory
 # to g+w so that pictures can be uploaded to netbox.
 RUN mkdir -p static /opt/unit/state/ /opt/unit/tmp/ \
+      && chown -R unit:root media /opt/unit/ \
       && chmod -R g+w media /opt/unit/ \
+      && cd /opt/netbox/ && /opt/netbox/venv/bin/python -m mkdocs build \
+          --config-file /opt/netbox/mkdocs.yml --site-dir /opt/netbox/netbox/project-static/docs/ \
       && SECRET_KEY="dummy" /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py collectstatic --no-input
 
-ENTRYPOINT [ "/opt/netbox/docker-entrypoint.sh" ]
+ENTRYPOINT [ "/sbin/tini", "--" ]
+
+CMD [ "/opt/netbox/docker-entrypoint.sh", "/opt/netbox/launch-netbox.sh" ]
 
-CMD [ "/opt/netbox/launch-netbox.sh" ]
 
 LABEL maintainer="Vapor IO" \
 # See http://label-schema.org/rc1/#build-time-labels

README.md

@@ -5,11 +5,46 @@
 ![Master branch build status](https://github.com/netbox-community/netbox/workflows/CI/badge.svg?branch=master)
 
 NetBox is an infrastructure resource modeling (IRM) tool designed to empower
-network automation. Initially conceived by the network engineering team at
+network automation, used by thousands of organizations around the world.
+Initially conceived by the network engineering team at
 [DigitalOcean](https://www.digitalocean.com/), NetBox was developed specifically
 to address the needs of network and infrastructure engineers. It is intended to
 function as a domain-specific source of truth for network operations.
 
+Myriad infrastructure components can be modeled in NetBox, including:
+
+* Hierarchical regions, site groups, sites, and locations
+* Racks, devices, and device components
+* Cables and wireless connections
+* Power distribution
+* Data circuits and providers
+* Virtual machines and clusters
+* IP prefixes, ranges, and addresses
+* VRFs and route targets
+* FHRP groups (VRRP, HSRP, etc.)
+* AS numbers
+* VLANs and scoped VLAN groups
+* Organizational tenants and contacts
+
+In addition to its extensive built-in models and functionality, NetBox can be
+customized and extended through the use of:
+
+* Custom fields
+* Custom links
+* Configuration contexts
+* Custom model validation rules
+* Reports
+* Custom scripts
+* Export templates
+* Conditional webhooks
+* Plugins
+* Single sign-on (SSO) authentication
+* NAPALM integration
+* Detailed change logging
+
+NetBox also features a complete REST API as well as a GraphQL API for easily
+integrating with other tools and systems.
+
 NetBox runs as a web application atop the [Django](https://www.djangoproject.com/)
 Python framework with a [PostgreSQL](https://www.postgresql.org/) database. For a
 complete list of requirements, see `requirements.txt`. The code is available [on GitHub](https://github.com/netbox-community/netbox).
@@ -54,11 +89,15 @@ our [contributing guide](CONTRIBUTING.md) prior to beginning any work.
 
 ### Screenshots
 
-![Screenshot of main page](docs/media/screenshot1.png "Main page")
+![Screenshot of main page (light mode)](docs/media/screenshots/home-light.png "Main page (light mode)")
 
-![Screenshot of rack elevation](docs/media/screenshot2.png "Rack elevation")
+![Screenshot of main page (dark mode)](docs/media/screenshots/home-dark.png "Main page (dark mode)")
 
-![Screenshot of prefix hierarchy](docs/media/screenshot3.png "Prefix hierarchy")
+![Screenshot of rack elevation](docs/media/screenshots/rack.png "Rack elevation")
+
+![Screenshot of prefixes hierarchy](docs/media/screenshots/prefixes-list.png "Prefixes hierarchy")
+
+![Screenshot of cable trace](docs/media/screenshots/cable-trace.png "Cable tracing")
 
 ### Related projects
 

base_requirements.txt

@@ -1,10 +1,6 @@
 # The Python web framework on which NetBox is built
 # https://github.com/django/django
-Django
+Django<4.0
-
-# Django caching using Redis
-# https://github.com/Suor/django-cacheops
-django-cacheops
 
 # Django middleware which permits cross-domain API requests
 # https://github.com/OttoYiu/django-cors-headers
@@ -18,6 +14,10 @@ django-debug-toolbar
 # https://github.com/carltongibson/django-filter
 django-filter
 
+# Django debug toolbar extension with support for GraphiQL
+# https://github.com/flavors/django-graphiql-debug-toolbar/
+django-graphiql-debug-toolbar
+
 # Modified Preorder Tree Traversal (recursive nesting of objects)
 # https://github.com/django-mptt/django-mptt
 django-mptt
@@ -30,6 +30,10 @@ django-pglocks
 # https://github.com/korfuri/django-prometheus
 django-prometheus
 
+# Django chaching backend using Redis
+# https://github.com/jazzband/django-redis
+django-redis
+
 # Django integration for RQ (Reqis queuing)
 # https://github.com/rq/django-rq
 django-rq
@@ -54,6 +58,10 @@ djangorestframework
 # https://github.com/axnsan12/drf-yasg
 drf-yasg[validation]
 
+# Django wrapper for Graphene (GraphQL support)
+# https://github.com/graphql-python/graphene-django
+graphene_django
+
 # WSGI HTTP server
 # https://gunicorn.org/
 gunicorn
@@ -66,6 +74,14 @@ Jinja2
 # https://github.com/Python-Markdown/markdown
 Markdown
 
+# File inclusion plugin for Python-Markdown
+# https://github.com/cmacmackin/markdown-include
+markdown-include
+
+# MkDocs Material theme (for documentation build)
+# https://github.com/squidfunk/mkdocs-material
+mkdocs-material
+
 # Library for manipulating IP prefixes and addresses
 # https://github.com/drkjam/netaddr
 netaddr
@@ -78,17 +94,17 @@ Pillow
 # https://github.com/psycopg/psycopg2
 psycopg2-binary
 
-# Extensive cryptographic library (fork of pycrypto)
-# https://github.com/Legrandin/pycryptodome
-pycryptodome
-
 # YAML rendering library
 # https://github.com/yaml/pyyaml
 PyYAML
 
-# In-memory key/value store used for caching and queuing
+# Social authentication framework
-# https://github.com/andymccurdy/redis-py
+# https://github.com/python-social-auth/social-core
-redis
+social-auth-core
+
+# Django app for social-auth-core
+# https://github.com/python-social-auth/social-app-django
+social-auth-app-django
 
 # SVG image rendering (used for rack elevations)
 # https://github.com/mozman/svgwrite

contrib/netbox-housekeeping.sh

@@ -0,0 +1,9 @@
+#!/bin/sh
+# This shell script invokes NetBox's housekeeping management command, which
+# intended to be run nightly. This script can be copied into your system's
+# daily cron directory (e.g. /etc/cron.daily), or referenced directly from
+# within the cron configuration file.
+#
+# If NetBox has been installed into a nonstandard location, update the paths
+# below.
+/opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py housekeeping

contrib/netbox-rq.service

@@ -11,7 +11,7 @@ User=netbox
 Group=netbox
 WorkingDirectory=/opt/netbox
 
-ExecStart=/opt/netbox/venv/bin/python3 /opt/netbox/netbox/manage.py rqworker
+ExecStart=/opt/netbox/venv/bin/python3 /opt/netbox/netbox/manage.py rqworker high default low
 
 Restart=on-failure
 RestartSec=30

docker-compose.yml

@@ -8,7 +8,7 @@ services:
     - redis-cache
     - netbox-worker
     env_file: docker/env/netbox.env
-    user: '101'
+    user: 'unit:root'
     volumes:
     - ./docker/startup_scripts:/opt/netbox/startup_scripts:z,ro
     - ./docker/initializers:/opt/netbox/initializers:z,ro
@@ -30,7 +30,7 @@ services:
     ports: [ ]
 
   postgres:
-    image: postgres:12-alpine
+    image: postgres:14-alpine
     env_file: docker/env/postgres.env
     ports:
     - "5432:5432"

docker/configuration.docker.py

@@ -45,6 +45,9 @@ def read_configurations(config_module, config_dir, main_config):
             if not f.name.endswith(".py"):
                 continue
 
+            if f.name == f"{main_config}.py":
+                continue
+
             if f.name == f"{config_dir}.py":
                 continue
 
@@ -79,3 +82,10 @@ def __getattr__(name):
         except:
             pass
     raise AttributeError
+
+
+def __dir__():
+    names = []
+    for config in _loaded_configurations:
+        names.extend(config.__dir__())
+    return names

docker/configuration/configuration.py

@@ -106,9 +106,6 @@ BANNER_LOGIN = environ.get('BANNER_LOGIN', '')
 # BASE_PATH = 'netbox/'
 BASE_PATH = environ.get('BASE_PATH', '')
 
-# Cache timeout in seconds. Set to 0 to dissable caching. Defaults to 900 (15 minutes)
-CACHE_TIMEOUT = int(environ.get('CACHE_TIMEOUT', 900))
-
 # Maximum number of days to retain logged changes. Set to 0 to retain changes indefinitely. (Default: 90)
 CHANGELOG_RETENTION = int(environ.get('CHANGELOG_RETENTION', 90))
 
@@ -213,9 +210,6 @@ REMOTE_AUTH_HEADER = environ.get('REMOTE_AUTH_HEADER', 'HTTP_REMOTE_USER')
 REMOTE_AUTH_AUTO_CREATE_USER = environ.get('REMOTE_AUTH_AUTO_CREATE_USER', 'True').lower() == 'true'
 REMOTE_AUTH_DEFAULT_GROUPS = list(filter(None, environ.get('REMOTE_AUTH_DEFAULT_GROUPS', '').split(' ')))
 
-# This determines how often the GitHub API is called to check the latest release of NetBox. Must be at least 1 hour.
-RELEASE_CHECK_TIMEOUT = int(environ.get('RELEASE_CHECK_TIMEOUT', 24 * 3600))
-
 # This repository is used to check whether there is a new release of NetBox available. Set to None to disable the
 # version check or use the URL below to check for release in the official NetBox repository.
 # https://api.github.com/repos/netbox-community/netbox/releases

docker/env/netbox.env

@@ -2,7 +2,7 @@ CORS_ORIGIN_ALLOW_ALL=True
 DB_HOST=postgres
 DB_NAME=netbox
 DB_PASSWORD=12345
-DB_USER=postgres
+DB_USER=netbox
 EMAIL_FROM=netbox@bar.com
 EMAIL_PASSWORD=
 EMAIL_PORT=25

docker/env/postgres.env

@@ -1,3 +1,3 @@
 POSTGRES_DB=netbox
 POSTGRES_PASSWORD=12345
-POSTGRES_USER=postgres
+POSTGRES_USER=netbox

docker/housekeeping.sh

@@ -0,0 +1,8 @@
+#!/bin/bash
+SECONDS=${HOUSEKEEPING_INTERVAL:=86400}
+echo "Interval set to ${SECONDS} seconds"
+while true; do
+  date
+  /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py housekeeping
+  sleep "${SECONDS}s"
+done

docs/additional-features/caching.md

@@ -1,28 +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. Within that time, all recurrences of that specific query will return the pre-fetched results from the cache.
-
-!!! warning
-    In NetBox v2.11.10 and later queryset caching is disabled by default, and must be configured.
-
-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/napalm.md

@@ -1,6 +1,6 @@
 # NAPALM
 
-NetBox supports integration with the [NAPALM automation](https://napalm-automation.net/) library. NAPALM allows NetBox to serve a proxy for operational data, fetching live data from network devices and returning it to a requester via its REST API. Note that NetBox does not store any NAPALM data locally.
+NetBox supports integration with the [NAPALM automation](https://github.com/napalm-automation/napalm) library. NAPALM allows NetBox to serve a proxy for operational data, fetching live data from network devices and returning it to a requester via its REST API. Note that NetBox does not store any NAPALM data locally.
 
 The NetBox UI will display tabs for status, LLDP neighbors, and configuration under the device view if the following conditions are met:
 
@@ -29,7 +29,7 @@ GET /api/dcim/devices/1/napalm/?method=get_environment
 
 ## Authentication
 
-By default, the [`NAPALM_USERNAME`](../configuration/optional-settings.md#napalm_username) and [`NAPALM_PASSWORD`](../configuration/optional-settings.md#napalm_password) configuration parameters are used for NAPALM authentication. They can be overridden for an individual API call by specifying the `X-NAPALM-Username` and `X-NAPALM-Password` headers.
+By default, the [`NAPALM_USERNAME`](../configuration/dynamic-settings.md#napalm_username) and [`NAPALM_PASSWORD`](../configuration/dynamic-settings.md#napalm_password) configuration parameters are used for NAPALM authentication. They can be overridden for an individual API call by specifying the `X-NAPALM-Username` and `X-NAPALM-Password` headers.
 
 ```
 $ curl "http://localhost/api/dcim/devices/1/napalm/?method=get_environment" \

docs/additional-features/prometheus-metrics.md

@@ -26,4 +26,4 @@ For the exhaustive list of exposed metrics, visit the `/metrics` endpoint on you
 When deploying NetBox in a multiprocess manner (e.g. running multiple Gunicorn workers) the Prometheus client library requires the use of a shared directory to collect metrics from all worker processes. To configure this, first create or designate a local directory to which the worker processes have read and write access, and then configure your WSGI service (e.g. Gunicorn) to define this path as the `prometheus_multiproc_dir` environment variable.
 
 !!! warning
-    If having accurate long-term metrics in a multiprocess environment is crucial to your deployment, it's recommended you use the `uwsgi` library instead of `gunicorn`. The issue lies in the way `gunicorn` tracks worker processes (vs `uwsgi`) which helps manage the metrics files created by the above configurations. If you're using NetBox with gunicorn in a containerized enviroment following the one-process-per-container methodology, then you will likely not need to change to `uwsgi`. More details can be found in  [issue #3779](https://github.com/netbox-community/netbox/issues/3779#issuecomment-590547562).
+    If having accurate long-term metrics in a multiprocess environment is crucial to your deployment, it's recommended you use the `uwsgi` library instead of `gunicorn`. The issue lies in the way `gunicorn` tracks worker processes (vs `uwsgi`) which helps manage the metrics files created by the above configurations. If you're using NetBox with gunicorn in a containerized environment following the one-process-per-container methodology, then you will likely not need to change to `uwsgi`. More details can be found in  [issue #3779](https://github.com/netbox-community/netbox/issues/3779#issuecomment-590547562).

docs/additional-features/webhooks.md

@@ -1,86 +1,22 @@
-# Webhooks
+{!models/extras/webhook.md!}
 
-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.
+## Conditional Webhooks
 
-!!! warning
+A webhook may include a set of conditional logic expressed in JSON used to control whether a webhook triggers for a specific object. For example, you may wish to trigger a webhook for devices only when the `status` field of an object is "active":
-    Webhooks support the inclusion of user-submitted code to generate custom headers and payloads, which may pose security risks under certain conditions. Only grant permission to create or modify webhooks to trusted users.
 
-## Configuration
+```json
-
-* **Name** - A unique name for the webhook. The name is not included with outbound messages.
-* **Object type(s)** - The type or types of NetBox object that will trigger the webhook.
-* **Enabled** - If unchecked, the webhook will be inactive.
-* **Events** - A webhook may trigger on any combination of create, update, and delete events. At least one event type must be selected.
-* **HTTP method** - The type of HTTP request to send. Options include `GET`, `POST`, `PUT`, `PATCH`, and `DELETE`.
-* **URL** - The fuly-qualified URL of the request to be sent. This may specify a destination port number if needed.
-* **HTTP content type** - The value of the request's `Content-Type` header. (Defaults to `application/json`)
-* **Additional headers** - Any additional headers to include with the request (optional). Add one header per line in the format `Name: Value`. Jinja2 templating is supported for this field (see below).
-* **Body template** - The content of the request being sent (optional). Jinja2 templating is supported for this field (see below). If blank, NetBox will populate the request body with a raw dump of the webhook context. (If the HTTP cotent type is set to `application/json`, this will be formatted as a JSON object.)
-* **Secret** - A secret string used to prove authenticity of the request (optional). This will append a `X-Hook-Signature` header to the request, consisting of a HMAC (SHA-512) hex digest of the request body using the secret as the key.
-* **SSL verification** - Uncheck this option to disable validation of the receiver's SSL certificate. (Disable with caution!)
-* **CA file path** - The file path to a particular certificate authority (CA) file to use when validating the receiver's SSL certificate (optional).
-
-## Jinja2 Template Support
-
-[Jinja2 templating](https://jinja.palletsprojects.com/) is supported for the `additional_headers` and `body_template` fields. This enables the user to convey object data in the request headers as well as to craft a customized request body. Request content can be crafted to enable the direct interaction with external systems by ensuring the outgoing message is in a format the receiver expects and understands.
-
-For example, you might create a NetBox webhook to [trigger a Slack message](https://api.slack.com/messaging/webhooks) any time an IP address is created. You can accomplish this using the following configuration:
-
-* Object type: IPAM > IP address
-* HTTP method: `POST`
-* URL: Slack incoming webhook URL
-* HTTP content type: `application/json`
-* Body template: `{"text": "IP address {{ data['address'] }} was created by {{ username }}!"}`
-
-### Available Context
-
-The following data is available as context for Jinja2 templates:
-
-* `event` - The type of event which triggered the webhook: created, updated, or deleted.
-* `model` - The NetBox model which triggered the change.
-* `timestamp` - The time at which the event occurred (in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) format).
-* `username` - The name of the user account associated with the change.
-* `request_id` - The unique request ID. This may be used to correlate multiple changes associated with a single request.
-* `data` - A detailed representation of the object in its current state. This is typically equivalent to the model's representation in NetBox's REST API.
-* `snapshots` - Minimal "snapshots" of the object state both before and after the change was made; provided ass a dictionary with keys named `prechange` and `postchange`. These are not as extensive as the fully serialized representation, but contain enough information to convey what has changed.
-
-### Default Request Body
-
-If no body template is specified, the request body will be populated with a JSON object containing the context data. For example, a newly created site might appear as follows:
-
-```no-highlight
 {
-    "event": "created",
+  "and": [
-    "timestamp": "2021-03-09 17:55:33.968016+00:00",
+    {
-    "model": "site",
+      "attr": "status.value",
-    "username": "jstretch",
+      "value": "active"
-    "request_id": "fdbca812-3142-4783-b364-2e2bd5c16c6a",
-    "data": {
-        "id": 19,
-        "name": "Site 1",
-        "slug": "site-1",
-        "status": 
-            "value": "active",
-            "label": "Active",
-            "id": 1
-        },
-        "region": null,
-        ...
-    },
-    "snapshots": {
-        "prechange": null,
-        "postchange": {
-            "created": "2021-03-09",
-            "last_updated": "2021-03-09T17:55:33.851Z",
-            "name": "Site 1",
-            "slug": "site-1",
-            "status": "active",
-            ...
-        }
     }
+  ]
 }
 ```
 
+For more detail, see the reference documentation for NetBox's [conditional logic](../reference/conditions.md).
+
 ## Webhook Processing
 
 When a change is detected, any resulting webhooks are placed into a Redis queue for processing. This allows the user's request to complete without needing to wait for the outgoing webhook(s) to be processed. The webhooks are then extracted from the queue by the `rqworker` process and HTTP requests are sent to their respective destinations. The current webhook queue and any failed webhooks can be inspected in the admin UI under System > Background Tasks.

docs/administration/authentication.md

@@ -0,0 +1,37 @@
+# Authentication
+
+## Local Authentication
+
+Local user accounts and groups can be created in NetBox under the "Authentication and Authorization" section of the administrative user interface. This interface is available only to users with the "staff" permission enabled.
+
+At a minimum, each user account must have a username and password set. User accounts may also denote a first name, last name, and email address. [Permissions](./permissions.md) may also be assigned to users and/or groups within the admin UI.
+
+## Remote Authentication
+
+NetBox may be configured to provide user authenticate via a remote backend in addition to local authentication. This is done by setting the `REMOTE_AUTH_BACKEND` configuration parameter to a suitable backend class. NetBox provides several options for remote authentication.
+
+### LDAP Authentication
+
+```python
+REMOTE_AUTH_BACKEND = 'netbox.authentication.LDAPBackend'
+```
+
+NetBox includes an authentication backend which supports LDAP. See the [LDAP installation docs](../installation/6-ldap.md) for more detail about this backend.
+
+### HTTP Header Authentication
+
+```python
+REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
+```
+
+Another option for remote authentication in NetBox is to enable HTTP header-based user assignment. The front end HTTP server (e.g. nginx or Apache) performs client authentication as a process external to NetBox, and passes information about the authenticated user via HTTP headers. By default, the user is assigned via the `REMOTE_USER` header, but this can be customized via the `REMOTE_AUTH_HEADER` configuration parameter.
+
+### Single Sign-On (SSO)
+
+```python
+REMOTE_AUTH_BACKEND = 'social_core.backends.google.GoogleOAuth2'
+```
+
+NetBox supports single sign-on authentication via the [python-social-auth](https://github.com/python-social-auth) library. To enable SSO, specify the path to the desired authentication backend within the `social_core` Python package. Please see the complete list of [supported authentication backends](https://github.com/python-social-auth/social-core/tree/master/social_core/backends) for the available options.
+
+Most remote authentication backends require some additional configuration through settings prefixed with `SOCIAL_AUTH_`. These will be automatically imported from NetBox's `configuration.py` file. Additionally, the [authentication pipeline](https://python-social-auth.readthedocs.io/en/latest/pipeline.html) can be customized via the `SOCIAL_AUTH_PIPELINE` parameter.

docs/administration/housekeeping.md

@@ -0,0 +1,17 @@
+# 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/dynamic-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 linked from your cron scheduler's daily jobs directory (e.g. `/etc/cron.daily`) or referenced directly within the cron configuration file.
+
+```shell
+sudo ln -s /opt/netbox/contrib/netbox-housekeeping.sh /etc/cron.daily/netbox-housekeeping
+```
+
+!!! note
+    On Debian-based systems, be sure to omit the `.sh` file extension when linking to the script from within a cron directory. Otherwise, the task may not run.
+
+The `housekeeping` command can also be run manually at any time: Running the command outside scheduled execution times will not interfere with its operation.

docs/administration/netbox-shell.md

@@ -11,7 +11,7 @@ This will launch a lightly customized version of [the built-in Django shell](htt
 ```
 $ ./manage.py nbshell
 ### NetBox interactive shell (localhost)
-### Python 3.6.9 | Django 2.2.11 | NetBox 2.7.10
+### Python 3.7.10 | Django 3.2.5 | NetBox 3.0
 ### lsmodels() will show available models. Use help(<model>) for more info.
 ```
 
@@ -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/administration/permissions.md

@@ -1,8 +1,8 @@
 # Permissions
 
-NetBox v2.9 introduced a new object-based permissions framework, which replace's Django's built-in permissions model. Object-based permissions enable an administrator to grant users or groups the ability to perform an action on arbitrary subsets of objects in NetBox, rather than all objects of a certain type. For example, it is possible to grant a user permission to view only sites within a particular region, or to modify only VLANs with a numeric ID within a certain range.
+NetBox v2.9 introduced a new object-based permissions framework, which replaces Django's built-in permissions model. Object-based permissions enable an administrator to grant users or groups the ability to perform an action on arbitrary subsets of objects in NetBox, rather than all objects of a certain type. For example, it is possible to grant a user permission to view only sites within a particular region, or to modify only VLANs with a numeric ID within a certain range.
 
-{!docs/models/users/objectpermission.md!}
+{!models/users/objectpermission.md!}
 
 ### Example Constraint Definitions
 

docs/administration/replicating-netbox.md

@@ -71,14 +71,3 @@ To extract the saved archive into a new installation, run the following from the
 ```no-highlight
 tar -xf netbox_media.tar.gz
 ```
-
----
-
-## Cache Invalidation
-
-If you are migrating your instance of NetBox to a different machine, be sure to first invalidate the cache on the original instance by issuing the `invalidate all` management command (within the Python virtual environment):
-
-```no-highlight
-# source /opt/netbox/venv/bin/activate
-(venv) # python3 manage.py invalidate all
-```

docs/configuration/dynamic-settings.md

@@ -0,0 +1,180 @@
+# Dynamic Configuration Settings
+
+These configuration parameters are primarily controlled via NetBox's admin interface (under Admin > Extras > Configuration Revisions). These setting may also be overridden in `configuration.py`; this will prevent them from being modified via the UI.
+
+---
+
+## ALLOWED_URL_SCHEMES
+
+Default: `('file', 'ftp', 'ftps', 'http', 'https', 'irc', 'mailto', 'sftp', 'ssh', 'tel', 'telnet', 'tftp', 'vnc', 'xmpp')`
+
+A list of permitted URL schemes referenced when rendering links within NetBox. Note that only the schemes specified in this list will be accepted: If adding your own, be sure to replicate all of the default values as well (excluding those schemes which are not desirable).
+
+---
+
+## BANNER_TOP
+
+## BANNER_BOTTOM
+
+Setting these variables will display custom content in a banner at the top and/or bottom of the page, respectively. HTML is allowed. To replicate the content of the top banner in the bottom banner, set:
+
+```python
+BANNER_TOP = 'Your banner text'
+BANNER_BOTTOM = BANNER_TOP
+```
+
+---
+
+## BANNER_LOGIN
+
+This defines custom content to be displayed on the login page above the login form. HTML is allowed.
+
+---
+
+## CHANGELOG_RETENTION
+
+Default: 90
+
+The number of days to retain logged changes (object creations, updates, and deletions). Set this to `0` to retain
+changes in the database indefinitely.
+
+!!! warning
+    If enabling indefinite changelog retention, it is recommended to periodically delete old entries. Otherwise, the database may eventually exceed capacity.
+
+---
+
+## 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. An example is provided below:
+
+```python
+CUSTOM_VALIDATORS = {
+    "dcim.site": [
+        {
+            "name": {
+                "min_length": 5,
+                "max_length": 30
+            }
+        },
+        "my_plugin.validators.Validator1"
+    ],
+    "dim.device": [
+        "my_plugin.validators.Validator1"
+    ]
+}
+```
+
+---
+
+## ENFORCE_GLOBAL_UNIQUE
+
+Default: False
+
+By default, NetBox will permit users to create duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF). This behavior can be disabled by setting `ENFORCE_GLOBAL_UNIQUE` to True.
+
+---
+
+## GRAPHQL_ENABLED
+
+Default: True
+
+Setting this to False will disable the GraphQL API.
+
+---
+
+## MAINTENANCE_MODE
+
+Default: False
+
+Setting this to True will display a "maintenance mode" banner at the top of every page. Additionally, NetBox will no longer update a user's "last active" time upon login. This is to allow new logins when the database is in a read-only state. Recording of login times will resume when maintenance mode is disabled.
+
+---
+
+## MAPS_URL
+
+Default: `https://maps.google.com/?q=` (Google Maps)
+
+This specifies the URL to use when presenting a map of a physical location by street address or GPS coordinates. The URL must accept either a free-form street address or a comma-separated pair of numeric coordinates appended to it.
+
+---
+
+## MAX_PAGE_SIZE
+
+Default: 1000
+
+A web user or API consumer can request an arbitrary number of objects by appending the "limit" parameter to the URL (e.g. `?limit=1000`). This parameter defines the maximum acceptable limit. Setting this to `0` or `None` will allow a client to retrieve _all_ matching objects at once with no limit by specifying `?limit=0`.
+
+---
+
+## NAPALM_USERNAME
+
+## NAPALM_PASSWORD
+
+NetBox will use these credentials when authenticating to remote devices via the supported [NAPALM integration](../additional-features/napalm.md), if installed. Both parameters are optional.
+
+!!! note
+    If SSH public key authentication has been set up on the remote device(s) for the system account under which NetBox runs, these parameters are not needed.
+
+---
+
+## NAPALM_ARGS
+
+A dictionary of optional arguments to pass to NAPALM when instantiating a network driver. See the NAPALM documentation for a [complete list of optional arguments](https://napalm.readthedocs.io/en/latest/support/#optional-arguments). An example:
+
+```python
+NAPALM_ARGS = {
+    'api_key': '472071a93b60a1bd1fafb401d9f8ef41',
+    'port': 2222,
+}
+```
+
+Some platforms (e.g. Cisco IOS) require an argument named `secret` to be passed in addition to the normal password. If desired, you can use the configured `NAPALM_PASSWORD` as the value for this argument:
+
+```python
+NAPALM_USERNAME = 'username'
+NAPALM_PASSWORD = 'MySecretPassword'
+NAPALM_ARGS = {
+    'secret': NAPALM_PASSWORD,
+    # Include any additional args here
+}
+```
+
+---
+
+## NAPALM_TIMEOUT
+
+Default: 30 seconds
+
+The amount of time (in seconds) to wait for NAPALM to connect to a device.
+
+---
+
+## PAGINATE_COUNT
+
+Default: 50
+
+The default maximum number of objects to display per page within each list of objects.
+
+---
+
+## PREFER_IPV4
+
+Default: False
+
+When determining the primary IP address for a device, IPv6 is preferred over IPv4 by default. Set this to True to prefer IPv4 instead.
+
+---
+
+## RACK_ELEVATION_DEFAULT_UNIT_HEIGHT
+
+Default: 22
+
+Default height (in pixels) of a unit within a rack elevation. For best results, this should be approximately one tenth of `RACK_ELEVATION_DEFAULT_UNIT_WIDTH`.
+
+---
+
+## RACK_ELEVATION_DEFAULT_UNIT_WIDTH
+
+Default: 220
+
+Default width (in pixels) of a unit within a rack elevation.

docs/configuration/index.md

@@ -1,18 +1,22 @@
 # NetBox Configuration
 
-NetBox's local configuration is stored in `$INSTALL_ROOT/netbox/netbox/configuration.py`. An example configuration is provided as `configuration.example.py`. You may copy or rename the example configuration and make changes as appropriate. NetBox will not run without a configuration file.
+NetBox's local configuration is stored in `$INSTALL_ROOT/netbox/netbox/configuration.py`. An example configuration is provided as `configuration.example.py`. You may copy or rename the example configuration and make changes as appropriate. NetBox will not run without a configuration file.  While NetBox has many configuration settings, only a few of them must be defined at the time of installation: these are defined under "required settings" below.
 
-While NetBox has many configuration settings, only a few of them must be defined at the time of installation.
+Some configuration parameters may alternatively be defined either in `configuration.py` or within the administrative section of the user interface. Settings which are "hard-coded" in the configuration file take precedence over those defined via the UI.
 
 ## Configuration Parameters
 
 * [Required settings](required-settings.md)
 * [Optional settings](optional-settings.md)
+* [Dynamic settings](dynamic-settings.md)
+* [Remote authentication settings](remote-authentication.md)
 
 ## Changing the Configuration
 
-Configuration settings may be changed at any time. However, the WSGI service (e.g. Gunicorn) must be restarted before the changes will take effect:
+The configuration file may be modified at any time. However, the WSGI service (e.g. Gunicorn) must be restarted before the changes will take effect:
 
 ```no-highlight
 $ sudo systemctl restart netbox
 ```
+
+Configuration parameters which are set via the admin UI (those listed under "dynamic settings") take effect immediately.

docs/configuration/optional-settings.md

@@ -13,33 +13,6 @@ ADMINS = [
 
 ---
 
-## ALLOWED_URL_SCHEMES
-
-Default: `('file', 'ftp', 'ftps', 'http', 'https', 'irc', 'mailto', 'sftp', 'ssh', 'tel', 'telnet', 'tftp', 'vnc', 'xmpp')`
-
-A list of permitted URL schemes referenced when rendering links within NetBox. Note that only the schemes specified in this list will be accepted: If adding your own, be sure to replicate all of the default values as well (excluding those schemes which are not desirable).
-
----
-
-## BANNER_TOP
-
-## BANNER_BOTTOM
-
-Setting these variables will display custom content in a banner at the top and/or bottom of the page, respectively. HTML is allowed. To replicate the content of the top banner in the bottom banner, set:
-
-```python
-BANNER_TOP = 'Your banner text'
-BANNER_BOTTOM = BANNER_TOP
-```
-
----
-
-## BANNER_LOGIN
-
-This defines custom content to be displayed on the login page above the login form. HTML is allowed.
-
----
-
 ## BASE_PATH
 
 Default: None
@@ -52,26 +25,6 @@ BASE_PATH = 'netbox/'
 
 ---
 
-## CACHE_TIMEOUT
-
-Default: 0 (disabled)
-
-The number of seconds that cached database queries will be retained before expiring.
-
----
-
-## CHANGELOG_RETENTION
-
-Default: 90
-
-The number of days to retain logged changes (object creations, updates, and deletions). Set this to `0` to retain
-changes in the database indefinitely.
-
-!!! warning
-    If enabling indefinite changelog retention, it is recommended to periodically delete old entries. Otherwise, the database may eventually exceed capacity.
-
----
-
 ## CORS_ORIGIN_ALLOW_ALL
 
 Default: False
@@ -144,7 +97,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
@@ -160,14 +113,6 @@ Email is sent from NetBox only for critical events or if configured for [logging
 
 ---
 
-## ENFORCE_GLOBAL_UNIQUE
-
-Default: False
-
-By default, NetBox will permit users to create duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF). This behavior can be disabled by setting `ENFORCE_GLOBAL_UNIQUE` to True.
-
----
-
 ## EXEMPT_VIEW_PERMISSIONS
 
 Default: Empty list
@@ -271,7 +216,7 @@ Note that enabling this setting causes NetBox to update a user's session in the
 
 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.
 
 ---
 
@@ -283,30 +228,6 @@ The lifetime (in seconds) of the authentication cookie issued to a NetBox user u
 
 ---
 
-## MAINTENANCE_MODE
-
-Default: False
-
-Setting this to True will display a "maintenance mode" banner at the top of every page. Additionally, NetBox will no longer update a user's "last active" time upon login. This is to allow new logins when the database is in a read-only state. Recording of login times will resume when maintenance mode is disabled.
-
----
-
-## MAPS_URL
-
-Default: `https://maps.google.com/?q=` (Google Maps)
-
-This specifies the URL to use when presenting a map of a physical location by street address or GPS coordinates. The URL must accept either a free-form street address or a comma-separated pair of numeric coordinates appended to it.
-
----
-
-## MAX_PAGE_SIZE
-
-Default: 1000
-
-A web user or API consumer can request an arbitrary number of objects by appending the "limit" parameter to the URL (e.g. `?limit=1000`). This parameter defines the maximum acceptable limit. Setting this to `0` or `None` will allow a client to retrieve _all_ matching objects at once with no limit by specifying `?limit=0`.
-
----
-
 ## MEDIA_ROOT
 
 Default: $INSTALL_ROOT/netbox/media/
@@ -323,57 +244,6 @@ Toggle the availability Prometheus-compatible metrics at `/metrics`. See the [Pr
 
 ---
 
-## NAPALM_USERNAME
-
-## NAPALM_PASSWORD
-
-NetBox will use these credentials when authenticating to remote devices via the [NAPALM library](https://napalm-automation.net/), if installed. Both parameters are optional.
-
-!!! note
-    If SSH public key authentication has been set up on the remote device(s) for the system account under which NetBox runs, these parameters are not needed.
-
----
-
-## NAPALM_ARGS
-
-A dictionary of optional arguments to pass to NAPALM when instantiating a network driver. See the NAPALM documentation for a [complete list of optional arguments](https://napalm.readthedocs.io/en/latest/support/#optional-arguments). An example:
-
-```python
-NAPALM_ARGS = {
-    'api_key': '472071a93b60a1bd1fafb401d9f8ef41',
-    'port': 2222,
-}
-```
-
-Some platforms (e.g. Cisco IOS) require an argument named `secret` to be passed in addition to the normal password. If desired, you can use the configured `NAPALM_PASSWORD` as the value for this argument:
-
-```python
-NAPALM_USERNAME = 'username'
-NAPALM_PASSWORD = 'MySecretPassword'
-NAPALM_ARGS = {
-    'secret': NAPALM_PASSWORD,
-    # Include any additional args here
-}
-```
-
----
-
-## NAPALM_TIMEOUT
-
-Default: 30 seconds
-
-The amount of time (in seconds) to wait for NAPALM to connect to a device.
-
----
-
-## PAGINATE_COUNT
-
-Default: 50
-
-The default maximum number of objects to display per page within each list of objects.
-
----
-
 ## PLUGINS
 
 Default: Empty
@@ -407,94 +277,11 @@ Note that a plugin must be listed in `PLUGINS` for its configuration to take eff
 
 ---
 
-## PREFER_IPV4
-
-Default: False
-
-When determining the primary IP address for a device, IPv6 is preferred over IPv4 by default. Set this to True to prefer IPv4 instead.
-
----
-
-## RACK_ELEVATION_DEFAULT_UNIT_HEIGHT
-
-Default: 22
-
-Default height (in pixels) of a unit within a rack elevation. For best results, this should be approximately one tenth of `RACK_ELEVATION_DEFAULT_UNIT_WIDTH`.
-
----
-
-## RACK_ELEVATION_DEFAULT_UNIT_WIDTH
-
-Default: 220
-
-Default width (in pixels) of a unit within a rack elevation.
-
----
-
-## REMOTE_AUTH_AUTO_CREATE_USER
-
-Default: `False`
-
-If true, NetBox will automatically create local accounts for users authenticated via a remote service. (Requires `REMOTE_AUTH_ENABLED`.)
-
----
-
-## REMOTE_AUTH_BACKEND
-
-Default: `'netbox.authentication.RemoteUserBackend'`
-
-This is the Python path to the custom [Django authentication backend](https://docs.djangoproject.com/en/stable/topics/auth/customizing/) to use for external user authentication. NetBox provides two built-in backends (listed below), though custom authentication backends may also be provided by other packages or plugins.
-
-* `netbox.authentication.RemoteUserBackend`
-* `netbox.authentication.LDAPBackend`
-
----
-
-## REMOTE_AUTH_DEFAULT_GROUPS
-
-Default: `[]` (Empty list)
-
-The list of groups to assign a new user account when created using remote authentication. (Requires `REMOTE_AUTH_ENABLED`.)
-
----
-
-## REMOTE_AUTH_DEFAULT_PERMISSIONS
-
-Default: `{}` (Empty dictionary)
-
-A mapping of permissions to assign a new user account when created using remote authentication. Each key in the dictionary should be set to a dictionary of the attributes to be applied to the permission, or `None` to allow all objects. (Requires `REMOTE_AUTH_ENABLED`.)
-
----
-
-## REMOTE_AUTH_ENABLED
-
-Default: `False`
-
-NetBox can be configured to support remote user authentication by inferring user authentication from an HTTP header set by the HTTP reverse proxy (e.g. nginx or Apache). Set this to `True` to enable this functionality. (Local authentication will still take effect as a fallback.)
-
----
-
-## REMOTE_AUTH_HEADER
-
-Default: `'HTTP_REMOTE_USER'`
-
-When remote user authentication is in use, this is the name of the HTTP header which informs NetBox of the currently authenticated user. For example, to use the request header `X-Remote-User` it needs to be set to `HTTP_X_REMOTE_USER`. (Requires `REMOTE_AUTH_ENABLED`.)
-
----
-
-## 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).
@@ -505,7 +292,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.
 
 ---
 
@@ -521,7 +308,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/configuration/remote-authentication.md

@@ -0,0 +1,110 @@
+# Remote Authentication Settings
+
+The configuration parameters listed here control remote authentication for NetBox. Note that `REMOTE_AUTH_ENABLED` must be true in order for these settings to take effect.
+
+---
+
+## REMOTE_AUTH_AUTO_CREATE_USER
+
+Default: `False`
+
+If true, NetBox will automatically create local accounts for users authenticated via a remote service. (Requires `REMOTE_AUTH_ENABLED`.)
+
+---
+
+## REMOTE_AUTH_BACKEND
+
+Default: `'netbox.authentication.RemoteUserBackend'`
+
+This is the Python path to the custom [Django authentication backend](https://docs.djangoproject.com/en/stable/topics/auth/customizing/) to use for external user authentication. NetBox provides two built-in backends (listed below), though custom authentication backends may also be provided by other packages or plugins.
+
+* `netbox.authentication.RemoteUserBackend`
+* `netbox.authentication.LDAPBackend`
+
+---
+
+## REMOTE_AUTH_DEFAULT_GROUPS
+
+Default: `[]` (Empty list)
+
+The list of groups to assign a new user account when created using remote authentication. (Requires `REMOTE_AUTH_ENABLED`.)
+
+---
+
+## REMOTE_AUTH_DEFAULT_PERMISSIONS
+
+Default: `{}` (Empty dictionary)
+
+A mapping of permissions to assign a new user account when created using remote authentication. Each key in the dictionary should be set to a dictionary of the attributes to be applied to the permission, or `None` to allow all objects. (Requires `REMOTE_AUTH_ENABLED`.)
+
+---
+
+## REMOTE_AUTH_ENABLED
+
+Default: `False`
+
+NetBox can be configured to support remote user authentication by inferring user authentication from an HTTP header set by the HTTP reverse proxy (e.g. nginx or Apache). Set this to `True` to enable this functionality. (Local authentication will still take effect as a fallback.)
+
+---
+
+## REMOTE_AUTH_GROUP_SYNC_ENABLED
+
+Default: `False`
+
+NetBox can be configured to sync remote user groups by inferring user authentication from an HTTP header set by the HTTP reverse proxy (e.g. nginx or Apache). Set this to `True` to enable this functionality. (Local authentication will still take effect as a fallback.) (Requires `REMOTE_AUTH_ENABLED`.)
+
+---
+
+## REMOTE_AUTH_HEADER
+
+Default: `'HTTP_REMOTE_USER'`
+
+When remote user authentication is in use, this is the name of the HTTP header which informs NetBox of the currently authenticated user. For example, to use the request header `X-Remote-User` it needs to be set to `HTTP_X_REMOTE_USER`. (Requires `REMOTE_AUTH_ENABLED`.)
+
+---
+
+## REMOTE_AUTH_GROUP_HEADER
+
+Default: `'HTTP_REMOTE_USER_GROUP'`
+
+When remote user authentication is in use, this is the name of the HTTP header which informs NetBox of the currently authenticated user. For example, to use the request header `X-Remote-User-Groups` it needs to be set to `HTTP_X_REMOTE_USER_GROUPS`. (Requires `REMOTE_AUTH_ENABLED` and `REMOTE_AUTH_GROUP_SYNC_ENABLED` )
+
+---
+
+## REMOTE_AUTH_SUPERUSER_GROUPS
+
+Default: `[]` (Empty list)
+
+The list of groups that promote an remote User to Superuser on Login. If group isn't present on next Login, the Role gets revoked. (Requires `REMOTE_AUTH_ENABLED` and `REMOTE_AUTH_GROUP_SYNC_ENABLED` )
+
+---
+
+## REMOTE_AUTH_SUPERUSERS
+
+Default: `[]` (Empty list)
+
+The list of users that get promoted to Superuser on Login. If user isn't present in list on next Login, the Role gets revoked. (Requires `REMOTE_AUTH_ENABLED` and `REMOTE_AUTH_GROUP_SYNC_ENABLED` )
+
+---
+
+## REMOTE_AUTH_STAFF_GROUPS
+
+Default: `[]` (Empty list)
+
+The list of groups that promote an remote User to Staff on Login. If group isn't present on next Login, the Role gets revoked. (Requires `REMOTE_AUTH_ENABLED` and `REMOTE_AUTH_GROUP_SYNC_ENABLED` )
+
+---
+
+## REMOTE_AUTH_STAFF_USERS
+
+Default: `[]` (Empty list)
+
+The list of users that get promoted to Staff on Login. If user isn't present in list on next Login, the Role gets revoked. (Requires `REMOTE_AUTH_ENABLED` and `REMOTE_AUTH_GROUP_SYNC_ENABLED` )
+
+---
+
+## REMOTE_AUTH_GROUP_SEPARATOR
+
+Default: `|` (Pipe)
+
+The Seperator upon which `REMOTE_AUTH_GROUP_HEADER` gets split into individual Groups. This needs to be coordinated with your authentication Proxy. (Requires `REMOTE_AUTH_ENABLED` and `REMOTE_AUTH_GROUP_SYNC_ENABLED` )

docs/configuration/required-settings.md

@@ -25,7 +25,7 @@ ALLOWED_HOSTS = ['*']
 
 ## DATABASE
 
-NetBox requires access to a PostgreSQL 9.6 or later database service to store data. This service can run locally on the NetBox server or on a remote system. The following parameters must be defined within the `DATABASE` dictionary:
+NetBox requires access to a PostgreSQL 10 or later database service to store data. This service can run locally on the NetBox server or on a remote system. The following parameters must be defined within the `DATABASE` dictionary:
 
 * `NAME` - Database name
 * `USER` - PostgreSQL username

docs/core-functionality/circuits.md

@@ -1,10 +1,10 @@
 # Circuits
 
-{!docs/models/circuits/provider.md!}
+{!models/circuits/provider.md!}
-{!docs/models/circuits/providernetwork.md!}
+{!models/circuits/providernetwork.md!}
 
 ---
 
-{!docs/models/circuits/circuit.md!}
+{!models/circuits/circuit.md!}
-{!docs/models/circuits/circuittype.md!}
+{!models/circuits/circuittype.md!}
-{!docs/models/circuits/circuittermination.md!}
+{!models/circuits/circuittermination.md!}

docs/core-functionality/contacts.md

@@ -0,0 +1,5 @@
+# Contacts
+
+{!models/tenancy/contact.md!}
+{!models/tenancy/contactgroup.md!}
+{!models/tenancy/contactrole.md!}

docs/core-functionality/device-types.md

@@ -1,7 +1,7 @@
 # Device Types
 
-{!docs/models/dcim/devicetype.md!}
+{!models/dcim/devicetype.md!}
-{!docs/models/dcim/manufacturer.md!}
+{!models/dcim/manufacturer.md!}
 
 ---
 
@@ -30,11 +30,11 @@ Once component templates have been created, every new device that you create as
 !!! note
     Assignment of components from templates occurs only at the time of device creation. If you modify the templates of a device type, it will not affect devices which have already been created. However, you always have the option of adding, modifying, or deleting components on existing devices.
 
-{!docs/models/dcim/consoleporttemplate.md!}
+{!models/dcim/consoleporttemplate.md!}
-{!docs/models/dcim/consoleserverporttemplate.md!}
+{!models/dcim/consoleserverporttemplate.md!}
-{!docs/models/dcim/powerporttemplate.md!}
+{!models/dcim/powerporttemplate.md!}
-{!docs/models/dcim/poweroutlettemplate.md!}
+{!models/dcim/poweroutlettemplate.md!}
-{!docs/models/dcim/interfacetemplate.md!}
+{!models/dcim/interfacetemplate.md!}
-{!docs/models/dcim/frontporttemplate.md!}
+{!models/dcim/frontporttemplate.md!}
-{!docs/models/dcim/rearporttemplate.md!}
+{!models/dcim/rearporttemplate.md!}
-{!docs/models/dcim/devicebaytemplate.md!}
+{!models/dcim/devicebaytemplate.md!}

docs/core-functionality/devices.md

@@ -1,8 +1,8 @@
 # Devices and Cabling
 
-{!docs/models/dcim/device.md!}
+{!models/dcim/device.md!}
-{!docs/models/dcim/devicerole.md!}
+{!models/dcim/devicerole.md!}
-{!docs/models/dcim/platform.md!}
+{!models/dcim/platform.md!}
 
 ---
 
@@ -10,20 +10,30 @@
 
 Device components represent discrete objects within a device which are used to terminate cables, house child devices, or track resources.
 
-{!docs/models/dcim/consoleport.md!}
+{!models/dcim/consoleport.md!}
-{!docs/models/dcim/consoleserverport.md!}
+{!models/dcim/consoleserverport.md!}
-{!docs/models/dcim/powerport.md!}
+{!models/dcim/powerport.md!}
-{!docs/models/dcim/poweroutlet.md!}
+{!models/dcim/poweroutlet.md!}
-{!docs/models/dcim/interface.md!}
+{!models/dcim/interface.md!}
-{!docs/models/dcim/frontport.md!}
+{!models/dcim/frontport.md!}
-{!docs/models/dcim/rearport.md!}
+{!models/dcim/rearport.md!}
-{!docs/models/dcim/devicebay.md!}
+{!models/dcim/devicebay.md!}
-{!docs/models/dcim/inventoryitem.md!}
+{!models/dcim/inventoryitem.md!}
 
 ---
 
-{!docs/models/dcim/virtualchassis.md!}
+{!models/dcim/virtualchassis.md!}
 
 ---
 
-{!docs/models/dcim/cable.md!}
+{!models/dcim/cable.md!}
+
+In the example below, three individual cables comprise a path between devices A and D:
+
+![Cable path](../media/models/dcim_cable_trace.png)
+
+Traced from Interface 1 on Device A, NetBox will show the following path:
+
+* Cable 1: Interface 1 to Front Port 1
+* Cable 2: Rear Port 1 to Rear Port 2
+* Cable 3: Front Port 2 to Interface 2

docs/core-functionality/ipam.md

@@ -1,18 +1,27 @@
 # IP Address Management
 
-{!docs/models/ipam/aggregate.md!}
+{!models/ipam/aggregate.md!}
-{!docs/models/ipam/rir.md!}
+{!models/ipam/rir.md!}
 
 ---
 
-{!docs/models/ipam/prefix.md!}
+{!models/ipam/prefix.md!}
-{!docs/models/ipam/role.md!}
+{!models/ipam/role.md!}
 
 ---
 
-{!docs/models/ipam/ipaddress.md!}
+{!models/ipam/iprange.md!}
+{!models/ipam/ipaddress.md!}
 
 ---
 
-{!docs/models/ipam/vrf.md!}
+{!models/ipam/vrf.md!}
-{!docs/models/ipam/routetarget.md!}
+{!models/ipam/routetarget.md!}
+
+---
+
+{!models/ipam/fhrpgroup.md!}
+
+---
+
+{!models/ipam/asn.md!}

docs/core-functionality/power.md

@@ -1,8 +1,8 @@
 # Power Tracking
 
-{!docs/models/dcim/powerpanel.md!}
+{!models/dcim/powerpanel.md!}
-{!docs/models/dcim/powerfeed.md!}
+{!models/dcim/powerfeed.md!}
 
 # Example Power Topology
 
-![Power distribution model](../../media/power_distribution.png)
+![Power distribution model](../media/power_distribution.png)

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/core-functionality/services.md

@@ -1,3 +1,3 @@
 # Service Mapping
 
-{!docs/models/ipam/service.md!}
+{!models/ipam/service.md!}

docs/core-functionality/sites-and-racks.md

@@ -1,12 +1,12 @@
 # Sites and Racks
 
-{!docs/models/dcim/region.md!}
+{!models/dcim/region.md!}
-{!docs/models/dcim/sitegroup.md!}
+{!models/dcim/sitegroup.md!}
-{!docs/models/dcim/site.md!}
+{!models/dcim/site.md!}
-{!docs/models/dcim/location.md!}
+{!models/dcim/location.md!}
 
 ---
 
-{!docs/models/dcim/rack.md!}
+{!models/dcim/rack.md!}
-{!docs/models/dcim/rackrole.md!}
+{!models/dcim/rackrole.md!}
-{!docs/models/dcim/rackreservation.md!}
+{!models/dcim/rackreservation.md!}

docs/core-functionality/tenancy.md

@@ -1,4 +1,4 @@
 # Tenancy Assignment
 
-{!docs/models/tenancy/tenant.md!}
+{!models/tenancy/tenant.md!}
-{!docs/models/tenancy/tenantgroup.md!}
+{!models/tenancy/tenantgroup.md!}

docs/core-functionality/virtualization.md

@@ -1,10 +1,10 @@
 # Virtualization
 
-{!docs/models/virtualization/cluster.md!}
+{!models/virtualization/cluster.md!}
-{!docs/models/virtualization/clustertype.md!}
+{!models/virtualization/clustertype.md!}
-{!docs/models/virtualization/clustergroup.md!}
+{!models/virtualization/clustergroup.md!}
 
 ---
 
-{!docs/models/virtualization/virtualmachine.md!}
+{!models/virtualization/virtualmachine.md!}
-{!docs/models/virtualization/vminterface.md!}
+{!models/virtualization/vminterface.md!}

docs/core-functionality/vlans.md

@@ -1,4 +1,4 @@
 # VLAN Management
 
-{!docs/models/ipam/vlan.md!}
+{!models/ipam/vlan.md!}
-{!docs/models/ipam/vlangroup.md!}
+{!models/ipam/vlangroup.md!}

docs/core-functionality/wireless.md

@@ -0,0 +1,8 @@
+# Wireless Networks
+
+{!models/wireless/wirelesslan.md!}
+{!models/wireless/wirelesslangroup.md!}
+
+---
+
+{!models/wireless/wirelesslink.md!}

docs/customization/custom-fields.md

@@ -0,0 +1,36 @@
+{!models/extras/customfield.md!}
+
+## Custom Fields in Templates
+
+Several features within NetBox, such as export templates and webhooks, utilize Jinja2 templating. For convenience, objects which support custom field assignment expose custom field data through the `cf` property. This is a bit cleaner than accessing custom field data through the actual field (`custom_field_data`).
+
+For example, a custom field named `foo123` on the Site model is accessible on an instance as `{{ site.cf.foo123 }}`.
+
+## Custom Fields and the REST API
+
+When retrieving an object via the REST API, all of its custom data will be included within the `custom_fields` attribute. For example, below is the partial output of a site with two custom fields defined:
+
+```json
+{
+    "id": 123,
+    "url": "http://localhost:8000/api/dcim/sites/123/",
+    "name": "Raleigh 42",
+    ...
+    "custom_fields": {
+        "deployed": "2018-06-19",
+        "site_code": "US-NC-RAL42"
+    },
+    ...
+```
+
+To set or change these values, simply include nested JSON data. For example:
+
+```json
+{
+    "name": "New Site",
+    "slug": "new-site",
+    "custom_fields": {
+        "deployed": "2019-03-24"
+    }
+}
+```

docs/customization/custom-scripts.md

@@ -45,6 +45,20 @@ Defining script variables is optional: You may create a script with only a `run(
 
 Any output generated by the script during its execution will be displayed under the "output" tab in the UI.
 
+By default, scripts within a module are ordered alphabetically in the scripts list page. To return scripts in a specific order, you can define the `script_order` variable at the end of your module. The `script_order` variable is a tuple which contains each Script class in the desired order. Any scripts that are omitted from this list will be listed last.
+
+```python
+from extras.scripts import Script
+
+class MyCustomScript(Script):
+    ...
+
+class AnotherCustomScript(Script):
+    ...
+
+script_order = (MyCustomScript, AnotherCustomScript)
+```
+
 ## Module Attributes
 
 ### `name`
@@ -63,6 +77,10 @@ This is the human-friendly names of your script. If omitted, the class name will
 
 A human-friendly description of what your script does.
 
+### `field_order`
+
+By default, script variables will be ordered in the form as they are defined in the script. `field_order` may be defined as an iterable of field names to determine the order in which variables are rendered. Any fields not included in this iterable be listed last.
+
 ### `commit_default`
 
 The checkbox to commit database changes when executing a script is checked by default. Set `commit_default` to False under the script's Meta class to leave this option unchecked by default.
@@ -170,14 +188,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
@@ -231,7 +244,7 @@ An IPv4 or IPv6 network with a mask. Returns a `netaddr.IPNetwork` object. Two a
 !!! note
     To run a custom script, a user must be assigned the `extras.run_script` permission. This is achieved by assigning the user (or group) a permission on the Script object and specifying the `run` action in the admin UI as shown below.
 
-    ![Adding the run action to a permission](../../media/admin_ui_run_permission.png)
+    ![Adding the run action to a permission](../media/admin_ui_run_permission.png)
 
 ### Via the Web UI
 
@@ -250,6 +263,22 @@ http://netbox/api/extras/scripts/example.MyReport/ \
 --data '{"data": {"foo": "somevalue", "bar": 123}, "commit": true}'
 ```
 
+### Via the CLI
+
+Scripts can be run on the CLI by invoking the management command:
+
+```
+python3 manage.py runscript [--commit] [--loglevel {debug,info,warning,error,critical}] [--data "<data>"] <module>.<script> 
+```
+
+The required ``<module>.<script>`` argument is the script to run where ``<module>`` is the name of the python file in the ``scripts`` directory without the ``.py`` extension and ``<script>`` is the name of the script class in the ``<module>`` to run.
+
+The optional ``--data "<data>"`` argument is the data to send to the script
+
+The optional ``--loglevel`` argument is the desired logging level to output to the console.
+
+The optional ``--commit`` argument will commit any changes in the script to the database.
+
 ## Example
 
 Below is an example script that creates new objects for a planned site. The user is prompted for three variables:
@@ -288,7 +317,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,118 @@
+# 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 custom validation rules.
+
+## Custom Validation Rules
+
+Custom validation rules are expressed as a mapping of model attributes to a set of rules to which that attribute must conform. For example:
+
+```json
+{
+  "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. NetBox provides a `CustomValidator` class which 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/dynamic-settings.md#custom_validators) configuration parameter. There are three manners by which custom validation rules can be defined:
+
+1. Plain JSON mapping (no custom logic)
+2. Dotted path to a custom validator class
+3. Direct reference to a custom validator class
+
+### Plain Data
+
+For cases where custom logic is not needed, it is sufficient to pass validation rules as plain JSON-compatible objects. This approach typically affords the most portability for your configuration. For instance:
+
+```python
+CUSTOM_VALIDATORS = {
+    "dcim.site": [
+        {
+            "name": {
+                "min_length": 5,
+                "max_length": 30,
+            }
+        }
+    ],
+    "dcim.device": [
+        {
+            "platform": {
+                "required": True,
+            }
+        }
+    ]
+}
+```
+
+### Dotted Path
+
+In instances where a custom validator class is needed, it can be referenced by its Python path (relative to NetBox's working directory):
+
+```python
+CUSTOM_VALIDATORS = {
+    'dcim.site': (
+        'my_validators.Validator1',
+        'my_validators.Validator2',
+    ),
+    'dcim.device': (
+        'my_validators.Validator3',
+    )
+}
+```
+
+### Direct Class Reference
+
+This approach requires each class being instantiated to be imported directly within the Python configuration file.
+
+```python
+from my_validators import Validator1, Validator2, Validator3
+
+CUSTOM_VALIDATORS = {
+    'dcim.site': (
+        Validator1,
+        Validator2,
+    ),
+    'dcim.device': (
+        Validator3,
+    )
+}
+```
+
+!!! note
+    Even if defining only a single validator, it must be passed as an iterable.

docs/customization/export-templates.md

@@ -0,0 +1,44 @@
+{!models/extras/exporttemplate.md!}
+
+## 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.
+
+```
+{% for device in queryset %}{% if device.status and device.primary_ip %}define host{
+        use                     generic-switch
+        host_name               {{ device.name }}
+        address                 {{ device.primary_ip.address.ip }}
+}
+{% endif %}{% endfor %}
+```
+
+The generated output will look something like this:
+
+```
+define host{
+        use                     generic-switch
+        host_name               switch1
+        address                 192.0.2.1
+}
+define host{
+        use                     generic-switch
+        host_name               switch2
+        address                 192.0.2.2
+}
+define host{
+        use                     generic-switch
+        host_name               switch3
+        address                 192.0.2.3
+}
+```

docs/customization/reports.md

@@ -97,6 +97,20 @@ The recording of one or more failure messages will automatically flag a report a
 
 To perform additional tasks, such as sending an email or calling a webhook, after a report has been run, extend the `post_run()` method. The status of the report is available as `self.failed` and the results object is `self.result`.
 
+By default, reports within a module are ordered alphabetically in the reports list page. To return reports in a specific order, you can define the `report_order` variable at the end of your module. The `report_order` variable is a tuple which contains each Report class in the desired order. Any reports that are omitted from this list will be listed last.
+
+```
+from extras.reports import Report
+
+class DeviceConnectionsReport(Report)
+    pass
+
+class DeviceIPsReport(Report)
+    pass
+
+report_order = (DeviceIPsReport, DeviceConnectionsReport)
+```
+
 Once you have created a report, it will appear in the reports list. Initially, reports will have no results associated with them. To generate results, run the report.
 
 ## Running Reports
@@ -104,7 +118,7 @@ Once you have created a report, it will appear in the reports list. Initially, r
 !!! note
     To run a report, a user must be assigned the `extras.run_report` permission. This is achieved by assigning the user (or group) a permission on the Report object and specifying the `run` action in the admin UI as shown below.
 
-    ![Adding the run action to a permission](../../media/admin_ui_run_permission.png)
+    ![Adding the run action to a permission](/media/admin_ui_run_permission.png)
 
 ### Via the Web UI
 

docs/development/adding-models.md

@@ -6,9 +6,9 @@ Models within each app are stored in either `models.py` or within a submodule un
 
 Each model should define, at a minimum:
 
+* A `Meta` class specifying a deterministic ordering (if ordered by fields other than the primary ID)
 * A `__str__()` method returning a user-friendly string representation of the instance
 * A `get_absolute_url()` method returning an instance's direct URL (using `reverse()`)
-* A `Meta` class specifying a deterministic ordering (if ordered by fields other than the primary ID)
 
 ## 2. Define field choices
 
@@ -16,9 +16,9 @@ If the model has one or more fields with static choices, define those choices in
 
 ## 3. Generate database migrations
 
-Once your model definition is complete, generate database migrations by running `manage.py -n $NAME --no-header`. Always specify a short unique name when generating migrations.
+Once your model definition is complete, generate database migrations by running `manage.py makemigrations -n $NAME --no-header`. Always specify a short unique name when generating migrations.
 
-!!! info
+!!! info "Configuration Required"
     Set `DEVELOPER = True` in your NetBox configuration to enable the creation of new migrations.
 
 ## 4. Add all standard views
@@ -37,25 +37,32 @@ Most models will need view classes created in `views.py` to serve the following
 
 Add the relevant URL path for each view created in the previous step to `urls.py`.
 
-## 6. Create the FilterSet
+## 6. Add relevant forms
+
+Depending on the type of model being added, you may need to define several types of form classes. These include:
+
+* A base model form (for creating/editing individual objects)
+* A bulk edit form
+* A bulk import form (for CSV-based import)
+* A filterset form (for filtering the object list view)
+
+## 7. Create the FilterSet
 
 Each model should have a corresponding FilterSet class defined. This is used to filter UI and API queries. Subclass the appropriate class from `netbox.filtersets` that matches the model's parent class.
 
-Every model FilterSet should define a `q` filter to support general search queries.
+## 8. Create the table class
-
-## 7. Create the table
 
 Create a table class for the model in `tables.py` by subclassing `utilities.tables.BaseTable`. Under the table's `Meta` class, be sure to list both the fields and default columns.
 
-## 8. Create the object template
+## 9. Create the object template
 
 Create the HTML template for the object view. (The other views each typically employ a generic template.) This template should extend `generic/object.html`.
 
-## 9. Add the model to the navigation menu
+## 10. Add the model to the navigation menu
 
-For NetBox releases prior to v3.0, add the relevant link(s) to the navigation menu template. For later releases, add the relevant items in `netbox/netbox/navigation_menu.py`.
+Add the relevant navigation menu items in `netbox/netbox/navigation_menu.py`.
 
-## 10. REST API components
+## 11. REST API components
 
 Create the following for each model:
 
@@ -64,13 +71,13 @@ Create the following for each model:
 * API view in `api/views.py`
 * Endpoint route in `api/urls.py`
 
-## 11. GraphQL API components (v3.0+)
+## 12. GraphQL API components
 
 Create a Graphene object type for the model in `graphql/types.py` by subclassing the appropriate class from `netbox.graphql.types`.
 
 Also extend the schema class defined in `graphql/schema.py` with the individual object and object list fields per the established convention.
 
-## 12. Add tests
+## 13. Add tests
 
 Add tests for the following:
 
@@ -78,7 +85,7 @@ Add tests for the following:
 * API views
 * Filter sets
 
-## 13. Documentation
+## 14. Documentation
 
 Create a new documentation page for the model in `docs/models/<app_label>/<model_name>.md`. Include this file under the "features" documentation where appropriate.
 

docs/development/extending-models.md

@@ -4,16 +4,16 @@ Below is a list of tasks to consider when adding a new field to a core model.
 
 ## 1. Generate and run database migrations
 
-Django migrations are used to express changes to the database schema. In most cases, Django can generate these automatically, however very complex changes may require manual intervention. Always remember to specify a short but descriptive name when generating a new migration.
+[Django migrations](https://docs.djangoproject.com/en/stable/topics/migrations/) are used to express changes to the database schema. In most cases, Django can generate these automatically, however very complex changes may require manual intervention. Always remember to specify a short but descriptive name when generating a new migration.
 
 ```
 ./manage.py makemigrations <app> -n <name>
 ./manage.py migrate
 ```
 
-Where possible, try to merge related changes into a single migration. For example, if three new fields are being added to different models within an app, these can be expressed in the same migration. You can merge a new migration with an existing one by combining their `operations` lists.
+Where possible, try to merge related changes into a single migration. For example, if three new fields are being added to different models within an app, these can be expressed in a single migration. You can merge a newly generated migration with an existing one by combining their `operations` lists.
 
-!!! note
+!!! warning "Do not alter existing migrations"
     Migrations can only be merged within a release. Once a new release has been published, its migrations cannot be altered (other than for the purpose of correcting a bug).
 
 ## 2. Add validation logic to `clean()`
@@ -24,7 +24,6 @@ If the new field introduces additional validation requirements (beyond what's in
 class Foo(models.Model):
 
     def clean(self):
-
         super().clean()
 
         # Custom validation goes here
@@ -32,40 +31,36 @@ class Foo(models.Model):
             raise ValidationError()
 ```
 
-## 3. Add CSV helpers
+## 3. Update relevant querysets
 
-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.
+If you're adding a relational field (e.g. `ForeignKey`) and intend to include the data when retrieving 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.
 
-## 4. Update relevant querysets
+## 4. Update API serializer
 
-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.
+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 representation of the model.
 
-## 5. Update API serializer
+## 5. Add fields to forms
 
-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.
+Extend any forms to include the new field(s) as appropriate. These are found under the `forms/` directory within each app. Common forms include:
-
-## 6. Add field to forms
-
-Extend any forms to include the new field as appropriate. Common forms include:
 
 * **Credit/edit** - Manipulating a single object
 * **Bulk edit** - Performing a change on many objects at once
 * **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.
+If the new field should be filterable, add it to the `FilterSet` for the model. If the field should be searchable, remember to query 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.
+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. Also add the field name to `default_columns` if the column should be present in the table by default.
 
-## 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 +72,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/getting-started.md

@@ -35,6 +35,8 @@ The NetBox project utilizes three persistent git branches to track work:
 
 Typically, you'll base pull requests off of the `develop` branch, or off of `feature` if you're working on a new major release. **Never** merge pull requests into the `master` branch, which receives merged only from the `develop` branch.
 
+For example, assume that the current NetBox release is v3.1.1. Work applied to the `develop` branch will appear in v3.1.2, and work done under the `feature` branch will be included in the next minor release (v3.2.0).
+
 ### Enable Pre-Commit Hooks
 
 NetBox ships with a [git pre-commit hook](https://githooks.com/) script that automatically checks for style compliance and missing database migrations prior to committing changes. This helps avoid erroneous commits that result in CI test failures. You are encouraged to enable it by creating a link to `scripts/git-hooks/pre-commit`:
@@ -46,7 +48,7 @@ $ ln -s ../../scripts/git-hooks/pre-commit
 
 ### Create a Python Virtual Environment
 
-A [virtual environment](https://docs.python.org/3/tutorial/venv.html) is like a container for a set of Python packages. They allow you to build environments suited to specific projects without interfering with system packages or other projects. When installed per the documentation, NetBox uses a virtual environment in production.
+A [virtual environment](https://docs.python.org/3/tutorial/venv.html) (or "venv" for short) is like a container for a set of Python packages. These allow you to build environments suited to specific projects without interfering with system packages or other projects. When installed per the documentation, NetBox uses a virtual environment in production.
 
 Create a virtual environment using the `venv` Python module:
 
@@ -57,8 +59,8 @@ $ python3 -m venv ~/.venv/netbox
 
 This will create a directory named `.venv/netbox/` in your home directory, which houses a virtual copy of the Python executable and its related libraries and tooling. When running NetBox for development, it will be run using the Python binary at `~/.venv/netbox/bin/python`.
 
-!!! info
+!!! info "Where to Create Your Virtual Environments"
-    Keeping virtual environments in `~/.venv/` is a common convention but entirely optional: Virtual environments can be created wherever you please.
+    Keeping virtual environments in `~/.venv/` is a common convention but entirely optional: Virtual environments can be created almost wherever you please.
 
 Once created, activate the virtual environment:
 
@@ -94,7 +96,7 @@ Within the `netbox/netbox/` directory, copy `configuration.example.py` to `confi
 
 ### Start the Development Server
 
-Django provides a lightweight, auto-updating HTTP/WSGI server for development use. NetBox extends this slightly to automatically import models and other utilities. Run the NetBox development server with the `nbshell` management command:
+Django provides a lightweight, auto-updating HTTP/WSGI server for development use. It is started with the `runserver` management command:
 
 ```no-highlight
 $ python netbox/manage.py runserver
@@ -109,23 +111,38 @@ Quit the server with CONTROL-C.
 
 This ensures that your development environment is now complete and operational. Any changes you make to the code base will be automatically adapted by the development server.
 
+!!! info "IDE Integration"
+    Some IDEs, such as PyCharm, will integrate with Django's development server and allow you to run it directly within the IDE. This is strongly encouraged as it makes for a much more convenient development environment.
+
+## Populating Demo Data
+
+Once you have your development environment up and running, it might be helpful to populate some "dummy" data to make interacting with the UI and APIs more convenient. Check out the [netbox-demo-data](https://github.com/netbox-community/netbox-demo-data) repo on GitHub, which houses a collection of sample data that can be easily imported to any new NetBox deployment. (This sample data is used to populate the public demo instance at <https://demo.netbox.dev>.)
+
+The demo data is provided in JSON format and loaded into an empty database using Django's `loaddata` management command. Consult the demo data repo's `README` file for complete instructions on populating the data.
+
 ## Running Tests
 
-Throughout the course of development, it's a good idea to occasionally run NetBox's test suite to catch any potential errors. Tests are run using the `test` management command:
+Prior to committing any substantial changes to the code base, be sure to run NetBox's test suite to catch any potential errors. Tests are run using the `test` management command. Remember to ensure the Python virtual environment is active before running this command. Also keep in mind that these commands are executed in the `/netbox/` directory, not the root directory of the repository.
 
 ```no-highlight
-$ python netbox/manage.py test
+$ python manage.py test
 ```
 
 In cases where you haven't made any changes to the database (which is most of the time), you can append the `--keepdb` argument to this command to reuse the test database between runs. This cuts down on the time it takes to run the test suite since the database doesn't have to be rebuilt each time. (Note that this argument will cause errors if you've modified any model fields since the previous test run.)
 
 ```no-highlight
-$ python netbox/manage.py test --keepdb
+$ python manage.py test --keepdb
+```
+
+You can also limit the command to running only a specific subset of tests. For example, to run only IPAM and DCIM view tests:
+
+```no-highlight
+$ python manage.py test dcim.tests.test_views ipam.tests.test_views
 ```
 
 ## Submitting Pull Requests
 
-Once you're happy with your work and have verified that all tests pass, commit your changes and push it upstream to your fork. Always provide descriptive (but not excessively verbose) commit messages. When working on a specific issue, be sure to reference it.
+Once you're happy with your work and have verified that all tests pass, commit your changes and push it upstream to your fork. Always provide descriptive (but not excessively verbose) commit messages. When working on a specific issue, be sure to prefix your commit message with the word "Fixes" or "Closes" and the issue number (with a hash mark). This tells GitHub to automatically close the referenced issue once the commit has been merged.
 
 ```no-highlight
 $ git commit -m "Closes #1234: Add IPv5 support"
@@ -136,5 +153,5 @@ Once your fork has the new commit, submit a [pull request](https://github.com/ne
 
 Once submitted, a maintainer will review your pull request and either merge it or request changes. If changes are needed, you can make them via new commits to your fork: The pull request will update automatically.
 
-!!! note
+!!! note "Remember to Open an Issue First"
-    Remember, pull requests are entertained only for **accepted** issues. If an issue you want to work on hasn't been approved by a maintainer yet, it's best to avoid risking your time and effort on a change that might not be accepted.
+    Remember, pull requests are permitted only for **accepted** issues. If an issue you want to work on hasn't been approved by a maintainer yet, it's best to avoid risking your time and effort on a change that might not be accepted. (The one exception to this is trivial changes to the documentation or other non-critical resources.)

docs/development/index.md

@@ -1,32 +1,34 @@
 # NetBox Development
 
-NetBox is maintained as a [GitHub project](https://github.com/netbox-community/netbox) under the Apache 2 license. Users are encouraged to submit GitHub issues for feature requests and bug reports, however we are very selective about pull requests. Please see the `CONTRIBUTING` guide for more direction on contributing to NetBox.
+NetBox is maintained as a [GitHub project](https://github.com/netbox-community/netbox) under the Apache 2 license. Users are encouraged to submit GitHub issues for feature requests and bug reports, however we are very selective about pull requests. Each pull request must be preceded by an **approved** issue. Please see the `CONTRIBUTING` guide for more direction on contributing to NetBox.
 
 ## Communication
 
 There are several official forums for communication among the developers and community members:
 
-* [GitHub issues](https://github.com/netbox-community/netbox/issues) - All feature requests, bug reports, and other substantial changes to the code base **must** be documented in an issue.
+* [GitHub issues](https://github.com/netbox-community/netbox/issues) - All feature requests, bug reports, and other substantial changes to the code base **must** be documented in a GitHub issue.
 * [GitHub Discussions](https://github.com/netbox-community/netbox/discussions) - The preferred forum for general discussion and support issues. Ideal for shaping a feature request prior to submitting an issue.
 * [#netbox on NetDev Community Slack](https://netdev.chat/) - Good for quick chats. Avoid any discussion that might need to be referenced later on, as the chat history is not retained long.
 * [Google Group](https://groups.google.com/g/netbox-discuss) - Legacy mailing list; slowly being phased out in favor of GitHub discussions.
 
 ## Governance
 
-NetBox follows the [benevolent dictator](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) model of governance, with [Jeremy Stretch](https://github.com/jeremystretch) ultimately responsible for all changes to the code base. While community contributions are welcomed and encouraged, the lead maintainer's primary role is to ensure the project's long-term maintainability and continued focus on its primary functions (in other words, avoid scope creep).
+NetBox follows the [benevolent dictator](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) model of governance, with [Jeremy Stretch](https://github.com/jeremystretch) ultimately responsible for all changes to the code base. While community contributions are welcomed and encouraged, the lead maintainer's primary role is to ensure the project's long-term maintainability and continued focus on its primary functions.
 
 ## Project Structure
 
-All development of the current NetBox release occurs in the `develop` branch; releases are packaged from the `master` branch. The `master` branch should _always_ represent the current stable release in its entirety, such that installing NetBox by either downloading a packaged release or cloning the `master` branch provides the same code base.
+All development of the current NetBox release occurs in the `develop` branch; releases are packaged from the `master` branch. The `master` branch should _always_ represent the current stable release in its entirety, such that installing NetBox by either downloading a packaged release or cloning the `master` branch provides the same code base. Only pull requests representing new releases should be merged into `master`.
 
-NetBox components are arranged into functional subsections called _apps_ (a carryover from Django vernacular). Each app holds the models, views, and templates relevant to a particular function:
+NetBox components are arranged into Django apps. Each app holds the models, views, and other resources relevant to a particular function:
 
 * `circuits`: Communications circuits and providers (not to be confused with power circuits)
 * `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.)
 * `virtualization`: Virtual machines and clusters
+* `wireless`: Wireless links and LANs
+
+All core functionality is stored within the `netbox/` subdirectory. HTML templates are stored in a common `templates/` directory, with model- and view-specific templates arranged by app. Documentation is kept in the `docs/` root directory.

docs/development/models.md

@@ -10,19 +10,19 @@ 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
+* [Custom fields](../customization/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
+* [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
 
 | Type               | Change Logging   | Webhooks         | Custom Fields    | Export Templates | Tags             | Journaling       | Nesting          |
-| ------------------ | ---------------- | ---------------- | ---------------- | ---------------- | ---------------- | ---------------- | ---------------- |
+| ------------------ | ---------------- | ---------------- |------------------| ---------------- | ---------------- | ---------------- | ---------------- |
 | Primary            | :material-check: | :material-check: | :material-check: | :material-check: | :material-check: | :material-check: |                  |
-| Organizational     | :material-check: | :material-check: | :material-check: | :material-check: |                  |                  |                  |
+| Organizational     | :material-check: | :material-check: | :material-check: | :material-check: | :material-check: |                  |                  |
-| Nested Group       | :material-check: | :material-check: | :material-check: | :material-check: |                  |                  | :material-check: |
+| Nested Group       | :material-check: | :material-check: | :material-check: | :material-check: | :material-check: |                  | :material-check: |
 | Component          | :material-check: | :material-check: | :material-check: | :material-check: | :material-check: |                  |                  |
-| Component Template | :material-check: | :material-check: | :material-check: |                  |                  |                  |                  |
+| Component Template | :material-check: | :material-check: |                  |                  |                  |                  |                  |
 
 ## Models Index
 
@@ -41,16 +41,21 @@ The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/
 * [dcim.Site](../models/dcim/site.md)
 * [dcim.VirtualChassis](../models/dcim/virtualchassis.md)
 * [ipam.Aggregate](../models/ipam/aggregate.md)
+* [ipam.ASN](../models/ipam/asn.md)
+* [ipam.FHRPGroup](../models/ipam/fhrpgroup.md)
 * [ipam.IPAddress](../models/ipam/ipaddress.md)
+* [ipam.IPRange](../models/ipam/iprange.md)
 * [ipam.Prefix](../models/ipam/prefix.md)
 * [ipam.RouteTarget](../models/ipam/routetarget.md)
 * [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.Contact](../models/tenancy/contact.md)
 * [tenancy.Tenant](../models/tenancy/tenant.md)
 * [virtualization.Cluster](../models/virtualization/cluster.md)
 * [virtualization.VirtualMachine](../models/virtualization/virtualmachine.md)
+* [wireless.WirelessLAN](../models/wireless/wirelesslan.md)
+* [wireless.WirelessLink](../models/wireless/wirelesslink.md)
 
 ### Organizational Models
 
@@ -62,7 +67,7 @@ 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)
+* [tenancy.ContactRole](../models/tenancy/contactrole.md)
 * [virtualization.ClusterGroup](../models/virtualization/clustergroup.md)
 * [virtualization.ClusterType](../models/virtualization/clustertype.md)
 
@@ -71,7 +76,9 @@ The Django [content types](https://docs.djangoproject.com/en/stable/ref/contrib/
 * [dcim.Location](../models/dcim/location.md) (formerly RackGroup)
 * [dcim.Region](../models/dcim/region.md)
 * [dcim.SiteGroup](../models/dcim/sitegroup.md)
+* [tenancy.ContactGroup](../models/tenancy/contactgroup.md)
 * [tenancy.TenantGroup](../models/tenancy/tenantgroup.md)
+* [wireless.WirelessLANGroup](../models/wireless/wirelesslangroup.md)
 
 ### Component Models
 

docs/development/release-checklist.md

@@ -6,16 +6,6 @@
 
 Check `base_requirements.txt` for any dependencies pinned to a specific version, and upgrade them to their most stable release (where possible).
 
-### Update Static Libraries
-
-Update the following static libraries to their most recent stable release:
-
-* Bootstrap 3
-* Material Design Icons
-* Select2
-* jQuery
-* jQuery UI
-
 ### Link to the Release Notes Page
 
 Add the release notes (`/docs/release-notes/X.Y.md`) to the table of contents within `mkdocs.yml`, and point `index.md` to the new file.

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/development/style-guide.md

@@ -1,6 +1,6 @@
 # Style Guide
 
-NetBox generally follows the [Django style guide](https://docs.djangoproject.com/en/stable/internals/contributing/writing-code/coding-style/), which is itself based on [PEP 8](https://www.python.org/dev/peps/pep-0008/). [Pycodestyle](https://github.com/pycqa/pycodestyle) is used to validate code formatting, ignoring certain violations. See `scripts/cibuild.sh`.
+NetBox generally follows the [Django style guide](https://docs.djangoproject.com/en/stable/internals/contributing/writing-code/coding-style/), which is itself based on [PEP 8](https://www.python.org/dev/peps/pep-0008/). [Pycodestyle](https://github.com/pycqa/pycodestyle) is used to validate code formatting, ignoring certain violations. See `scripts/cibuild.sh` for details.
 
 ## PEP 8 Exceptions
 
@@ -30,7 +30,7 @@ pycodestyle --ignore=W504,E501 netbox/
 
 ## Introducing New Dependencies
 
-The introduction of a new dependency is best avoided unless it is absolutely necessary. For small features, it's generally preferable to replicate functionality within the NetBox code base rather than to introduce reliance on an external project. This reduces both the burden of tracking new releases and our exposure to outside bugs and attacks.
+The introduction of a new dependency is best avoided unless it is absolutely necessary. For small features, it's generally preferable to replicate functionality within the NetBox code base rather than to introduce reliance on an external project. This reduces both the burden of tracking new releases and our exposure to outside bugs and supply chain attacks.
 
 If there's a strong case for introducing a new dependency, it must meet the following criteria:
 
@@ -43,7 +43,7 @@ When adding a new dependency, a short description of the package and the URL of
 
 ## General Guidance
 
-* When in doubt, remain consistent: It is better to be consistently incorrect than inconsistently correct. If you notice in the course of unrelated work a pattern that should be corrected, continue to follow the pattern for now and open a bug so that the entire code base can be evaluated at a later point.
+* When in doubt, remain consistent: It is better to be consistently incorrect than inconsistently correct. If you notice in the course of unrelated work a pattern that should be corrected, continue to follow the pattern for now and submit a separate bug report so that the entire code base can be evaluated at a later point.
 
 * Prioritize readability over concision. Python is a very flexible language that typically offers several options for expressing a given piece of logic, but some may be more friendly to the reader than others. (List comprehensions are particularly vulnerable to over-optimization.) Always remain considerate of the future reader who may need to interpret your code without the benefit of the context within which you are writing it.
 

docs/development/web-ui.md

@@ -0,0 +1,99 @@
+# Web UI Development
+
+## Front End Technologies
+
+The NetBox UI is built on languages and frameworks:
+
+### Styling & HTML Elements
+
+#### [Bootstrap](https://getbootstrap.com/) 5
+
+The majority of the NetBox UI is made up of stock Bootstrap components, with some styling modifications and custom components added on an as-needed basis. Bootstrap uses [Sass](https://sass-lang.com/), and NetBox extends Bootstrap's core Sass files for theming and customization.
+
+### Client-side Scripting
+
+#### [TypeScript](https://www.typescriptlang.org/)
+
+All client-side scripting is transpiled from TypeScript to JavaScript and served by Django. In development, TypeScript is an _extremely_ effective tool for accurately describing and checking the code, which leads to significantly fewer bugs, a better development experience, and more predictable/readable code.
+
+As part of the [bundling](#bundling) process, Bootstrap's JavaScript plugins are imported and bundled alongside NetBox's front-end code.
+
+!!! danger "NetBox is jQuery-free"
+    Following the Bootstrap team's deprecation of jQuery in Bootstrap 5, NetBox also no longer uses jQuery in front-end code.
+
+## Guidance
+
+NetBox generally follows the following guidelines for front-end code:
+
+- Bootstrap utility classes may be used to solve one-off issues or to implement singular components, as long as the class list does not exceed 4-5 classes. If an element needs more than 5 utility classes, a custom SCSS class should be added that contains the required style properties.
+- Custom classes must be commented, explaining the general purpose of the class and where it is used.
+- Reuse SCSS variables whenever possible. CSS values should (almost) never be hard-coded.
+- All TypeScript functions must have, at a minimum, a basic [JSDoc](https://jsdoc.app/) description of what the function is for and where it is used. If possible, document all function arguments via [`@param` JSDoc block tags](https://jsdoc.app/tags-param.html).
+- Expanding on NetBox's [dependency policy](style-guide.md#introducing-new-dependencies), new front-end dependencies should be avoided unless absolutely necessary. Every new front-end dependency adds to the CSS/JavaScript file size that must be loaded by the client and this should be minimized as much as possible. If adding a new dependency is unavoidable, use a tool like [Bundlephobia](https://bundlephobia.com/) to ensure the smallest possible library is used.
+- All UI elements must be usable on all common screen sizes, including mobile devices. Be sure to test newly implemented solutions (JavaScript included) on as many screen sizes and device types as possible.
+- NetBox aligns with Bootstrap's [supported Browsers and Devices](https://getbootstrap.com/docs/5.1/getting-started/browsers-devices/) list.
+
+## UI Development
+
+To contribute to the NetBox UI, you'll need to review the main [Getting Started guide](getting-started.md) in order to set up your base environment.
+
+### Tools
+
+Once you have a working NetBox development environment, you'll need to install a few more tools to work with the NetBox UI:
+
+- [NodeJS](https://nodejs.org/en/download/) (the LTS release should suffice)
+- [Yarn](https://yarnpkg.com/getting-started/install) (version 1)
+
+After Node and Yarn are installed on your system, you'll need to install all the NetBox UI dependencies:
+
+```console
+$ cd netbox/project-static
+$ yarn
+```
+
+!!! warning "Check Your Working Directory"
+    You need to be in the `netbox/project-static` directory to run the below `yarn` commands.
+
+### Bundling
+
+In order for the TypeScript and Sass (SCSS) source files to be usable by a browser, they must first be transpiled (TypeScript → JavaScript, Sass → CSS), bundled, and minified. After making changes to TypeScript or Sass source files, run `yarn bundle`.
+
+`yarn bundle` is a wrapper around the following subcommands, any of which can be run individually:
+
+| Command               | Action                                          |
+| :-------------------- | :---------------------------------------------- |
+| `yarn bundle`         | Bundle TypeScript and Sass (SCSS) source files. |
+| `yarn bundle:styles`  | Bundle Sass (SCSS) source files only.           |
+| `yarn bundle:scripts` | Bundle TypeScript source files only.            |
+
+All output files will be written to `netbox/project-static/dist`, where Django will pick them up when `manage.py collectstatic` is run.
+
+!!! info "Remember to re-run `manage.py collectstatic`"
+    If you're running the development web server — `manage.py runserver` — you'll need to run `manage.py collectstatic` to see your changes.
+
+### Linting, Formatting & Type Checking
+
+Before committing any changes to TypeScript files, and periodically throughout the development process, you should run `yarn validate` to catch formatting, code quality, or type errors.
+
+!!! tip "IDE Integrations"
+    If you're using an IDE, it is strongly recommended to install [ESLint](https://eslint.org/docs/user-guide/integrations), [TypeScript](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-Support), and [Prettier](https://prettier.io/docs/en/editors.html) integrations, if available. Most of them will automatically check and/or correct issues in the code as you develop, which can significantly increase your productivity as a contributor.
+
+`yarn validate` is a wrapper around the following subcommands, any of which can be run individually:
+
+| Command                            | Action                                                           |
+| :--------------------------------- | :--------------------------------------------------------------- |
+| `yarn validate`                    | Run all validation.                                              |
+| `yarn validate:lint`               | Validate TypeScript code via [ESLint](https://eslint.org/) only. |
+| `yarn validate:types`              | Validate TypeScript code compilation only.                       |
+| `yarn validate:formatting`         | Validate code formatting of JavaScript & Sass/SCSS files.        |
+| `yarn validate:formatting:styles`  | Validate code formatting Sass/SCSS only.                         |
+| `yarn validate:formatting:scripts` | Validate code formatting TypeScript only.                        |
+
+You can also run the following commands to automatically fix formatting issues:
+
+| Command               | Action                                          |
+| :-------------------- | :---------------------------------------------- |
+| `yarn format`         | Format TypeScript and Sass (SCSS) source files. |
+| `yarn format:styles`  | Format Sass (SCSS) source files only.           |
+| `yarn format:scripts` | Format TypeScript source files only.            |
+

docs/extra.css

@@ -11,9 +11,19 @@ table {
     width: 100%;
 }
 th {
-    background-color: #f0f0f0;
     padding: 6px;
+    font-weight: bold;
 }
 td {
     padding: 6px;
 }
+/* Remove table header coloring.  */
+.md-typeset table:not([class]) th {
+    color: unset !important;
+    background-color: unset !important;
+}
+thead tr {
+    /* Colorize table headers. */
+    background-color: var(--md-code-bg-color);
+    color: var(--md-code-fg-color);
+}

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 {circuit_list(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 filters) 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 {site_list(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/dynamic-settings.md#graphql_enabled) configuration parameter to False and restarting NetBox.

docs/index.md

@@ -10,7 +10,6 @@ NetBox is an infrastructure resource modeling (IRM) application designed to empo
 * **Connections** - Network, console, and power connections among devices
 * **Virtualization** - Virtual machines and clusters
 * **Data circuits** - Long-haul communications circuits and providers
-* **Secrets** - Encrypted storage of sensitive credentials
 
 ## What NetBox Is Not
 
@@ -49,14 +48,16 @@ NetBox is built on the [Django](https://djangoproject.com/) Python framework and
 | HTTP service       | nginx or Apache   |
 | WSGI service       | gunicorn or uWSGI |
 | Application        | Django/Python     |
-| Database           | PostgreSQL 9.6+   |
+| Database           | PostgreSQL 10+    |
 | Task queuing       | Redis/django-rq   |
-| Live device access | NAPALM            |
+| Live device access | NAPALM (optional) |
 
 ## Supported Python Versions
 
-NetBox supports Python 3.6, 3.7, and 3.8 environments currently. (Support for Python 3.5 was removed in NetBox v2.8.)
+NetBox supports Python 3.7, 3.8, and 3.9 environments currently. (Support for Python 3.6 was removed in NetBox v3.0.)
 
 ## Getting Started
 
-See the [installation guide](installation/index.md) for help getting NetBox up and running quickly.
+Minor NetBox releases (e.g. v3.1) are published three times a year; in April, August, and December. These typically introduce major new features and may contain breaking API changes. Patch releases are published roughly every one to two weeks to resolve bugs and fulfill minor feature requests. These are backward-compatible with previous releases unless otherwise noted. The NetBox maintainers strongly recommend running the latest stable release whenever possible.
+
+Please see the [official installation guide](installation/index.md) for detailed instructions on obtaining and installing NetBox.

docs/installation/1-postgresql.md

@@ -2,8 +2,8 @@
 
 This section entails the installation and configuration of a local PostgreSQL database. If you already have a PostgreSQL database service in place, skip to [the next section](2-redis.md).
 
-!!! warning
+!!! warning "PostgreSQL 10 or later required"
-    NetBox requires PostgreSQL 9.6 or higher. Please note that MySQL and other relational databases are **not** currently supported.
+    NetBox requires PostgreSQL 10 or later. Please note that MySQL and other relational databases are **not** supported.
 
 ## Installation
 
@@ -21,9 +21,6 @@ This section entails the installation and configuration of a local PostgreSQL da
     sudo postgresql-setup --initdb
     ```
 
-    !!! info
-        PostgreSQL 9.6 and later are available natively on CentOS 8.2. If using an earlier CentOS release, you may need to [install it from an RPM](https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/).
-
     CentOS configures ident host-based authentication for PostgreSQL by default. Because NetBox will need to authenticate using a username and password, modify `/var/lib/pgsql/data/pg_hba.conf` to support MD5 authentication by changing `ident` to `md5` for the lines below:
 
     ```no-highlight
@@ -38,30 +35,36 @@ sudo systemctl start postgresql
 sudo systemctl enable postgresql
 ```
 
-## Database Creation
+Before continuing, verify that you have installed PostgreSQL 10 or later:
-
-At a minimum, we need to create a database for NetBox and assign it a username and password for authentication. This is done with the following commands.
-
-!!! danger
-    **Do not use the password from the example.** Choose a strong, random password to ensure secure database authentication for your NetBox installation.
 
 ```no-highlight
-$ sudo -u postgres psql
+psql -V
-psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1))
-Type "help" for help.
-
-postgres=# CREATE DATABASE netbox;
-CREATE DATABASE
-postgres=# CREATE USER netbox WITH PASSWORD 'J5brHrAXFLQSif0K';
-CREATE ROLE
-postgres=# GRANT ALL PRIVILEGES ON DATABASE netbox TO netbox;
-GRANT
-postgres=# \q
 ```
 
+## Database Creation
+
+At a minimum, we need to create a database for NetBox and assign it a username and password for authentication. Start by invoking the PostgreSQL shell as the system Postgres user.
+
+```no-highlight
+sudo -u postgres psql
+```
+
+Within the shell, enter the following commands to create the database and user (role), substituting your own value for the password:
+
+```postgresql
+CREATE DATABASE netbox;
+CREATE USER netbox WITH PASSWORD 'J5brHrAXFLQSif0K';
+GRANT ALL PRIVILEGES ON DATABASE netbox TO netbox;
+```
+
+!!! danger "Use a strong password"
+    **Do not use the password from the example.** Choose a strong, random password to ensure secure database authentication for your NetBox installation.
+
+Once complete, enter `\q` to exit the PostgreSQL shell.
+
 ## Verify Service Status
 
-You can verify that authentication works issuing the following command and providing the configured password. (Replace `localhost` with your database server if using a remote database.)
+You can verify that authentication works by executing the `psql` command and passing the configured username and password. (Replace `localhost` with your database server if using a remote database.)
 
 ```no-highlight
 $ psql --username netbox --password --host localhost netbox

docs/installation/2-redis.md

@@ -4,7 +4,7 @@
 
 [Redis](https://redis.io/) is an in-memory key-value store which NetBox employs for caching and queuing. This section entails the installation and configuration of a local Redis instance. If you already have a Redis service in place, skip to [the next section](3-netbox.md).
 
-!!! note
+!!! warning "Redis v4.0 or later required"
     NetBox v2.9.0 and later require Redis v4.0 or higher. If your distribution does not offer a recent enough release, you will need to build Redis from source. Please see [the Redis installation documentation](https://github.com/redis/redis) for further details.
 
 === "Ubuntu"
@@ -21,6 +21,12 @@
     sudo systemctl enable redis
     ```
 
+Before continuing, verify that your installed version of Redis is at least v4.0:
+
+```no-highlight
+redis-server -v
+```
+
 You may wish to modify the Redis configuration at `/etc/redis.conf` or `/etc/redis/redis.conf`, however in most cases the default configuration is sufficient.
 
 ## Verify Service Status
@@ -28,6 +34,7 @@ You may wish to modify the Redis configuration at `/etc/redis.conf` or `/etc/red
 Use the `redis-cli` utility to ensure the Redis service is functional:
 
 ```no-highlight
-$ redis-cli ping
+redis-cli ping
-PONG
 ```
+
+If successful, you should receive a `PONG` response from the server.

docs/installation/3-netbox.md

@@ -6,8 +6,8 @@ This section of the documentation discusses installing and configuring the NetBo
 
 Begin by installing all system packages required by NetBox and its dependencies.
 
-!!! note
+!!! warning "Python 3.7 or later required"
-    NetBox v2.8.0 and later require Python 3.6, 3.7, or 3.8.
+    NetBox v3.0 and v3.1 require Python 3.7, 3.8, or 3.9. It is recommended to install at least Python v3.8, as this will become the minimum supported Python version in NetBox v3.2.
 
 === "Ubuntu"
 
@@ -17,14 +17,19 @@ Begin by installing all system packages required by NetBox and its dependencies.
 
 === "CentOS"
 
+    !!! warning
+        CentOS 8 does not provide Python 3.7 or later via its native package manager. You will need to install it via some other means. [Here is an example](https://tecadmin.net/install-python-3-7-on-centos-8/) of installing Python 3.7 from source.
+
+    Once you have Python 3.7 or later installed, install the remaining system packages:
+
     ```no-highlight
-    sudo yum install -y gcc python36 python36-devel python3-pip libxml2-devel libxslt-devel libffi-devel libpq-devel openssl-devel redhat-rpm-config
+    sudo yum install -y gcc libxml2-devel libxslt-devel libffi-devel libpq-devel openssl-devel redhat-rpm-config
     ```
 
-Before continuing with either platform, update pip (Python's package management tool) to its latest release:
+Before continuing, check that your installed Python version is at least 3.7:
 
 ```no-highlight
-sudo pip3 install --upgrade pip
+python3 -V
 ```
 
 ## Download NetBox
@@ -36,23 +41,21 @@ This documentation provides two options for installing NetBox: from a downloadab
 Download the [latest stable release](https://github.com/netbox-community/netbox/releases) from GitHub as a tarball or ZIP archive and extract it to your desired path. In this example, we'll use `/opt/netbox` as the NetBox root.
 
 ```no-highlight
-$ sudo wget https://github.com/netbox-community/netbox/archive/vX.Y.Z.tar.gz
+sudo wget https://github.com/netbox-community/netbox/archive/vX.Y.Z.tar.gz
-$ sudo tar -xzf vX.Y.Z.tar.gz -C /opt
+sudo tar -xzf vX.Y.Z.tar.gz -C /opt
-$ sudo ln -s /opt/netbox-X.Y.Z/ /opt/netbox
+sudo ln -s /opt/netbox-X.Y.Z/ /opt/netbox
-$ ls -l /opt | grep netbox
-lrwxrwxrwx  1 root root         13 Jul 20 13:44 netbox -> netbox-2.9.0/
-drwxr-xr-x  2 root root       4096 Jul 20 13:44 netbox-2.9.0
 ```
 
 !!! note
-    It is recommended to install NetBox in a directory named for its version number. For example, NetBox v2.9.0 would be installed into `/opt/netbox-2.9.0`, and a symlink from `/opt/netbox/` would point to this location. This allows for future releases to be installed in parallel without interrupting the current installation. When changing to the new release, only the symlink needs to be updated.
+    It is recommended to install NetBox in a directory named for its version number. For example, NetBox v3.0.0 would be installed into `/opt/netbox-3.0.0`, and a symlink from `/opt/netbox/` would point to this location. (You can verify this configuration with the command `ls -l /opt | grep netbox`.) This allows for future releases to be installed in parallel without interrupting the current installation. When changing to the new release, only the symlink needs to be updated.
 
 ### Option B: Clone the Git Repository
 
 Create the base directory for the NetBox installation. For this guide, we'll use `/opt/netbox`.
 
 ```no-highlight
-sudo mkdir -p /opt/netbox/ && cd /opt/netbox/
+sudo mkdir -p /opt/netbox/
+cd /opt/netbox/
 ```
 
 If `git` is not already installed, install it:
@@ -72,23 +75,26 @@ If `git` is not already installed, install it:
 Next, clone the **master** branch of the NetBox GitHub repository into the current directory. (This branch always holds the current stable release.)
 
 ```no-highlight
-$ sudo git clone -b master https://github.com/netbox-community/netbox.git .
+sudo git clone -b master --depth 1 https://github.com/netbox-community/netbox.git .
-```
-
-The screen below should be the result:
-
-```
-Cloning into '.'...
-remote: Counting objects: 1994, done.
-remote: Compressing objects: 100% (150/150), done.
-remote: Total 1994 (delta 80), reused 0 (delta 0), pack-reused 1842
-Receiving objects: 100% (1994/1994), 472.36 KiB | 0 bytes/s, done.
-Resolving deltas: 100% (1495/1495), done.
-Checking connectivity... done.
 ```
 
 !!! note
-    Installation via git also allows you to easily try out development versions of NetBox. The `develop` branch contains all work underway for the next minor release, and the `feature` branch tracks progress on the next major release. 
+    The `git clone` command above utilizes a "shallow clone" to retrieve only the most recent commit. If you need to download the entire history, omit the `--depth 1` argument.
+
+The `git clone` command should generate output similar to the following:
+
+```
+Cloning into '.'...
+remote: Enumerating objects: 996, done.
+remote: Counting objects: 100% (996/996), done.
+remote: Compressing objects: 100% (935/935), done.
+remote: Total 996 (delta 148), reused 386 (delta 34), pack-reused 0
+Receiving objects: 100% (996/996), 4.26 MiB | 9.81 MiB/s, done.
+Resolving deltas: 100% (148/148), done.
+```
+
+!!! note
+    Installation via git also allows you to easily try out different versions of NetBox. To check out a [specific NetBox release](https://github.com/netbox-community/netbox/releases), use the `git checkout` command with the desired release tag. For example, `git checkout v3.0.8`.
 
 ## Create the NetBox System User
 
@@ -189,7 +195,7 @@ A simple Python script named `generate_secret_key.py` is provided in the parent
 python3 ../generate_secret_key.py
 ```
 
-!!! warning
+!!! warning "SECRET_KEY values must match"
     In the case of a highly available installation with multiple web servers, `SECRET_KEY` must be identical among all servers in order to maintain a persistent user session state.
 
 When you have finished modifying the configuration, remember to save the file.
@@ -200,7 +206,7 @@ All Python packages required by NetBox are listed in `requirements.txt` and will
 
 ### NAPALM
 
-The [NAPALM automation](https://napalm-automation.net/) library allows NetBox to fetch live data from devices and return it to a requester via its REST API. The `NAPALM_USERNAME` and `NAPALM_PASSWORD` configuration parameters define the credentials to be used when connecting to a device.
+Integration with the [NAPALM automation](../additional-features/napalm.md) library allows NetBox to fetch live data from devices and return it to a requester via its REST API. The `NAPALM_USERNAME` and `NAPALM_PASSWORD` configuration parameters define the credentials to be used when connecting to a device.
 
 ```no-highlight
 sudo sh -c "echo 'napalm' >> /opt/netbox/local_requirements.txt"
@@ -219,14 +225,21 @@ sudo sh -c "echo 'django-storages' >> /opt/netbox/local_requirements.txt"
 Once NetBox has been configured, we're ready to proceed with the actual installation. We'll run the packaged upgrade script (`upgrade.sh`) to perform the following actions:
 
 * Create a Python virtual environment
-* Install all required Python packages
+* Installs all required Python packages
 * Run database schema migrations
+* Builds the documentation locally (for offline use)
 * Aggregate static resource files on disk
 
 ```no-highlight
 sudo /opt/netbox/upgrade.sh
 ```
 
+Note that **Python 3.7 or later is required** for NetBox v3.0 and later releases. If the default Python installation on your server is set to a lesser version,  pass the path to the supported installation as an environment variable named `PYTHON`. (Note that the environment variable must be passed _after_ the `sudo` command.)
+
+```no-highlight
+sudo PYTHON=/usr/bin/python3.7 /opt/netbox/upgrade.sh
+```
+
 !!! note
     Upon completion, the upgrade script may warn that no existing virtual environment was detected. As this is a new installation, this warning can be safely ignored.
 
@@ -243,30 +256,45 @@ Once the virtual environment has been activated, you should notice the string `(
 Next, we'll create a superuser account using the `createsuperuser` Django management command (via `manage.py`). Specifying an email address for the user is not required, but be sure to use a very strong password.
 
 ```no-highlight
-(venv) $ cd /opt/netbox/netbox
+cd /opt/netbox/netbox
-(venv) $ python3 manage.py createsuperuser
+python3 manage.py createsuperuser
-Username: admin
-Email address: admin@example.com
-Password:
-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 or linked from 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
+sudo ln -s /opt/netbox/contrib/netbox-housekeeping.sh /etc/cron.daily/netbox-housekeeping
+```
+
+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:
 
 ```no-highlight
-(venv) $ python3 manage.py runserver 0.0.0.0:8000 --insecure
+python3 manage.py runserver 0.0.0.0:8000 --insecure
+```
+
+If successful, you should see output similar to the following:
+
+```no-highlight
+Watching for file changes with StatReloader
 Performing system checks...
 
 System check identified no issues (0 silenced).
-November 17, 2020 - 16:08:13
+August 30, 2021 - 18:02:23
-Django version 3.1.3, using settings 'netbox.settings'
+Django version 3.2.6, using settings 'netbox.settings'
-Starting development server at http://0.0.0.0:8000/
+Starting development server at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 ```
 
+Next, connect to the name or IP of the server (as defined in `ALLOWED_HOSTS`) on port 8000; for example, <http://127.0.0.1:8000/>. You should be greeted with the NetBox home page. Try logging in using the username and password specified when creating a superuser.
+
 !!! note
     By default RHEL based distros will likely block your testing attempts with firewalld. The development server port can be opened with `firewall-cmd` (add `--permanent` if you want the rule to survive server restarts):
 
@@ -274,20 +302,10 @@ Quit the server with CONTROL-C.
     firewall-cmd --zone=public --add-port=8000/tcp
     ```
 
-Next, connect to the name or IP of the server (as defined in `ALLOWED_HOSTS`) on port 8000; for example, <http://127.0.0.1:8000/>. You should be greeted with the NetBox home page.
+!!! danger "Not for production use"
-
-!!! danger
     The development server is for development and testing purposes only. It is neither performant nor secure enough for production use. **Do not use it in production.**
 
 !!! warning
     If the test service does not run, or you cannot reach the NetBox home page, something has gone wrong. Do not proceed with the rest of this guide until the installation has been corrected.
 
-Note that the initial user interface will be locked down for non-authenticated users.
-
-![NetBox UI as seen by a non-authenticated user](../media/installation/netbox_ui_guest.png)
-
-Try logging in using the superuser account we just created. Once authenticated, you'll be able to access all areas of the UI:
-
-![NetBox UI as seen by an administrator](../media/installation/netbox_ui_admin.png)
-
 Type `Ctrl+c` to stop the development server.

docs/installation/4-gunicorn.md

@@ -14,7 +14,7 @@ While the provided configuration should suffice for most initial installations,
 
 ## systemd Setup
 
-We'll use systemd to control both gunicorn and NetBox's background worker process. First, copy `contrib/netbox.service` and `contrib/netbox-rq.service` to the `/etc/systemd/system/` directory and reload the systemd dameon:
+We'll use systemd to control both gunicorn and NetBox's background worker process. First, copy `contrib/netbox.service` and `contrib/netbox-rq.service` to the `/etc/systemd/system/` directory and reload the systemd daemon:
 
 ```no-highlight
 sudo cp -v /opt/netbox/contrib/*.service /etc/systemd/system/
@@ -31,18 +31,23 @@ sudo systemctl enable netbox netbox-rq
 You can use the command `systemctl status netbox` to verify that the WSGI service is running:
 
 ```no-highlight
-# systemctl status netbox.service
+systemctl status netbox.service
+```
+
+You should see output similar to the following:
+
+```no-highlight
 ● netbox.service - NetBox WSGI Service
      Loaded: loaded (/etc/systemd/system/netbox.service; enabled; vendor preset: enabled)
-     Active: active (running) since Tue 2020-11-17 16:18:23 UTC; 3min 35s ago
+     Active: active (running) since Mon 2021-08-30 04:02:36 UTC; 14h ago
        Docs: https://netbox.readthedocs.io/en/stable/
-   Main PID: 22836 (gunicorn)
+   Main PID: 1140492 (gunicorn)
-      Tasks: 6 (limit: 2345)
+      Tasks: 19 (limit: 4683)
-     Memory: 339.3M
+     Memory: 666.2M
      CGroup: /system.slice/netbox.service
-             ├─22836 /opt/netbox/venv/bin/python3 /opt/netbox/venv/bin/gunicorn --pid>
+             ├─1140492 /opt/netbox/venv/bin/python3 /opt/netbox/venv/bin/gunicorn --pid /va>
-             ├─22854 /opt/netbox/venv/bin/python3 /opt/netbox/venv/bin/gunicorn --pid>
+             ├─1140513 /opt/netbox/venv/bin/python3 /opt/netbox/venv/bin/gunicorn --pid /va>
-             ├─22855 /opt/netbox/venv/bin/python3 /opt/netbox/venv/bin/gunicorn --pid>
+             ├─1140514 /opt/netbox/venv/bin/python3 /opt/netbox/venv/bin/gunicorn --pid /va>
 ...
 ```
 

docs/installation/6-ldap.md

@@ -152,7 +152,7 @@ LOGGING = {
         'netbox_auth_log': {
             'level': 'DEBUG',
             'class': 'logging.handlers.RotatingFileHandler',
-            'filename': '/opt/netbox/logs/django-ldap-debug.log',
+            'filename': '/opt/netbox/local/logs/django-ldap-debug.log',
             'maxBytes': 1024 * 500,
             'backupCount': 5,
         },

docs/installation/index.md

@@ -1,6 +1,6 @@
 # Installation
 
-The installation instructions provided here have been tested to work on Ubuntu 20.04 and CentOS 8.2. The particular commands needed to install dependencies on other distributions may vary significantly. Unfortunately, this is outside the control of the NetBox maintainers. Please consult your distribution's documentation for assistance with any errors.
+The installation instructions provided here have been tested to work on Ubuntu 20.04 and CentOS 8.3. The particular commands needed to install dependencies on other distributions may vary significantly. Unfortunately, this is outside the control of the NetBox maintainers. Please consult your distribution's documentation for assistance with any errors.
 
 The following sections detail how to set up a new instance of NetBox:
 
@@ -11,16 +11,16 @@ The following sections detail how to set up a new instance of NetBox:
 5. [HTTP server](5-http-server.md)
 6. [LDAP authentication](6-ldap.md) (optional)
 
-The video below demonstrates the installation of NetBox v2.10.3 on Ubuntu 20.04 for your reference.
+The video below demonstrates the installation of NetBox v3.0 on Ubuntu 20.04 for your reference.
 
-<iframe width="560" height="315" src="https://www.youtube.com/embed/dFANGlxXEng" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<iframe width="560" height="315" src="https://www.youtube.com/embed/7Fpd2-q9_28" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ## Requirements
 
 | Dependency | Minimum Version |
 |------------|-----------------|
-| Python     | 3.6             |
+| Python     | 3.7             |
-| PostgreSQL | 9.6             |
+| PostgreSQL | 10              |
 | Redis      | 4.0             |
 
 !!! note

docs/installation/upgrading.md

@@ -6,12 +6,12 @@ Prior to upgrading your NetBox instance, be sure to carefully review all [releas
 
 ## Update Dependencies to Required Versions
 
-NetBox v2.9.0 and later requires the following:
+NetBox v3.0 and later requires the following:
 
 | Dependency | Minimum Version |
 |------------|-----------------|
-| Python     | 3.6             |
+| Python     | 3.7             |
-| PostgreSQL | 9.6             |
+| PostgreSQL | 10              |
 | Redis      | 4.0             |
 
 ## Install the Latest Release
@@ -75,16 +75,23 @@ Once the new code is in place, verify that any optional Python packages required
 sudo ./upgrade.sh
 ```
 
+!!! warning
+    If the default version of Python is not at least 3.7, you'll need to pass the path to a supported Python version as an environment variable when calling the upgrade script. For example:
+
+    ```no-highlight
+    sudo PYTHON=/usr/bin/python3.7 ./upgrade.sh
+    ```
+
 This script performs the following actions:
 
 * Destroys and rebuilds the Python virtual environment
 * Installs all required Python packages (listed in `requirements.txt`)
 * Installs any additional packages from `local_requirements.txt`
 * Applies any database migrations that were included in the release
+* Builds the documentation locally (for offline use)
 * Collects all static files to be served by the HTTP service
 * Deletes stale content types from the database
 * Deletes all expired user sessions from the database
-* Clears all cached data to prevent conflicts with the new release
 
 !!! note
     If the upgrade script prompts a warning about unreflected database migrations, this indicates that some change has
@@ -102,5 +109,12 @@ Finally, restart the gunicorn and RQ services:
 sudo systemctl restart netbox netbox-rq
 ```
 
-!!! note
+## Verify Housekeeping Scheduling
-    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.
+
+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 linked from 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
+sudo ln -s /opt/netbox/contrib/netbox-housekeeping.sh /etc/cron.daily/netbox-housekeeping
+```
+
+See the [housekeeping documentation](../administration/housekeeping.md) for further details.

docs/models/dcim/cable.md

@@ -22,13 +22,3 @@ Each cable may be assigned a type, label, length, and color. Each cable is also
 ## Tracing Cables
 
 A cable may be traced from either of its endpoints by clicking the "trace" button. (A REST API endpoint also provides this functionality.) NetBox will follow the path of connected cables from this termination across the directly connected cable to the far-end termination. If the cable connects to a pass-through port, and the peer port has another cable connected, NetBox will continue following the cable path until it encounters a non-pass-through or unconnected termination point. The entire path will be displayed to the user.
-
-In the example below, three individual cables comprise a path between devices A and D:
-
-![Cable path](../../media/models/dcim_cable_trace.png)
-
-Traced from Interface 1 on Device A, NetBox will show the following path:
-
-* Cable 1: Interface 1 to Front Port 1
-* Cable 2: Rear Port 1 to Rear Port 2
-* Cable 3: Front Port 2 to Interface 2

docs/models/dcim/devicetype.md

@@ -12,3 +12,5 @@ Some devices house child devices which share physical resources, like space and
 
 !!! note
     This parent/child relationship is **not** suitable for modeling chassis-based devices, wherein child members share a common control plane. Instead, line cards and similarly non-autonomous hardware should be modeled as inventory items within a device, with any associated interfaces or other components assigned directly to the device.
+
+A device type may optionally specify an airflow direction, such as front-to-rear, rear-to-front, or passive. Airflow direction may also be set separately per device. If it is not defined for a device at the time of its creation, it will inherit the airflow setting of its device type.

docs/models/dcim/interface.md

@@ -11,6 +11,17 @@ Interfaces may be physical or virtual in nature, but only physical interfaces ma
 
 Physical interfaces may be arranged into a link aggregation group (LAG) and associated with a parent LAG (virtual) interface. LAG interfaces can be recursively nested to model bonding of trunk groups. Like all virtual interfaces, LAG interfaces cannot be connected physically.
 
+### Wireless Interfaces
+
+Wireless interfaces may additionally track the following attributes:
+
+* **Role** - AP or station
+* **Channel** - One of several standard wireless channels
+* **Channel Frequency** - The transmit frequency
+* **Channel Width** - Channel bandwidth
+
+If a predefined channel is selected, the frequency and width attributes will be assigned automatically. If no channel is selected, these attributes may be defined manually.
+
 ### IP Address Assignment
 
 IP addresses can be assigned to interfaces. VLANs can also be assigned to each interface as either tagged or untagged. (An interface may have only one untagged VLAN.)

docs/models/dcim/location.md

@@ -2,4 +2,5 @@
 
 Racks and devices can be grouped by location within a site. A location may represent a floor, room, cage, or similar organizational unit. Locations can be nested to form a hierarchy. For example, you may have floors within a site, and rooms within a floor.
 
-The name and facility ID of each rack within a location must be unique. (Racks not assigned to the same location may have identical names and/or facility IDs.)
+Each location must have a name that is unique within its parent site and location, if any.
+

docs/models/dcim/platform.md

@@ -4,6 +4,6 @@ A platform defines the type of software running on a device or virtual machine.
 
 Platforms may optionally be limited by manufacturer: If a platform is assigned to a particular manufacturer, it can only be assigned to devices with a type belonging to that manufacturer.
 
-The platform model is also used to indicate which [NAPALM](https://napalm-automation.net/) driver and any associated arguments NetBox should use when connecting to a remote device. The name of the driver along with optional parameters are stored with the platform.
+The platform model is also used to indicate which NAPALM driver (if any) and any associated arguments NetBox should use when connecting to a remote device. The name of the driver along with optional parameters are stored with the platform.
 
 The assignment of platforms to devices is an optional feature, and may be disregarded if not desired.

docs/models/dcim/rack.md

@@ -1,6 +1,6 @@
 # Racks
 
-The rack model represents a physical two- or four-post equipment rack in which devices can be installed. Each rack must be assigned to a site, and may optionally be assigned to a location and/or tenant. Racks can also be organized by user-defined functional roles.
+The rack model represents a physical two- or four-post equipment rack in which devices can be installed. Each rack must be assigned to a site, and may optionally be assigned to a location and/or tenant. Racks can also be organized by user-defined functional roles. The name and facility ID of each rack within a location must be unique.
 
 Rack height is measured in *rack units* (U); racks are commonly between 42U and 48U tall, but NetBox allows you to define racks of arbitrary height. A toggle is provided to indicate whether rack units are in ascending (from the ground up) or descending order.
 

docs/models/dcim/region.md

@@ -1,3 +1,5 @@
 # Regions
 
 Sites can be arranged geographically using regions. A region might represent a continent, country, city, campus, or other area depending on your use case. Regions can be nested recursively to construct a hierarchy. For example, you might define several country regions, and within each of those several state or city regions to which sites are assigned.
+
+Each region must have a name that is unique within its parent region, if any.

docs/models/dcim/sitegroup.md

@@ -1,3 +1,5 @@
 # Site Groups
 
 Like regions, site groups can be used to organize sites. Whereas regions are intended to provide geographic organization, site groups can be used to classify sites by role or function. Also like regions, site groups can be nested to form a hierarchy. Sites which belong to a child group are also considered to be members of any of its parent groups.
+
+Each site group must have a name that is unique within its parent group, if any.

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/extras/customfield.md

@@ -8,17 +8,19 @@ 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)
+* Long text: Free-form of any length; supports Markdown rendering
 * Integer: A whole number (positive or negative)
 * Boolean: True or false
 * Date: A date in ISO 8601 format (YYYY-MM-DD)
 * URL: This will be presented as a link in the web UI
+* JSON: Arbitrary data stored in JSON format
 * Selection: A selection of one of several pre-defined custom choices
 * Multiple selection: A selection field which supports the assignment of multiple values
 
-Each custom field must have a name; this should be a simple database-friendly string, e.g. `tps_report`. You may also assign a corresponding human-friendly label (e.g. "TPS report"); the label will be displayed on web forms. A weight is also required: Higher-weight fields will be ordered lower within a form. (The default weight is 100.) If a description is provided, it will appear beneath the field in a form.
+Each custom field must have a name. This should be a simple database-friendly string (e.g. `tps_report`) and may contain only alphanumeric characters and underscores. You may also assign a corresponding human-friendly label (e.g. "TPS report"); the label will be displayed on web forms. A weight is also required: Higher-weight fields will be ordered lower within a form. (The default weight is 100.) If a description is provided, it will appear beneath the field in a form.
 
 Marking a field as required will force the user to provide a value for the field when creating a new object or when saving an existing object. A default value for the field may also be provided. Use "true" or "false" for boolean fields, or the exact value of a choice for selection fields.
 
@@ -39,38 +41,3 @@ NetBox supports limited custom validation for custom field values. Following are
 Each custom selection field must have at least two choices. These are specified as a comma-separated list. Choices appear in forms in the order they are listed. Note that choice values are saved exactly as they appear, so it's best to avoid superfluous punctuation or symbols where possible.
 
 If a default value is specified for a selection field, it must exactly match one of the provided choices. The value of a multiple selection field will always return a list, even if only one value is selected.
-
-## Custom Fields in Templates
-
-Several features within NetBox, such as export templates and webhooks, utilize Jinja2 templating. For convenience, objects which support custom field assignment expose custom field data through the `cf` property. This is a bit cleaner than accessing custom field data through the actual field (`custom_field_data`).
-
-For example, a custom field named `foo123` on the Site model is accessible on an instance as `{{ site.cf.foo123 }}`.
-
-## Custom Fields and the REST API
-
-When retrieving an object via the REST API, all of its custom data will be included within the `custom_fields` attribute. For example, below is the partial output of a site with two custom fields defined:
-
-```json
-{
-    "id": 123,
-    "url": "http://localhost:8000/api/dcim/sites/123/",
-    "name": "Raleigh 42",
-    ...
-    "custom_fields": {
-        "deployed": "2018-06-19",
-        "site_code": "US-NC-RAL42"
-    },
-    ...
-```
-
-To set or change these values, simply include nested JSON data. For example:
-
-```json
-{
-    "name": "New Site",
-    "slug": "new-site",
-    "custom_fields": {
-        "deployed": "2019-03-24"
-    }
-}
-```

docs/models/extras/customlink.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 (NMS).
 
-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 has display text and a URL, and data from the Netbox item being viewed can be included in the link using [Jinja2 template code](https://jinja2docs.readthedocs.io/en/stable/) through the variable `obj`, and custom fields through `obj.cf`.
 
 For example, you might define a link like this:
 
@@ -15,7 +15,10 @@ 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.
+
+!!! warning
+    Custom links rely on user-created code to generate arbitrary HTML output, which may be dangerous. Only grant permission to create or modify custom links to trusted users.
 
 !!! warning
     Custom links rely on user-created code to generate arbitrary HTML output, which may be dangerous. Only grant permission to create or modify custom links to trusted users.
@@ -55,3 +58,7 @@ The link will only appear when viewing a device with a manufacturer name of "Cis
 ## Link Groups
 
 Group names can be specified to organize links into groups. Links with the same group name will render as a dropdown menu beneath a single button bearing the name of the group.
+
+## Table Columns
+
+Custom links can also be included in object tables by selecting the desired links from the table configuration form. When displayed, each link will render as a hyperlink for its corresponding object. When exported (e.g. as CSV data), each link render only its URL.

docs/models/extras/exporttemplate.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.
 
@@ -35,36 +35,3 @@ If you need to use the config context data in an export template, you'll should
 The `as_attachment` attribute of an export template controls its behavior when rendered. If true, the rendered content will be returned to the user as a downloadable file. If false, it will be displayed within the browser. (This may be handy e.g. for generating HTML content.)
 
 A MIME type and file extension can optionally be defined for each export template. The default MIME type is `text/plain`.
-
-## Example
-
-Here's an example device export template that will generate a simple Nagios configuration from a list of devices.
-
-```
-{% for device in queryset %}{% if device.status and device.primary_ip %}define host{
-        use                     generic-switch
-        host_name               {{ device.name }}
-        address                 {{ device.primary_ip.address.ip }}
-}
-{% endif %}{% endfor %}
-```
-
-The generated output will look something like this:
-
-```
-define host{
-        use                     generic-switch
-        host_name               switch1
-        address                 192.0.2.1
-}
-define host{
-        use                     generic-switch
-        host_name               switch2
-        address                 192.0.2.2
-}
-define host{
-        use                     generic-switch
-        host_name               switch3
-        address                 192.0.2.3
-}
-```

docs/models/extras/tag.md

@@ -15,6 +15,3 @@ The `tag` filter can be specified multiple times to match only objects which hav
 ```no-highlight
 GET /api/dcim/devices/?tag=monitored&tag=deprecated
 ```
-
-!!! note
-    Tags have changed substantially in NetBox v2.9. They are no longer created on-demand when editing an object, and their representation in the REST API now includes a complete depiction of the tag rather than only its label.

docs/models/extras/webhook.md

@@ -0,0 +1,83 @@
+# 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.
+
+!!! warning
+    Webhooks support the inclusion of user-submitted code to generate custom headers and payloads, which may pose security risks under certain conditions. Only grant permission to create or modify webhooks to trusted users.
+
+## Configuration
+
+* **Name** - A unique name for the webhook. The name is not included with outbound messages.
+* **Object type(s)** - The type or types of NetBox object that will trigger the webhook.
+* **Enabled** - If unchecked, the webhook will be inactive.
+* **Events** - A webhook may trigger on any combination of create, update, and delete events. At least one event type must be selected.
+* **HTTP method** - The type of HTTP request to send. Options include `GET`, `POST`, `PUT`, `PATCH`, and `DELETE`.
+* **URL** - The fuly-qualified URL of the request to be sent. This may specify a destination port number if needed.
+* **HTTP content type** - The value of the request's `Content-Type` header. (Defaults to `application/json`)
+* **Additional headers** - Any additional headers to include with the request (optional). Add one header per line in the format `Name: Value`. Jinja2 templating is supported for this field (see below).
+* **Body template** - The content of the request being sent (optional). Jinja2 templating is supported for this field (see below). If blank, NetBox will populate the request body with a raw dump of the webhook context. (If the HTTP cotent type is set to `application/json`, this will be formatted as a JSON object.)
+* **Secret** - A secret string used to prove authenticity of the request (optional). This will append a `X-Hook-Signature` header to the request, consisting of a HMAC (SHA-512) hex digest of the request body using the secret as the key.
+* **Conditions** - An optional set of conditions evaluated to determine whether the webhook fires for a given object.
+* **SSL verification** - Uncheck this option to disable validation of the receiver's SSL certificate. (Disable with caution!)
+* **CA file path** - The file path to a particular certificate authority (CA) file to use when validating the receiver's SSL certificate (optional).
+
+## Jinja2 Template Support
+
+[Jinja2 templating](https://jinja.palletsprojects.com/) is supported for the `additional_headers` and `body_template` fields. This enables the user to convey object data in the request headers as well as to craft a customized request body. Request content can be crafted to enable the direct interaction with external systems by ensuring the outgoing message is in a format the receiver expects and understands.
+
+For example, you might create a NetBox webhook to [trigger a Slack message](https://api.slack.com/messaging/webhooks) any time an IP address is created. You can accomplish this using the following configuration:
+
+* Object type: IPAM > IP address
+* HTTP method: `POST`
+* URL: Slack incoming webhook URL
+* HTTP content type: `application/json`
+* Body template: `{"text": "IP address {{ data['address'] }} was created by {{ username }}!"}`
+
+### Available Context
+
+The following data is available as context for Jinja2 templates:
+
+* `event` - The type of event which triggered the webhook: created, updated, or deleted.
+* `model` - The NetBox model which triggered the change.
+* `timestamp` - The time at which the event occurred (in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) format).
+* `username` - The name of the user account associated with the change.
+* `request_id` - The unique request ID. This may be used to correlate multiple changes associated with a single request.
+* `data` - A detailed representation of the object in its current state. This is typically equivalent to the model's representation in NetBox's REST API.
+* `snapshots` - Minimal "snapshots" of the object state both before and after the change was made; provided ass a dictionary with keys named `prechange` and `postchange`. These are not as extensive as the fully serialized representation, but contain enough information to convey what has changed.
+
+### Default Request Body
+
+If no body template is specified, the request body will be populated with a JSON object containing the context data. For example, a newly created site might appear as follows:
+
+```json
+{
+    "event": "created",
+    "timestamp": "2021-03-09 17:55:33.968016+00:00",
+    "model": "site",
+    "username": "jstretch",
+    "request_id": "fdbca812-3142-4783-b364-2e2bd5c16c6a",
+    "data": {
+        "id": 19,
+        "name": "Site 1",
+        "slug": "site-1",
+        "status": 
+            "value": "active",
+            "label": "Active",
+            "id": 1
+        },
+        "region": null,
+        ...
+    },
+    "snapshots": {
+        "prechange": null,
+        "postchange": {
+            "created": "2021-03-09",
+            "last_updated": "2021-03-09T17:55:33.851Z",
+            "name": "Site 1",
+            "slug": "site-1",
+            "status": "active",
+            ...
+        }
+    }
+}
+```

docs/models/ipam/asn.md

@@ -0,0 +1,15 @@
+# ASN
+
+ASN is short for Autonomous System Number.  This identifier is used in the BGP protocol to identify which "autonomous system" a particular prefix is originating and transiting through.
+
+The AS number model within NetBox allows you to model some of this real-world relationship.
+
+Within NetBox:
+
+* AS numbers are globally unique
+* Each AS number must be associated with a RIR (ARIN, RFC 6996, etc)
+* Each AS number can be associated with many different sites
+* Each site can have many different AS numbers
+* Each AS number can be assigned to a single tenant
+
+

docs/models/ipam/fhrpgroup.md

@@ -0,0 +1,16 @@
+# FHRP Group
+
+A first-hop redundancy protocol (FHRP) enables multiple physical interfaces to present a virtual IP address in a redundant manner. Example of such protocols include:
+
+* Hot Standby Router Protocol (HSRP)
+* Virtual Router Redundancy Protocol (VRRP)
+* Common Address Redundancy Protocol (CARP)
+* Gateway Load Balancing Protocol (GLBP)
+
+NetBox models these redundancy groups by protocol and group ID. Each group may optionally be assigned an authentication type and key. (Note that the authentication key is stored as a plaintext value in NetBox.) Each group may be assigned or more virtual IPv4 and/or IPv6 addresses.
+
+## FHRP Group Assignments
+
+Member device and VM interfaces can be assigned to FHRP groups, along with a numeric priority value. For instance, three interfaces, each belonging to a different router, may each be assigned to the same FHRP group to serve a common virtual IP address. Each of these assignments would typically receive a different priority.
+
+Interfaces are assigned to FHRP groups under the interface detail view.

docs/models/ipam/iprange.md

@@ -0,0 +1,14 @@
+# IP Ranges
+
+This model represents an arbitrary range of individual IPv4 or IPv6 addresses, inclusive of its starting and ending addresses. For instance, the range 192.0.2.10 to 192.0.2.20 has eleven members. (The total member count is available as the `size` property on an IPRange instance.) Like prefixes and IP addresses, each IP range may optionally be assigned to a VRF and/or tenant.
+
+IP also ranges share the same functional roles as prefixes and VLANs, although the assignment of a role is optional. Each IP range must be assigned an operational status, which is one of the following:
+
+* Active - Provisioned and in use
+* Reserved - Designated for future use
+* Deprecated - No longer in use
+
+The status of a range does _not_ have any impact on its member IP addresses, which may have their statuses modified separately.
+
+!!! note
+    The maximum supported size of an IP range is 2^32 - 1.

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/models/tenancy/contact.md

@@ -0,0 +1,31 @@
+# Contacts
+
+A contact represent an individual or group that has been associated with an object in NetBox for administrative reasons. For example, you might assign one or more operational contacts to each site. Contacts can be arranged within nested contact groups.
+
+Each contact must include a name, which is unique to its parent group (if any). The following optional descriptors are also available:
+
+* Title
+* Phone
+* Email
+* Address
+
+## Contact Assignment
+
+Each contact can be assigned to one or more objects, allowing for the efficient reuse of contact information. When assigning a contact to an object, the user may optionally specify a role and/or priority (primary, secondary, tertiary, or inactive) to better convey the nature of the contact's relationship to the assigned object.
+
+The following models support the assignment of contacts:
+
+* circuits.Circuit
+* circuits.Provider
+* dcim.Device
+* dcim.Location
+* dcim.Manufacturer
+* dcim.PowerPanel
+* dcim.Rack
+* dcim.Region
+* dcim.Site
+* dcim.SiteGroup
+* tenancy.Tenant
+* virtualization.Cluster
+* virtualization.ClusterGroup
+* virtualization.VirtualMachine