1265: language improvements; passwords and role-based-access-control pages (Week 21, 2026)

docs/administration/passwords/burnt-secret-password-storage.mdx

@@ -14,7 +14,7 @@ If a burnt Secret is forgotten, it **must** be reset and regenerated. Storing th
 
 ## Store a Burnt Secret
 
-Creating a burnt Secret is very similar to the creation of a normal stored Secret. Head to the **Resources > All Secrets** and click **Create**. 
+Creating a burnt Secret is similar to creating a normal stored Secret. Navigate to **Resources > All Secrets** and click **Create**.
 
 The **Password Storage** option can be set to **Burnt** (as opposed to the default of **Normal**), which will cause a Secret to be stored non-retrievable:
 

docs/administration/passwords/index.mdx

@@ -4,5 +4,5 @@ title: "Passwords"
 
 Device42 software helps IT teams securely manage passwords for Device42 user accounts and for environment discovery purposes. Passwords that are stored for the purpose of authentication for discovery and other tasks are called 'Secrets'. Passwords related to the Device42 user accounts are called 'passwords'.
 
-This section covers password operations, policy, reporting, burnt secret storage, and secret permissions. Use the sidebar on the left to navigate to specific pages. 
+This section covers password operations, policy, reporting, burnt secret storage, and secret permissions. Use the sidebar on the left to navigate to specific pages.
 

docs/administration/passwords/password-operations.mdx

@@ -28,7 +28,7 @@ Navigate to **Tools > Settings > Password Security** and enter a 12-32 character
 
 ## Add a New Secret
 
-Navigate to **Resources > Secrets >All Secrets** and click **Create**. 
+Navigate to **Resources > Secrets > All Secrets** and click **Create**.
 
 You'll also have the option to add a new Secret from discovery job pages and anywhere else credentials are needed.
 
@@ -47,14 +47,14 @@ Fill in the following fields:
 - **Category**: Select a category or add a new one. 
 - **\# Days Before Expiration**: Number of days before the password expires. 
 - **Use Password**: Selected by default. 
-- **Password Storage**: Choose between **Normal** or **Burnt**. See [Burnt Secret Storage](administration/passwords/burnt-secret-password-storage/#what-is-a-burnt-secret.mdx) for more information.
+- **Password Storage**: Choose between **Normal** or **Burnt**. See [Burnt Secret Storage](administration/passwords/burnt-secret-password-storage.mdx#what-is-a-burnt-secret) for more information.
 - **Password:** Required when **Use Password** is selected. Click the **eye icon** to display the password. 
 - **Key File**: Select an existing key file stored on your machine. 
 - **Devices**: Optionally assign one or more devices to a password. Useful for easy searching and centralizing all device passwords.
 - **Application Components**: Optionally assign one or more [Application Components](apps/application-components/index.mdx) to a password.
 - **Notes**: Searchable free text.
 - **Last Password Change**: Provide the date and time the password was changed.
-- **Custom Fields**: Assign custom field values. Learn more about [creating a custom field for Secrets](administration/custom-key-value-pairs-explained/#create-a-custom-field-for-secrets.mdx).
+- **Custom Fields**: Assign custom field values. Learn more about [creating a custom field for Secrets](administration/custom-key-value-pairs-explained.mdx#create-a-custom-field-for-secrets).
 
 ### Assign Permissions
 
@@ -97,7 +97,7 @@ Navigate to **Resources > Secrets > All Secrets** to display the Secrets list pa
 
 Note that the search bar doesn't return matches for passwords. You have to go to the Secrets list page to perform a search for specific passwords (stored in the Secret object).
 
-By default, the password is not displayed. Click the blue **eye icon** to display the password or to hide it again. Click the blue **copy icon** to copy the password to your clipboard.
+By default, the password is not displayed. Click the blue **eye icon** to display the password or hide it again. Click the blue **copy icon** to copy the password to your clipboard.
 
 <ThemedImage
   alt="Secrets list page"

docs/administration/passwords/password-policy.mdx

@@ -63,7 +63,7 @@ Selecting **Expire Passwords** and **Lock Accounts** options prevent users from
 ### Account Lockout
 
 - A login attempt with an invalid password counts against account lockout.
-- Users locked out of their account see an alert when they try to login and must contact their administrator to regain account access.
+- Users locked out of their account see an alert when they try to log in and must contact their administrator to regain account access.
 
 <ThemedImage
   alt="Login page with locked account alert"

docs/administration/passwords/password-security-and-permissions.mdx

@@ -36,7 +36,7 @@ The following Admin Group permissions are available:
 
 - **Add permission** allows users to create new Secrets.
 
-- **View / Change permission** is needed to view the Secret in the menu, but the permission is controlled granularly for each Secret. So, you can globally assign the view/change permission to a group, but it would not give that group permission to edit specific Secrets. It would only enable the group to see the Secret.
+- **View or Change permission** is needed to view the Secret in the menu, but the permission is controlled granularly for each Secret. So, you can globally assign the view or change permission to a group, but it would not give that group permission to edit specific Secrets. It would only enable the group to see the Secret.
 
 - **Delete permission** is required to see the delete button, but individual permission to delete a Secret is controlled by permissions granted on that Secret. If a user can change a Secret, they can also delete that Secret.
 
@@ -68,12 +68,12 @@ Each permission can be applied to two user categories - individual Users and Adm
 
 - **Use Only Users:** Users who can only **use** the Secret.
 - **Use Only Groups:** Admin Groups who can only **use** the Secret.
-- **View edit users:** Users who can **view and change** the Secret.
-- **View edit groups:** Admin Groups who can **view and change** the Secret.
+- **View Edit Users:** Users who can **view and change** the Secret.
+- **View Edit Groups:** Admin Groups who can **view and change** the Secret.
 
 At least one User or Admin Group should have permission to edit a Secret. Otherwise, a password might become inaccessible.
 
-If no permissions are entered, the User who created the Secret will have **view/edit** permission by default.
+If no permissions are entered, the User who created the Secret will have **view or edit** permission by default.
 
 ## Bulk Permissions Change
 
@@ -115,6 +115,6 @@ From the Secrets list page, you can edit the group permissions of many Secrets a
 - All change, add, delete, and view operations are logged in an audit trail.
 - After one minute of inactivity on a password page, the session will timeout.
 - A global timeout value controls the overall timeout for any session and is set in the Appliance Manager.
-- Secrets aren't displayed in the Secret list page by default. Click on the eye icon next to the Secret to display it. 
+- Secrets aren't displayed in the Secret list page by default. Click the **eye icon** next to the Secret to display it.
 
-See our [Centralized Password Management](https://www.device42.com/blog/2012/05/04/introducing-centralized-device-password-management/) blog post for more details.
+See the [Centralized Password Management](https://www.device42.com/blog/2012/05/04/introducing-centralized-device-password-management/) blog post for more details.

docs/administration/passwords/secrets-reporting.mdx

@@ -65,7 +65,7 @@ Device42 displays your Secrets data in a grid view.
     }}
     />
 
-- Enter a unique name for the report in order to **Save** it.
+- Enter a unique name for the report to **Save** it.
 
 ### Export and Schedule the Report
 
@@ -79,4 +79,4 @@ Click **Export** and choose between the **Excel** or **TSV** (Tab-Separated Valu
   }}
 />
 
-See [Reports](/reports/index.mdx) for more information about creating Device42 reports.
+See [Reports](reports/index.mdx) for more information about creating Device42 reports.

docs/administration/passwords/set-default-password-management-group.mdx

@@ -6,7 +6,7 @@ sidebar_position: 3
 import ThemedImage from "@theme/ThemedImage";
 import useBaseUrl from "@docusaurus/useBaseUrl";
 
-Device42 allows you to set a default view-edit group for passwords. Once set the group(s) will be given view-edit privileges by default on all new passwords.
+Device42 allows you to set a default view-edit group for passwords. Once set, the group or groups will be given view-edit privileges by default on all new passwords.
 
 ## Set the Default Group
 

docs/administration/role-based-access-control/index.mdx

@@ -56,7 +56,7 @@ The list pages for permissioned objects have two useful filters:
 - Filter by an object or subnet category to see all objects that can be seen by groups with view permissions for the category.
 
 
-You can view the objects that a group is associated with by clicking the ellipsis icon and selecting **Direct Permissions**, **Inherited Permissions**, or **All Permissions**.
+You can view the objects that a group is associated with by clicking the **ellipsis icon** and selecting **Direct Permissions**, **Inherited Permissions**, or **All Permissions**.
 
 <ThemedImage
   alt="Permission buttons"
@@ -180,7 +180,7 @@ From the list view of the object type, bulk select the objects you want to assig
   }}
 />
 
-Here, we are about to assign the **Prod** admin group permissions to the three racks listed above. 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.
+In this example, you are assigning the **Prod** admin group permissions to the three racks listed above. 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.
 
 <ThemedImage
   alt="Select admin group"
@@ -234,7 +234,7 @@ The following objects and screens do not have object-level permission and are go
 - Telecom and Power circuits 
 - DNS 
 - OS’s 
-- Passwords (also have their own user/group security) 
+- Passwords (also have their own user or group security)
 - Lifecycle Event Actions 
 - Misc Functions 
 - Custom Field setup 
@@ -245,7 +245,7 @@ The following objects and screens do not have object-level permission and are go
 
 ## 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:
+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. This hierarchy is called 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.
@@ -254,7 +254,7 @@ If an admin group is granted access to a building, the admin group is also grant
 - 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.
 
-There is a second hierarchy that we call the IP Hierarchy. The rules for the IP Hierarchy are as follows:
+There is a second hierarchy called 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.
@@ -264,7 +264,7 @@ Please note that change permission for an object also applies to the objects ben
 
 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.
+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
 
@@ -280,7 +280,7 @@ If you have view but not change permission to a device, you can still add an IP
 
 If you give a group change permission to a room, you should also grant view permission to the building for the room. Otherwise, the user won't be able to select a building and, without a building specified, they won't be able to save the room edit form.
 
-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 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 (for example, 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 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.
 

docs/administration/role-based-access-control/role-based-permissions-and-access.mdx

@@ -6,7 +6,7 @@ sidebar_position: 1
 import ThemedImage from '@theme/ThemedImage'
 import useBaseUrl from '@docusaurus/useBaseUrl'
 
-Role-based access can be defined at either the group or user level. If you have many users but a smaller number of different permission sets, it would make sense to use admin groups. In the example below, we will create a new group with selected IP address, DNS, and VLAN management permissions.
+Role-based access can be defined at either the group or user level. If you have many users but a smaller number of different permission sets, it makes sense to use admin groups. In the example below, you will create a new group with selected IP address, DNS, and VLAN management permissions.
 
 ## Create a New Admin Group
 
@@ -44,7 +44,7 @@ In the screenshot below, we have added several IP-related permissions and are ab
   }}
 />
 
-And now we'll add some VLAN permissions.
+Next, add some VLAN permissions.
 
 <ThemedImage
   alt="Select VLAN-related permissions"
@@ -60,7 +60,7 @@ Navigate to **Tools > Administrators**, select the user from the list page, and
 
 When you click **Save**, the user will only have permissions to act on the IP addresses, DNS records, and VLANs defined in the admin group they are assigned to.
 
-Please make sure the **Superuser Status** checkbox is unchecked before saving.
+Make sure the **Superuser Status** checkbox is unchecked before saving.
 
 <ThemedImage
   alt="Assign user to Admin Group"