diff --git a/docs/administration/role-based-access-control/index.md b/docs/administration/role-based-access-control/index.md
index b972409d..990822f3 100644
--- a/docs/administration/role-based-access-control/index.md
+++ b/docs/administration/role-based-access-control/index.md
@@ -2,168 +2,281 @@
title: "Role-Based Access Control"
---
-### Role-Based Access Control Overview
+import ThemedImage from "@theme/ThemedImage";
+import useBaseUrl from "@docusaurus/useBaseUrl";
-Device42 supports a number of role-based access use cases. A corporation might want to restrict access by geographic location, department, division, corporate entity, and so on. More importantly, they might want a user to have access to just one department while another user has access to all departments within a division.
-Similarly, a service provider might to allocate subnets to customers or racks to customers. The role-based access feature enables the service provider to restrict customer access to the specific subnets and racks assigned to the customer where the service provider can see all subnets and racks.
+## Role-Based Access Control Overview
-### Setting Up Role-Based Access
+Device42 supports role-based access control, which is useful in several cases. A corporation might want to restrict access by location, department, division, and corporate entity. For example, you might want a user to access only one department while another user has access to all departments within a division.
-To set up role-based access in Device42, navigate to _Tools > Settings > Global Settings_, and click _Edit_ at the top right of the page.
+Or you as a service provider might allocate subnets or racks to customers. The role-based access feature enables you to restrict customer access to specific subnets and racks.
-
+## Setting Up Role-Based Access
-The two Role-Based Access Control options are:
+To set up role-based access in Device42, navigate to **Tools > Settings > Global Settings**, and click **Edit** at the top right of the page.
-- **Role-Based Access Control Option – Off:** _This is the default._ Do not change this option unless you want to enable role-based access.
-- **Role-Based Access Control Option – On:** Choose this option to enable role-based access.
+
-The other three _orphaned objects_ options are explained below.
+You can toggle the **Role-Based Access Control Option** options:
-Click _Save_ at the bottom of the Global Settings page to save your selections.
+- **On:** Choose this option to enable role-based access.
+- **Off:** _This is the default._ Turns off role-based access.
-### Functional vs. Object Permissions
+See the [Orphaned Objects](#orphaned-objects) section for details about the three checkbox options.
-If role-based access is not enabled, admin groups are granted only "Functional Permissions". These functional permissions define which menu items can be seen by users assigned to the group.
+Click **Save** at the bottom of the Global Settings page to save your selections.
-
+## Viewing Role-Based Access Permissions
-When role-based access is initially turned on, superusers will still have access to all objects (i.e. buildings, rooms, racks, ...) in the system. However, non-superusers will not see any objects whatsoever until they are granted permission to see those objects so long as none of the 'allow orphaned objects' checkboxes shown in the top screenshot are selected. See the section below on 'orphaned objects' for a more complete explanation.
+In the view page for every object with permissions, there is a view-only field named “Group Permissions”:
-
+
-When role-based access is enabled, users will only be able to see a device, asset, or pdu if an Object Category is assigned to that device, asset, or pdu and the user is granted access to that Object Category as shown above.
+The “Group Permissions” field tells you what groups are assigned to this device based on:
+- any groups assigned via device categories
+- groups assigned via buildings, rooms, or racks containing the device
+- VMs and blade chassis containing the device
-
+The group view and edit screens for admin groups have three additional buttons:
-Object Categories can be found on the Datacenter menu. As shown above, to create an object category, you enter a Name and an optional description.
+
-Admin groups, in turn, can be assigned to each object category and the category is granted view-only or change permission. In the above example, two admin groups, Prod and 760 Chapel St have been granted change permission to the Prod -- Change object category. This means that any user who has been assigned to either of the two groups has permission to modify any device, asset, or PDU that has been assigned the Prod -- Change object category.
+The **Direct Permissions** option shows a list of all objects that have been directly assigned to the group. If the group has been assigned to a specific device, the device will appear in the report. If the group has been assigned a building, devices in the building that do not have a direct group assignment will not be shown even though these devices inherit permissions from the building.
-In the initial release of the role-based access feature, the admin groups were assigned directly to devices, assets, and PDUs. However, customers told us that, because of the vast number of devices, assets, and PDUs, this was just too much work. This is why we introduced Object Categories.
+
-For other objects that aren't as numerous as devices and assets (e.g. buildings, rooms, racks, customers, purchases, and object categories themselves), object permissions are still created by assigning admin groups directly to these types of objects as shown in the object categories assignment above.
+If you click the **Inherited Permissions** button, you'll see only the inherited permissions. The **All Permissions** button shows both the direct and inherited permissions for objects for this group.
-Many customers won't need to use Object Categories at all for devices, assets, and PDUs. Instead, you can simply assign admin groups to buildings, rooms, and racks. If an admin group has permission to a building, they have permission to every object in that building (i.e. every room, rack, device, PDU, asset). If an admin group has permission to a room, they have permission to every object in that room (i.e. every rack, device, PDU, asset).
+The list pages for permissioned objects have two useful types of filters:
+- filter by an admin group to see all the objects that the group can view
+- filter by an object or subnet category to see all objects that can be seen by groups with view permissions for the category.
-### Do Not Propagate Option
+## Do Not Propagate Option
-
+
-The _"Do Not Propagate"_ option (pictured above) can be set on Buildings, Rooms, and Racks to stop automatic permission propagation. If you'd prefer that inheritance rules are not applied to a specific building, room, or rack, you can check the _'Do not propagate...'_ link shown above for a rack. In the above example, devices, assets, and pdu in rack NHCTDC1R2 will be visible to anyone who can see the rack. This is useful, for example, for a colocation operator who wants to split a rack among different customers. In the rack layout view, a customer with permission to see the rack and some devices in the rack but not others will see a grayed out rack with no information for those devices, assets, and PDUs they are not allowed to see.
+The **Do Not Propagate** option can be set on buildings, rooms, and racks to stop automatic permission propagation. If you'd prefer that inheritance rules are not applied to a specific building, room, or rack, check the **Do not propagate rack permissions** option.
-### Subnet Categories
+In the above example, devices, assets, and PDU in rack NH-CT-88 will be visible to anyone with permission to see the rack. This is useful for a co-location operator who wants to split a rack among different customers. In the rack layout view, a customer with permission to see specific racks and their devices, but not others, will see a grayed-out rack with no information about the devices, assets, and PDUs they are not authorized to view.
-Subnet Categories work on subnets exactly like Object Categories work on devices, assets, and PDUs. You create Subnet Categories from the IPAM menus and assign admin groups to subnet categories just like you do for object categories. Then the subnet categories and their admin group assignments determine which subnets (and which IPs in those subnet) are visible and changeable for a given user.
+## Functional vs. Object Permissions
-As with object categories, it's not necessary to assign a subnet category to every subnet. If a group is assigned to a VRF Group, then every subnet in that VRF Group will inherit the permissions of the VRF Group. Also, if a subnet is assigned a subnet category, then every child subnet of that subnet will also acquire the permissions granted by the subnet category.
+If role-based access is turned off, admin groups are granted 'functional permissions' that define the menu items that can be seen by users assigned to a group.
-### Assigning Object Permissions to Admin Groups
+
-Object permissions are applicable to the following objects: - Buildings - Rooms - Racks - Devices - Assets - Object Categories - PDUs - VRF Groups - Subnet Categories - Purchases - Vendors - Customers - Auto Discovery jobs
+When role-based access is initially turned on, superusers will still have access to all objects (buildings, rooms, and racks) in the system. However, non-superusers will not see any objects whatsoever if none of the 'allow orphaned objects' checkboxes are selected. Non-superusers will need to be given permission to see the objects again.
-Object assignments are made either from the list view of the object or the edit page of a specific object. It is also possible to assign object permissions to discovered objects of auto discovery jobs.
+### Object Category Field
-
+
-In the example above, we are about to assign 4 racks to an object permission group. If you click the "Add/Delete Object Permission Group" action and then click "Go", you will see...
+When role-based access is enabled, users will only be able to see a device, asset, or PDU if an Object Category is assigned to that device, asset, or PDU and the user is granted access to that Object Category.
-
+### Add or Edit Object Category
-Here we are about to assign permission to the 4 racks listed above the the IT Managers admin group. If you click "Add, you will give the IT Managers group the right to view and edit these 4 racks. If you do not check the Change Permission box, then the permission will be view only.
+Initially, admin groups were assigned directly to devices, assets, and PDUs. However, because of the vast number of devices, assets, and PDUs, Object Categories were introduced.
-This dialog is also used to remove previously assign permissions. So, if you wanted to delete the IT Manager's permissions for these 4 racks, you would click the "Delete" button. You can also modify the Change Permission flag through this dialog as well.
+Object Categories are located under **Infrastructure > Organization > Object Categories**. To create an object category, you enter a **Name** and an optional **Description**.
-You can also assign permissions from object edit pages as shown above.
+
-The Add/Delete Groups action is available for the following objects: - Buildings - Rooms - Racks - VRF Groups
+Admin groups can be assigned to each Object Category to grant view-only or change permission. In the above example, the "Prod" admin group has change permission on the "Development Machines" object category. Any user who has been assigned to "Prod" has permission to modify any device, asset, or PDU that has been assigned the "Development Machines" object category.
-Similarly, the Device, Asset, and PDU list pages offer Set Object Category and a Delete Object Category actions. The Subnet list page offers Set Subnet Category and a Delete Subnet Category actions.
+For objects that aren't as numerous as devices and assets, object permissions are still created by assigning admin groups directly to these types of objects. These object types include buildings, rooms, racks, customers, purchases, and object categories themselves.
-### Permission Hierarchies
+Many users won't need to use Object Categories for devices, assets, and PDUs. Instead, you can simply assign admin groups to buildings, rooms, and racks. If an admin group has permission to a building, they have permission to every object in that building (like every room, rack, device, PDU, and asset). If an admin group has permission to a room, they have permission to every object in that room (that is, every rack, device, PDU, and asset).
-As mentioned above, if an admin group is granted access to a building, the admin group is implicitly granted access to all rooms, racks, devices, pdus, and assets in the building. We call the hierarchy that contains buildings the Device Hierarchy. The rules for the Device Hierarchy are as follows:
+## Subnet Categories
-- Permission for a building implies permission for all rooms, racks, devices, pdus, and assets in the building.
-- Permission for a room implies permission for all racks, devices, pdus, and assets in the room.
-- Permission for a rack implies permission for all devices, pdus, and assets in the rack (unless the "Do not propagate" box is checked for the rack).
-- Permission for a blade chassis implies permission for all blade devices in the chassis.
-- Permission for a virtual host implies permission for all virtual machines in the host.
-- Permission for a device that is part of a cluster _does not_ imply permission to the cluster device itself. Additionally, as a cluster can be made up of devices that reside in multiple physical locations, a cluster device can not and does not have a location attribute, meaning permissions for those using multi-tenancy will be inherited for cluster member devices, but will not be inherited for the cluster device itself. The only way to create permissions on a cluster object is to assign an object category to the cluster device.
+Subnet Categories work on subnets exactly like Object Categories work on devices, assets, and PDUs. Create Subnet Categories from the **Resources > Network > Subnet Categories** and assign admin groups to subnet categories just like you do for object categories. Then the subnet categories and their admin group assignments determine which subnets, and which IPs in those subnets, are visible and changeable for a given user.
-Also as mentioned above, there is a second hierarchy that we call the IP Hierarchy. The rules for the IP Hierarchy are as follows:
+As with Object Categories, it's not necessary to assign a subnet category to every subnet. If a group is assigned to a VRF Group, then every subnet in that VRF Group will inherit the permissions of the VRF Group. Also, if a subnet is assigned a subnet category, then every child subnet of that subnet will also have the permissions granted by the subnet category.
-- Permission for a vrf group implies permission for all subnets and IP addresses within the vrf group.
-- Permission for a subnet category implies permission for all subnets labeled with that subnet category, all child subnets of those subnets and all IP addresses within all those subnets.
-- Permission for a parent subnet implies permission for all child subnets (e.g. permission for a /20 subnet implies permission for a /24 subnet).
+## Assigning Object Permissions to Admin Groups
-Please note that change permission for an object also applies to the objects beneath it in the hierarchy. For example, if you have change permission for a subnet, you can change any IPs in the subnet and you can add IPs (or child subnets) to the subnet. However, if you have view-only access to the subnet (i.e. you do not have change permission), then you can not change any IPs in the subnet and you cannot add IPs to the subnet.
+Object permissions apply to the following objects:
+- Buildings
+- Rooms
+- Racks
+- Devices
+- Assets
+- Object Categories
+- PDUs
+- VRF Groups
+- Subnet Categories
+- Purchases
+- Vendors
+- Customers
+- Auto Discovery jobs
-It is possible to grant view-only permission to a room but change permission to specific devices. This would allow users to change the specific devices but not change the other devices in the room.
+Object assignments are made either from the list view of the object or the edit page of a specific object. It is also possible to assign object permissions to discovered objects of autodiscovery jobs.
-_Lastly, note that there is a special scenario such that an admin group with "change" permission assigned to a building, room, or rack in conjunction with the "Do Not Propagate" (aka DNP) option being selected. In this case, members of the Admin Group in question will end up with a "View Only" user experience, as the "change" permission's propagation in this scenario is blocked by the DNP option._
+
-### Objects that Do Not Have Explicit Permissioning
+In the example above, we assign three racks to an object permission group. If you click the "Add Groups" action and then click the **hammer icon**, you will see a confirmation page:
-Certain objects are subject to permissioning even though admin groups are not directly granted these permissions.
+
-- Parts are viewable and/or editable if they are assigned to a device, room, or storage rack that is viewable or editable.
-- UCS Service Profiles are viewable and/or editable if they are assigned to a device that is viewable or editable.
-- Software components are viewable by all. However, software details are viewable or editable if the software component is in use by a device or end user is viewable or editable.
-- Services are viewable by all. However, service details are viewable or editable if the service is in use by a device or end user is viewable or editable.
-- Application components are viewable or editable only if they are attached to a service that is viewable or editable.
-- Mac addresses are viewable or editable if they are attached to a device that is viewable or editable.
+Here we are about to assign permission to the three racks listed above the "Prod" admin group. If you click **Add group for selected objects**, you will give the "Prod" group the right to view and edit the selected racks. Leaving the **Change Permissions?** box unchecked means only granting view permission.
-### What Happens If an Admin Group Has No Permissions?
+Remove previously assigned permissions with the **Delete Groups** action. If you want to delete the "Prod" group's permissions for these racks, select that option. You can change the **Change Permissions?** flag through this dialog as well.
-The Device42 role-based access system is set up so that if an admin group is assigned no object permissions and no object or subnet categories, then users in that admin group will not be able to see any objects (unless 'orphaned objects' are allowed -- see below). As discussed above, if an admin group has access to only one room (and 'do not propagate' is unchecked) then users in the admin group will have access to that room and any racks, devices, pdus, and assets inside the room. However, if the admin group has not been granted access to any subnets, then the users will not be see any subnets or ips in their list pages.
+You can also assign permissions from object edit pages as shown above.
-Note: Under certain circumstances, it is possible to see the name of an object without permission. For example, a user with access to a device will see the IP address of the device even if they don't have permission to see the subnet the IP address resides in. However, when they click on the IP address, they will get a permission error.
+The **Add Groups** and **Delete Groups** actions are available for the following objects:
+- Buildings
+- Rooms
+- Racks
+- VRF Groups
-The following objects and/or screens do not have object-level permission and are governed only by admin group functional permissions: - Hardware models, pdu models, patch panel models, tap module models, parts models, and similar objects - QR, Device Names, and Asset Number Profiles - Telecom and Power circuits - DNS - OS’s - Passwords (also have their own user/group security) - Lifecycle Event Actions - Misc Functions - Custom Field setup - Monitoring appliances - Org units - Settings - Tags
+Similarly, the device, asset, and PDU list pages have **Set Object Category** and **Delete Object Category** actions. The Subnet list page has **Set Subnet Category** and **Delete Subnet Category** actions.
-### Viewing Role-Based Access Permissions
+## Who Can Assign Admin Groups to Objects?
-For your convenience, in the view page for every object with permissions, there is a view-only field named “Group Permissions” (see the example above for Physical Device NTCTCORE01). This field tells you what groups are assigned to this device taking into account any groups assigned via device categories (see below) and taking into accounts groups assigned via buildings, rooms, or racks that contain the device and take into account VMs and blade chassis that contain the device
+Superusers are allowed to add, change, and delete groups for objects through the UI, import spreadsheets, or the API. Superusers can also enable non-superusers to have this ability by assigning them add, change, and delete capabilities for "Object Permissions".
-Also, the group view and edit screens for admin groups will have 3 extra buttons (circled in red below):
+
-
+When you turn on role-based access, you will need to go to each admin group and check if they have the object permissions you want. If you give a group add, change, or delete permission, then all users assigned to that group (including non-superusers) will have the ability to add, change, or delete object permissions through the UI, imports, and APIs.
-The Direct Permissions button will show a list of all objects that have been directly assigned to the group. If the group has been assigned to a specific device, the device will appear in the report. If the group has been assigned a building, devices in the building that do not have a direct group assignment will not be shown even though these devices "inherit" permissions from the building. An example is shown below...
-
+## Objects that Do Not Have Explicit Permissions
-If you click the "All Permissions" button, you will see both direct and inherited permissions for objects for this group. If you click the "Inherited Permissions" button, you will see just the inherited permissions.
+Certain objects are subject to permissions even though admin groups are not directly granted these permissions.
-Last, but often the most useful, list pages for permissioned objects have two types of filters. First, you can filter by an admin group to see all the objects that group can view. Second, you can filter by an Object or Subnet Category to see all objects that can be seen by groups with view permissions for the category.
+- Parts are viewable or editable if they are assigned to a device, room, or storage rack that is viewable or editable.
+- UCS Service Profiles are viewable or editable if they are assigned to a device that is viewable or editable.
+- Software components are viewable by all. However, software details are viewable or editable if the software component is in use by a device or end-user is viewable or editable.
+- Services are viewable by all. However, service details are viewable or editable if the service is in use by a device or end-user is viewable or editable.
+- Application components are viewable or editable only if they are attached to a service that is viewable or editable.
+- MAC addresses are viewable or editable if they are attached to a device that is viewable or editable.
-### Autodiscovery Jobs
+## What Happens If an Admin Group Has No Permissions?
-When you create or modify an autodiscovery job, you can assign an admin group to the autodiscovery job. This governs which users can can view and/or modify the autodiscovery job. You can also add groups in bulk to multiple jobs from the list view.
+The Device42 role-based access system is set up so that if an admin group is assigned no object permissions and no object or subnet categories, then users in that admin group will not be able to see any objects (unless [Orphaned Objects](#orphaned-objects) are allowed).
-Within many of the autodiscovery jobs, you can also assign an object category and/or a subnet category. The object category will then be assigned to any devices, assets, or pdus discovered. The subnet category will be assigned to any discovered subnets.
+As discussed above, if an admin group has access to only one room (and **do not propagate** is unchecked) then users in the admin group will have access to that room and any racks, devices, PDUs, and assets inside the room. However, if the admin group has not been granted access to any subnets, then the users will not see any subnets or IPs in their list pages.
-Warning: If you are a non-superuser and you run an autodiscovery without specifying any categories, then you may not be able to view or edit the discovered objects (because you will not have permission to see them!).
+Note: Under certain circumstances, it is possible to see the name of an object without permission. For example, a user with access to a device will see the IP address of the device even if they don't have permission to see the subnet the IP address resides in. However, when they click on the IP address, they will get a permission error.
-### Who Can Assign Admin Groups to Objects?
+The following objects and screens do not have object-level permission and are governed only by admin group functional permissions:
+- Hardware models, PDU models, patch panel models, tap module models, parts models, and similar objects
+- QR, Device Names, and Asset Number Profiles
+- Telecom and Power circuits
+- DNS
+- OS’s
+- Passwords (also have their own user/group security)
+- Lifecycle Event Actions
+- Misc Functions
+- Custom Field setup
+- Monitoring appliances
+- Org units
+- Settings
+- Tags
+
+## Permission Hierarchies
+
+If an admin group is granted access to a building, the admin group is also granted access to all rooms, racks, devices, PDUs, and assets in the building. We call the hierarchy that contains buildings the Device Hierarchy. The rules for the Device Hierarchy are as follows:
+
+- Permission for a building implies permission for all rooms, racks, devices, PDUs, and assets in the building.
+- Permission for a room implies permission for all racks, devices, PDUs, and assets in the room.
+- Permission for a rack implies permission for all devices, PDUs, and assets in the rack (unless the **Do not propagate** box is checked for the rack).
+- Permission for a blade chassis implies permission for all blade devices in the chassis.
+- Permission for a virtual host implies permission for all virtual machines in the host.
+- Permission for a device that is part of a cluster _does not_ imply permission to the cluster device itself. Because a cluster can be made up of devices that reside in multiple physical locations, a cluster device does not have a location attribute. Permissions for those using multi-tenancy will be inherited for cluster member devices, but will not be inherited for the cluster device itself. The only way to create permissions on a cluster object is to assign an object category to the cluster device.
-Superusers are allowed to add, change, delete groups for objects through the UI, import spreadsheets, or the API. Superusers can also enable non-superusers to have this ability by assigning them them add, change, and/or delete capability for "Object Permissions".
+There is a second hierarchy that we call the IP Hierarchy. The rules for the IP Hierarchy are as follows:
-
+- Permission for a VRF group implies permission for all subnets and IP addresses within the VRF group.
+- Permission for a subnet category implies permission for all subnets labeled with that subnet category, all child subnets of those subnets, and all IP addresses within all those subnets.
+- Permission for a parent subnet implies permission for all child subnets (for example, permission for a /20 subnet implies permission for a /24 subnet).
-When you turn on role-based access, you will need to go to each admin group and make sure that each has or does not have the object permissions you want it to have. If you give a group add/change/delete permission, then all users assigned to that group (including non-superusers) will have the ability to add/change/delete object permissions through the UI, imports, and APIs.
+Please note that change permission for an object also applies to the objects beneath it in the hierarchy. For example, if you have change permission for a subnet, you can change any IPs in the subnet and you can add IPs (or child subnets) to the subnet. However, if you have view-only access to the subnet (that is, you do not have change permission), then you can not change any IPs in the subnet and you cannot add IPs to the subnet.
+
+It is possible to grant view-only permission to a room but change permission to specific devices. This would allow users to change the specific devices but not change the other devices in the room.
+
+Note that there is a special scenario when an admin group with change permission is assigned to a building, room, or rack in conjunction with the **"Do Not Propagate** (DNP) option being selected. In this case, members of the admin group will only have view-only permission as the change permission is blocked by the DNP option.
### IPAM Hierarchy Rules
-The Merge and Relocate subnet capabilities are available to any user with change permission to both the to-be-moved subnet and the parent subnet.
+The **Merge and Relocate** subnet capabilities are available to any user with change permission to the to-be-moved subnet and the parent subnet.
-Only superusers can create subnets from the subnet list page. However, non-superusers can create subnet from the subnet tree view.
+Only superusers can create subnets from the subnet list page. However, non-superusers can create a subnet from the subnet tree view.
Only superusers can create parent root subnets. The only exception to this rule is the Ping Sweep Autodiscovery job. If a ping sweep job setup by a non-superuser discovers a root subnet, it will be created.
-If you do have view but not change permission to a device, you can still add an IP address to the device. This is considered by Device42 to be a modification of the IP address not the device.
+If you have view but not change permission to a device, you can still add an IP address to the device. This is considered by Device42 to be a modification of the IP address, not the device.
### Device Hierarchy Rules
@@ -171,21 +284,26 @@ If you give a group change permission to a room, you should also grant view perm
When cloning devices and racks with explicit permissions, those permissions will be copied over to the newly cloned objects. If there are no permissions on a device or rack, it will copy over the next closest parent's object permissions (e.g. if there are no permissions on a device but there are permissions on the rack the device is in, the rack's permissions will be copied over). Also, if a device or rack has multiple groups, only the groups assigned to the current user will be copied over.
-When deleting permissions on an object which has objects below it in the hierarchy (e.g. deleting a building which has rooms, racks, devices, ...), removing the permissions on the building will not cascade the delete down the line. So any rooms within the building that you deleted permissions from will still be available to the group.
+When deleting permissions on an object that has objects below it in the hierarchy (for example, deleting a building that has rooms, racks, and devices), removing the permissions on the building will not cascade the delete down the line. So any rooms within the building that you deleted permissions from will still be available to the group.
+
+## Autodiscovery Jobs
-### Orphaned Objects
+When you create or modify an autodiscovery job, you can assign an admin group to the autodiscovery job. This governs which users can view and modify the autodiscovery job. You can also add groups in bulk to multiple jobs from the list view.
-An “orphaned object” is an object (e.g. a rack or a subnet) that has no group assigned to it directly AND has no group assigned to a “parent object”. To refresh your memory, the parent objects of racks are rooms and buildings and the parent objects of subnets are their parent subnets and vrf groups. Prior to this release, orphaned objects cannot be viewed by any non-superuser.
+For many of the autodiscovery jobs, you can also assign an object category and a subnet category. The object category will then be assigned to any devices, assets, or pdus discovered. The subnet category will be assigned to any discovered subnets.
-Customers have told us that this behavior is overly restrictive. You can maintain this behavior by unchecking the two options above. However, the default will be to leave these unchecked so that orphaned objects are visible to everyone.
+:::caution
+If you are a non-superuser and you run an autodiscovery without specifying any categories, then you may not be able to view or edit the discovered objects because you will not have permission to see them.
+:::
-The “Building hierarchy” option applies to building hierarchy objects, specifically buildings, rooms, racks, devices, assets, and pdus. For example, if this option is checked, a non-super can view and change any building that has no groups assigned to it AND can view and change any room, rack, device, asset or pdu in the building. The “IP hierarchy” option applies to IP addresses and subnets. For example, if this option is checked, a non-super can view and change any subnet that has no groups assigned to it or to a parent subnet.
+## Orphaned Objects
-The “Other objects” option applies to purchases and customers. For example, if this option is checked, a non-super can view and change any purchase that has no groups assigned to it.
+An 'orphaned object' is an object (for example, a rack or a subnet) that has no group assigned to it directly _and_ has no group assigned to a parent object. The parent objects of racks are rooms and buildings and the parent objects of subnets are their parent subnets and VRF groups.
-
+The default is to leave the orphaned objects options unchecked so that orphaned objects are visible to everyone.
+The **Allow non-superusers to see orphaned building hierarchy objects** option applies to building hierarchy objects, specifically buildings, rooms, racks, devices, assets, and PDUs. If this option is checked, a non-superuser can view and change any building that has no groups assigned to it _and_ can view and change any room, rack, device, asset, or PDU in the building.
-## Table of contents
+The **Allow non-superusers to see orphaned IP hierarchy objects** option applies to IP addresses and subnets. If this option is checked, a non-superuser can view and change any subnet that has no groups assigned to it or a parent subnet.
-- [Role-based Permissions and Access](/administration/role-based-access-control/role-based-permissions-and-access.mdx)
\ No newline at end of file
+The **Allow non-superusers to see other orphaned objects** option applies to purchases and customers. If this option is checked, a non-superuser can view and change any purchase that has no groups assigned to it.
diff --git a/docs/getstarted/installation/getting-started-on-a-pc.md b/docs/getstarted/installation/getting-started-on-a-pc.md
index 6dee49ab..a1fea76f 100644
--- a/docs/getstarted/installation/getting-started-on-a-pc.md
+++ b/docs/getstarted/installation/getting-started-on-a-pc.md
@@ -3,69 +3,83 @@ title: "Getting Started on a PC"
sidebar_position: 14
---
-## From the Start - How to Setup Device42 on a PC hypervisor
+import extract from '/assets/images/getting-started-on-a-pc/2extract.PNG'
+
+## From the Start: How to Setup Device42 on a PC Hypervisor
### Prerequisites
-To use Device42 you will need a hypervisor like Virtualbox, VMWare player or VMware Workstation that can manage and run virtual machine images. If you don't already have one, you can download one Virtualbox for free @ [https://www.virtualbox.org](https://www.virtualbox.org), or alternatively, get [VMware Player here](https://customerconnect.vmware.com/en/downloads/free#desktop_end_user_computing/vmware_workstation_player/15_0).
+To use Device42 you will need a hypervisor like Virtualbox, VMWare player, or VMware Workstation that can manage and run virtual machine images. If you don't already have one, you can download one Virtualbox for free from [https://www.virtualbox.org](https://www.virtualbox.org), or get [VMware Player here](https://customerconnect.vmware.com/en/downloads/free#desktop_end_user_computing/vmware_workstation_player/15_0).
-
+
To install VirtualBox, open the downloaded file and double-click the "VirtualBox.pkg" icon, then you can find VirtualBox in your Applications list.
-
-
-**Discovery Account WARNING: Please _do not_ set up an autodiscovery / scan using critical \[production\] account credentials! Please create a separate, dedicated account to use _only_ for discovery**
+:::caution
+Please do not set up an autodiscovery scan using critical production account credentials. Create a separate, dedicated account to use only for discovery.
-_Depending on permissions granted & your configured password policies, account lock-out could result in an otherwise completely avoidable outage. You, the customer, are responsible for any such behavior that might result if you choose to ignore this requirement._
+Depending on the granted permissions and configured password policies, using production account credentials could result in account lockout, leading to an otherwise completely avoidable outage.
+:::
### Installing Device42
-To download Device42, visit [Device42](https://www.device42.com/download/) and enter your name and email address. You will receive a download link in your email momentarily. Once you receive the link, download the VirtualBox version from the options given, as seen in the screenshot below:
+To download Device42, visit [Device42](https://www.device42.com/download/) and enter your name and email address. You will receive a download link in your email momentarily. When you receive the link, download the VirtualBox version from the options given:
+
+
-
+Once downloaded, extract the file contents from the zip file.
-Once the file has downloaded, you can unzip it using 7-Zip, which is a free program available through the App store or from their website, [7-Zip](https://7-zip.org/).
+
-
+From the VirtualBox Manager, click **Import**.
-From VirtualBox, File menu --> Import Appliance. Browse to the .ova / .ovf file you downloaded, and follow the on-screen prompts:
+
-
+Browse to the `.ova` or `.ovf` file you downloaded, and follow the on-screen prompts. Visit [Sizing Recommendations](sizing-recommendations.md) to see the minimum requirements needed to run Device42 smoothly.
-We recommend 2GB of memory at a minimum and suggest 4GB to be sure Device42 runs smoothly.
+
-
+After choosing the hard disk you can follow through with any further default settings.
-After choosing the hard disk you can follow through with any further default settings, but uncheck "Power on after Create" if it is selected.
+
### Additional VM Settings
-Right click on the newly created virtual machine in VirtualBox that appears on the left and choose "Settings". In the window that pops up, select the "System" tab, and then "Processor", and click the checkbox in "Extended Features" to "Enable PAE/NX":
+Right-click on the newly created virtual machine in VirtualBox that appears on the left and choose **Settings**. In the window that pops up, select the **System > Processor** tab and click the **Extended Features:** checkbox to **Enable PAE/NX**.
-
+
-Continuing to the "Network" tab, enable adapter 1 and set it to bridged (note, NAT will also work), and choose the physical NIC/network card you will be using. You can then click OK and close the settings window.
+Continue to the **Network** tab, and confirm that **Adapter 1** is enabled and the "Bridged adapter" or "NAT" option is selected. Then choose the **Name** of the physical NIC or network card you will be using.
-
+
+
+To get rid of an "Invalid settings detected" warning, change the **Display** settings to "VMSVGA":
+
+
### Starting the Virtual Machine
-Once the VM settings have been configured you can power on the virtual appliance. If you receive an audio driver warning you can ignore it. At the login screen, the username is `device42` and the password is `adm!nd42`. Please change these when you first login under option 10.
+When the VM settings have been configured, you can power on the virtual appliance. If you receive an audio driver warning you can ignore it. At the login screen, use the username `device42` and the password `adm!nd42`.
+
+:::info
+Please change the default credentials when you first log in by entering option **10**.
+:::
-
+
-After you are logged in, you can configure your IP settings _(DHCP/Static)_ via Option 1 - **\[Please use a STATIC IP for all production Device42 VMs to avoid connectivity issues\]**
+When you are logged in, enter **1** to configure your IP settings _(DHCP/Static)_. Please use a **static IP** for all production Device42 VMs to avoid connectivity issues.
-
+
-You can apply updates and do other menu-related work using by connecting through ssh using the terminal. Please note that root login has been disabled via ssh. Last, point your browser to the address at the top of the console menu and you’re ready to go…
+You can apply updates and do other menu-related work by connecting via SSH in the terminal. Please note that the `root` login has been disabled via SSH. Lastly, point your browser to the address at the top of the console menu.
You will receive a "Your Connection is not private" warning in your browser as you are accessing a local server that does not have a signed security certificate but it is safe to click "show advanced" in Chrome or "I understand the risks" in Firefox and proceed through to the Device42 login screen:
-At the login screen you can log in using the default name and password: admin/adm!nd42 and you can now start using Device42!
+Log in using the default credentials and start using Device42!
+- Name: `admin`
+- Password: `adm!nd42`
diff --git a/static/assets/images/getting-started-on-a-pc/10-network.PNG b/static/assets/images/getting-started-on-a-pc/10-network.PNG
new file mode 100644
index 00000000..3259028e
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/10-network.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/12-graphics.PNG b/static/assets/images/getting-started-on-a-pc/12-graphics.PNG
new file mode 100644
index 00000000..607c3b91
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/12-graphics.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/14-login.PNG b/static/assets/images/getting-started-on-a-pc/14-login.PNG
new file mode 100644
index 00000000..a65bc278
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/14-login.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/15-logged-in.PNG b/static/assets/images/getting-started-on-a-pc/15-logged-in.PNG
new file mode 100644
index 00000000..903cf202
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/15-logged-in.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/2extract.PNG b/static/assets/images/getting-started-on-a-pc/2extract.PNG
new file mode 100644
index 00000000..89f625c8
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/2extract.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/3-import.PNG b/static/assets/images/getting-started-on-a-pc/3-import.PNG
new file mode 100644
index 00000000..3f232df2
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/3-import.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/4-choose-file.PNG b/static/assets/images/getting-started-on-a-pc/4-choose-file.PNG
new file mode 100644
index 00000000..5ef13b39
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/4-choose-file.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/6-after-import.PNG b/static/assets/images/getting-started-on-a-pc/6-after-import.PNG
new file mode 100644
index 00000000..8aa040bc
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/6-after-import.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/9-cpu-settings.PNG b/static/assets/images/getting-started-on-a-pc/9-cpu-settings.PNG
new file mode 100644
index 00000000..3ba8bf9c
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/9-cpu-settings.PNG differ
diff --git a/static/assets/images/getting-started-on-a-pc/software-download.png b/static/assets/images/getting-started-on-a-pc/software-download.png
new file mode 100644
index 00000000..3131b74b
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/software-download.png differ
diff --git a/static/assets/images/getting-started-on-a-pc/virtualbox-2024.png b/static/assets/images/getting-started-on-a-pc/virtualbox-2024.png
new file mode 100644
index 00000000..818973db
Binary files /dev/null and b/static/assets/images/getting-started-on-a-pc/virtualbox-2024.png differ
diff --git a/static/assets/images/role-based-access-control/add-group-window-dark.png b/static/assets/images/role-based-access-control/add-group-window-dark.png
new file mode 100644
index 00000000..54b59b38
Binary files /dev/null and b/static/assets/images/role-based-access-control/add-group-window-dark.png differ
diff --git a/static/assets/images/role-based-access-control/add-group-window-light.png b/static/assets/images/role-based-access-control/add-group-window-light.png
new file mode 100644
index 00000000..8fe98cfa
Binary files /dev/null and b/static/assets/images/role-based-access-control/add-group-window-light.png differ
diff --git a/static/assets/images/role-based-access-control/add-groups-action-dark.png b/static/assets/images/role-based-access-control/add-groups-action-dark.png
new file mode 100644
index 00000000..107db767
Binary files /dev/null and b/static/assets/images/role-based-access-control/add-groups-action-dark.png differ
diff --git a/static/assets/images/role-based-access-control/add-groups-action-light.png b/static/assets/images/role-based-access-control/add-groups-action-light.png
new file mode 100644
index 00000000..6b14f17d
Binary files /dev/null and b/static/assets/images/role-based-access-control/add-groups-action-light.png differ
diff --git a/static/assets/images/role-based-access-control/admin-group-permissions-dark.png b/static/assets/images/role-based-access-control/admin-group-permissions-dark.png
new file mode 100644
index 00000000..669ef215
Binary files /dev/null and b/static/assets/images/role-based-access-control/admin-group-permissions-dark.png differ
diff --git a/static/assets/images/role-based-access-control/admin-group-permissions-light.png b/static/assets/images/role-based-access-control/admin-group-permissions-light.png
new file mode 100644
index 00000000..7508068c
Binary files /dev/null and b/static/assets/images/role-based-access-control/admin-group-permissions-light.png differ
diff --git a/static/assets/images/role-based-access-control/change-object-category-dark.png b/static/assets/images/role-based-access-control/change-object-category-dark.png
new file mode 100644
index 00000000..088ce2a2
Binary files /dev/null and b/static/assets/images/role-based-access-control/change-object-category-dark.png differ
diff --git a/static/assets/images/role-based-access-control/change-object-category-light.png b/static/assets/images/role-based-access-control/change-object-category-light.png
new file mode 100644
index 00000000..81f30f10
Binary files /dev/null and b/static/assets/images/role-based-access-control/change-object-category-light.png differ
diff --git a/static/assets/images/role-based-access-control/direct-permissions-dark.png b/static/assets/images/role-based-access-control/direct-permissions-dark.png
new file mode 100644
index 00000000..87aebb08
Binary files /dev/null and b/static/assets/images/role-based-access-control/direct-permissions-dark.png differ
diff --git a/static/assets/images/role-based-access-control/direct-permissions-light.png b/static/assets/images/role-based-access-control/direct-permissions-light.png
new file mode 100644
index 00000000..67baeae6
Binary files /dev/null and b/static/assets/images/role-based-access-control/direct-permissions-light.png differ
diff --git a/static/assets/images/role-based-access-control/do-not-propagate-dark.png b/static/assets/images/role-based-access-control/do-not-propagate-dark.png
new file mode 100644
index 00000000..afafefce
Binary files /dev/null and b/static/assets/images/role-based-access-control/do-not-propagate-dark.png differ
diff --git a/static/assets/images/role-based-access-control/do-not-propagate-light.png b/static/assets/images/role-based-access-control/do-not-propagate-light.png
new file mode 100644
index 00000000..c0de7107
Binary files /dev/null and b/static/assets/images/role-based-access-control/do-not-propagate-light.png differ
diff --git a/static/assets/images/role-based-access-control/edit-object-category-dark.png b/static/assets/images/role-based-access-control/edit-object-category-dark.png
new file mode 100644
index 00000000..76d6a431
Binary files /dev/null and b/static/assets/images/role-based-access-control/edit-object-category-dark.png differ
diff --git a/static/assets/images/role-based-access-control/edit-object-category-light.png b/static/assets/images/role-based-access-control/edit-object-category-light.png
new file mode 100644
index 00000000..1b500e40
Binary files /dev/null and b/static/assets/images/role-based-access-control/edit-object-category-light.png differ
diff --git a/static/assets/images/role-based-access-control/grant-object-permissions-dark.png b/static/assets/images/role-based-access-control/grant-object-permissions-dark.png
new file mode 100644
index 00000000..484af20c
Binary files /dev/null and b/static/assets/images/role-based-access-control/grant-object-permissions-dark.png differ
diff --git a/static/assets/images/role-based-access-control/grant-object-permissions-light.png b/static/assets/images/role-based-access-control/grant-object-permissions-light.png
new file mode 100644
index 00000000..d3b16ac9
Binary files /dev/null and b/static/assets/images/role-based-access-control/grant-object-permissions-light.png differ
diff --git a/static/assets/images/role-based-access-control/permission-options-dark.png b/static/assets/images/role-based-access-control/permission-options-dark.png
new file mode 100644
index 00000000..8f18cc37
Binary files /dev/null and b/static/assets/images/role-based-access-control/permission-options-dark.png differ
diff --git a/static/assets/images/role-based-access-control/permission-options-light.png b/static/assets/images/role-based-access-control/permission-options-light.png
new file mode 100644
index 00000000..249465ac
Binary files /dev/null and b/static/assets/images/role-based-access-control/permission-options-light.png differ
diff --git a/static/assets/images/role-based-access-control/role-based-settings-dark.png b/static/assets/images/role-based-access-control/role-based-settings-dark.png
new file mode 100644
index 00000000..6ce8d4f9
Binary files /dev/null and b/static/assets/images/role-based-access-control/role-based-settings-dark.png differ
diff --git a/static/assets/images/role-based-access-control/role-based-settings-light.png b/static/assets/images/role-based-access-control/role-based-settings-light.png
new file mode 100644
index 00000000..7d5154bf
Binary files /dev/null and b/static/assets/images/role-based-access-control/role-based-settings-light.png differ
diff --git a/static/assets/images/role-based-access-control/view-permissions-dark.png b/static/assets/images/role-based-access-control/view-permissions-dark.png
new file mode 100644
index 00000000..7dbbdd1c
Binary files /dev/null and b/static/assets/images/role-based-access-control/view-permissions-dark.png differ
diff --git a/static/assets/images/role-based-access-control/view-permissions-light.png b/static/assets/images/role-based-access-control/view-permissions-light.png
new file mode 100644
index 00000000..e92038f2
Binary files /dev/null and b/static/assets/images/role-based-access-control/view-permissions-light.png differ