netbox-community · jeremystretch · Sep 20, 2021 · Aug 27, 2021 · Feb 8, 2021 · Sep 8, 2021
diff --git a/.gitattributes b/.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
-*.min.* binary
-*.map binary
-*.pack.js binary
+# Treat compiled JS/CSS files as binary, as they're not meant to be human-readable
+netbox/project-static/dist/*.css binary
+netbox/project-static/dist/*.js binary
+netbox/project-static/dist/*.js.map binary
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yaml b/.github/ISSUE_TEMPLATE/bug_report.yaml
@@ -17,7 +17,7 @@ body:
         What version of NetBox are you currently running? (If you don't have access to the most
         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: v3.0.2
+      placeholder: v3.0.3
     validations:
       required: true
   - type: dropdown

diff --git a/.github/ISSUE_TEMPLATE/feature_request.yaml b/.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: v3.0.2
+      placeholder: v3.0.3
     validations:
       required: true
   - type: dropdown

diff --git a/docs/administration/permissions.md b/docs/administration/permissions.md
@@ -2,7 +2,7 @@
 
 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.
 
-{!docs/models/users/objectpermission.md!}
+{!models/users/objectpermission.md!}
 
 ### Example Constraint Definitions
 

diff --git a/docs/administration/replicating-netbox.md b/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
-```
diff --git a/docs/configuration/optional-settings.md b/docs/configuration/optional-settings.md
@@ -490,6 +490,14 @@ NetBox can be configured to support remote user authentication by inferring user
 
 ---
 
+## 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'`
@@ -498,6 +506,54 @@ When remote user authentication is in use, this is the name of the HTTP header w
 
 ---
 
+## 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` )
+
+---
+
 ## RELEASE_CHECK_URL
 
 Default: None (disabled)

diff --git a/docs/core-functionality/circuits.md b/docs/core-functionality/circuits.md
@@ -1,10 +1,10 @@
 # Circuits
 
-{!docs/models/circuits/provider.md!}
-{!docs/models/circuits/providernetwork.md!}
+{!models/circuits/provider.md!}
+{!models/circuits/providernetwork.md!}
 
 ---
 
-{!docs/models/circuits/circuit.md!}
-{!docs/models/circuits/circuittype.md!}
-{!docs/models/circuits/circuittermination.md!}
+{!models/circuits/circuit.md!}
+{!models/circuits/circuittype.md!}
+{!models/circuits/circuittermination.md!}
diff --git a/docs/core-functionality/device-types.md b/docs/core-functionality/device-types.md
@@ -1,7 +1,7 @@
 # Device Types
 
-{!docs/models/dcim/devicetype.md!}
-{!docs/models/dcim/manufacturer.md!}
+{!models/dcim/devicetype.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!}
-{!docs/models/dcim/consoleserverporttemplate.md!}
-{!docs/models/dcim/powerporttemplate.md!}
-{!docs/models/dcim/poweroutlettemplate.md!}
-{!docs/models/dcim/interfacetemplate.md!}
-{!docs/models/dcim/frontporttemplate.md!}
-{!docs/models/dcim/rearporttemplate.md!}
-{!docs/models/dcim/devicebaytemplate.md!}
+{!models/dcim/consoleporttemplate.md!}
+{!models/dcim/consoleserverporttemplate.md!}
+{!models/dcim/powerporttemplate.md!}
+{!models/dcim/poweroutlettemplate.md!}
+{!models/dcim/interfacetemplate.md!}
+{!models/dcim/frontporttemplate.md!}
+{!models/dcim/rearporttemplate.md!}
+{!models/dcim/devicebaytemplate.md!}
diff --git a/docs/core-functionality/devices.md b/docs/core-functionality/devices.md
@@ -1,29 +1,29 @@
 # Devices and Cabling
 
-{!docs/models/dcim/device.md!}
-{!docs/models/dcim/devicerole.md!}
-{!docs/models/dcim/platform.md!}
+{!models/dcim/device.md!}
+{!models/dcim/devicerole.md!}
+{!models/dcim/platform.md!}
 
 ---
 
 ## Device Components
 
 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!}
-{!docs/models/dcim/consoleserverport.md!}
-{!docs/models/dcim/powerport.md!}
-{!docs/models/dcim/poweroutlet.md!}
-{!docs/models/dcim/interface.md!}
-{!docs/models/dcim/frontport.md!}
-{!docs/models/dcim/rearport.md!}
-{!docs/models/dcim/devicebay.md!}
-{!docs/models/dcim/inventoryitem.md!}
+{!models/dcim/consoleport.md!}
+{!models/dcim/consoleserverport.md!}
+{!models/dcim/powerport.md!}
+{!models/dcim/poweroutlet.md!}
+{!models/dcim/interface.md!}
+{!models/dcim/frontport.md!}
+{!models/dcim/rearport.md!}
+{!models/dcim/devicebay.md!}
+{!models/dcim/inventoryitem.md!}
 
 ---
 
-{!docs/models/dcim/virtualchassis.md!}
+{!models/dcim/virtualchassis.md!}
 
 ---
 
-{!docs/models/dcim/cable.md!}
+{!models/dcim/cable.md!}
diff --git a/docs/core-functionality/ipam.md b/docs/core-functionality/ipam.md
@@ -1,19 +1,19 @@
 # IP Address Management
 
-{!docs/models/ipam/aggregate.md!}
-{!docs/models/ipam/rir.md!}
+{!models/ipam/aggregate.md!}
+{!models/ipam/rir.md!}
 
 ---
 
-{!docs/models/ipam/prefix.md!}
-{!docs/models/ipam/role.md!}
+{!models/ipam/prefix.md!}
+{!models/ipam/role.md!}
 
 ---
 
-{!docs/models/ipam/iprange.md!}
-{!docs/models/ipam/ipaddress.md!}
+{!models/ipam/iprange.md!}
+{!models/ipam/ipaddress.md!}
 
 ---
 
-{!docs/models/ipam/vrf.md!}
-{!docs/models/ipam/routetarget.md!}
+{!models/ipam/vrf.md!}
+{!models/ipam/routetarget.md!}
diff --git a/docs/core-functionality/power.md b/docs/core-functionality/power.md
@@ -1,8 +1,8 @@
 # Power Tracking
 
-{!docs/models/dcim/powerpanel.md!}
-{!docs/models/dcim/powerfeed.md!}
+{!models/dcim/powerpanel.md!}
+{!models/dcim/powerfeed.md!}
 
 # Example Power Topology
 
-![Power distribution model](../../media/power_distribution.png)
+![Power distribution model](/media/power_distribution.png)
diff --git a/docs/core-functionality/services.md b/docs/core-functionality/services.md
@@ -1,3 +1,3 @@
 # Service Mapping
 
-{!docs/models/ipam/service.md!}
+{!models/ipam/service.md!}
diff --git a/docs/core-functionality/sites-and-racks.md b/docs/core-functionality/sites-and-racks.md
@@ -1,12 +1,12 @@
 # Sites and Racks
 
-{!docs/models/dcim/region.md!}
-{!docs/models/dcim/sitegroup.md!}
-{!docs/models/dcim/site.md!}
-{!docs/models/dcim/location.md!}
+{!models/dcim/region.md!}
+{!models/dcim/sitegroup.md!}
+{!models/dcim/site.md!}
+{!models/dcim/location.md!}
 
 ---
 
-{!docs/models/dcim/rack.md!}
-{!docs/models/dcim/rackrole.md!}
-{!docs/models/dcim/rackreservation.md!}
+{!models/dcim/rack.md!}
+{!models/dcim/rackrole.md!}
+{!models/dcim/rackreservation.md!}
diff --git a/docs/core-functionality/tenancy.md b/docs/core-functionality/tenancy.md
@@ -1,4 +1,4 @@
 # Tenancy Assignment
 
-{!docs/models/tenancy/tenant.md!}
-{!docs/models/tenancy/tenantgroup.md!}
+{!models/tenancy/tenant.md!}
+{!models/tenancy/tenantgroup.md!}
diff --git a/docs/core-functionality/virtualization.md b/docs/core-functionality/virtualization.md
@@ -1,10 +1,10 @@
 # Virtualization
 
-{!docs/models/virtualization/cluster.md!}
-{!docs/models/virtualization/clustertype.md!}
-{!docs/models/virtualization/clustergroup.md!}
+{!models/virtualization/cluster.md!}
+{!models/virtualization/clustertype.md!}
+{!models/virtualization/clustergroup.md!}
 
 ---
 
-{!docs/models/virtualization/virtualmachine.md!}
-{!docs/models/virtualization/vminterface.md!}
+{!models/virtualization/virtualmachine.md!}
+{!models/virtualization/vminterface.md!}
diff --git a/docs/core-functionality/vlans.md b/docs/core-functionality/vlans.md
@@ -1,4 +1,4 @@
 # VLAN Management
 
-{!docs/models/ipam/vlan.md!}
-{!docs/models/ipam/vlangroup.md!}
+{!models/ipam/vlan.md!}
+{!models/ipam/vlangroup.md!}
diff --git a/docs/customization/custom-scripts.md b/docs/customization/custom-scripts.md
@@ -226,7 +226,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
 

diff --git a/docs/customization/reports.md b/docs/customization/reports.md
@@ -104,7 +104,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
 

diff --git a/docs/graphql-api/overview.md b/docs/graphql-api/overview.md
@@ -11,7 +11,7 @@ curl -H "Authorization: Token $TOKEN" \
 -H "Content-Type: application/json" \
 -H "Accept: application/json" \
 http://netbox/graphql/ \
---data '{"query": "query {circuits(status:\"active\" {cid provider {name}}}"}'
+--data '{"query": "query {circuit_list(status:\"active\") {cid provider {name}}}"}'
 ```
 
 The response will include the requested data formatted as JSON:
@@ -54,7 +54,7 @@ For more detail on constructing GraphQL queries, see the [Graphene documentation
 The GraphQL API employs the same filtering logic as the UI and REST API. Filters can be specified as key-value pairs within parentheses immediately following the query name. For example, the following will return only sites within the North Carolina region with a status of active:
 
 ```
-{"query": "query {sites(region:\"north-carolina\", status:\"active\") {name}}"}
+{"query": "query {site_list(region:\"north-carolina\", status:\"active\") {name}}"}
 ```
 
 ## Authentication

diff --git a/docs/index.md b/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
 

diff --git a/docs/installation/index.md b/docs/installation/index.md
@@ -13,7 +13,7 @@ The following sections detail how to set up a new instance of NetBox:
 
 The video below demonstrates the installation of NetBox v2.10.3 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
 

diff --git a/docs/models/dcim/cable.md b/docs/models/dcim/cable.md
@@ -25,7 +25,7 @@ A cable may be traced from either of its endpoints by clicking the "trace" butto
 
 In the example below, three individual cables comprise a path between devices A and D:
 
-![Cable path](../../media/models/dcim_cable_trace.png)
+![Cable path](/media/models/dcim_cable_trace.png)
 
 Traced from Interface 1 on Device A, NetBox will show the following path: