diff --git a/src/registrar/assets/sass/_theme/_admin.scss b/src/registrar/assets/sass/_theme/_admin.scss index 137365309..6d49b724e 100644 --- a/src/registrar/assets/sass/_theme/_admin.scss +++ b/src/registrar/assets/sass/_theme/_admin.scss @@ -619,9 +619,22 @@ address.dja-address-contact-list { } div.django-admin__model-description{ - color: var(--primary); + p, li { + color: var(--primary); + font-size: medium; + line-height: 1.2em; + } + + li { + list-style-type: disc; + } + + button { + padding-top: 20px; + } + display: -webkit-box; - -webkit-line-clamp: 3; + -webkit-line-clamp: 2; -webkit-box-orient: vertical; overflow: hidden; } diff --git a/src/registrar/templates/admin/model_descriptions.html b/src/registrar/templates/admin/model_descriptions.html index 9c311ce5c..f1c580af4 100644 --- a/src/registrar/templates/admin/model_descriptions.html +++ b/src/registrar/templates/admin/model_descriptions.html @@ -1,183 +1,188 @@ -
- This table contains all domain requests that have been started within the registrar and the status of those requests. - Updating values here will immediately update the corresponding values that users see in the registrar. -
+ ++ This table contains all domain requests that have been started within the registrar and the status of those requests. + Updating values here will immediately update the corresponding values that users see in the registrar. +
-- Once a domain request has been adjudicated, the details of that request should not be modified. - To update attributes (like an organization’s name) after a domain’s approval, - go to Domains. - Similar fields display on each Domain page, but edits made there will not affect the corresponding domain request. -
- {% elif opts.model_name == 'domaininformation' %} -- Domain information represents the basic metadata for an approved domain and the organization that manages it. - It does not include any information specific to the registry (DNS name servers, security email). - Registry-related information - can be managed within the Domains table. -
++ Once a domain request has been adjudicated, the details of that request should not be modified. + To update attributes (like an organization’s name) after a domain’s approval, + go to Domains. + Similar fields display on each Domain page, but edits made there will not affect the corresponding domain request. +
+ {% elif opts.model_name == 'domaininformation' %} ++ Domain information represents the basic metadata for an approved domain and the organization that manages it. + It does not include any information specific to the registry (DNS name servers, security email). + Registry-related information + can be managed within the Domains table. +
-- Updating values here will immediately update the corresponding values that users see in the registrar. -
++ Updating values here will immediately update the corresponding values that users see in the registrar. +
-- Domain information is similar to Domain requests, - and the fields are nearly identical, - but edits made to one are not made to the other. - Domain information exists so we don’t modify details of an approved request after adjudication - (since a domain request should be maintained as-adjudicated for records retention purposes). - Entries are created here upon approval of a domain request. -
- {% elif opts.model_name == 'contact' %} -- Contacts include anyone who has access to the registrar (known as “users”) and anyone listed in a domain request, - including other employees and authorizing officials. - Only contacts who have access to the registrar will have - a corresponding record within the Users table. - Updating someone’s contact information here will not affect that person’s Login.gov information. -
- {% elif opts.model_name == 'auditlog' %} -- Log entries represent instances where something was created, updated, or deleted within the registrar or /admin. - The table on this page is useful for searching actions across all records. - To understand what happened to an individual record (like a domain request), - it’s better to go to that specific page - (Domain requests) and click on the “History” button. -
- {% elif opts.model_name == 'domain'%} -- This table contains all approved domains in the .gov registrar. - In other words, with the exception of domains in the “Unknown”, ”On hold”, and “Deleted” states, - this table matches the list of domains in the .gov zone file. -
++ Domain information is similar to Domain requests, + and the fields are nearly identical, + but edits made to one are not made to the other. + Domain information exists so we don’t modify details of an approved request after adjudication + (since a domain request should be maintained as-adjudicated for records retention purposes). + Entries are created here upon approval of a domain request. +
+ {% elif opts.model_name == 'contact' %} ++ Contacts include anyone who has access to the registrar (known as “users”) and anyone listed in a domain request, + including other employees and authorizing officials. + Only contacts who have access to the registrar will have + a corresponding record within the Users table. + Updating someone’s contact information here will not affect that person’s Login.gov information. +
+ {% elif opts.model_name == 'auditlog' %} ++ Log entries represent instances where something was created, updated, or deleted within the registrar or /admin. + The table on this page is useful for searching actions across all records. + To understand what happened to an individual record (like a domain request), + it’s better to go to that specific page + (Domain requests) and click on the “History” button. +
+ {% elif opts.model_name == 'domain'%} ++ This table contains all approved domains in the .gov registrar. + In other words, with the exception of domains in the “Unknown”, ”On hold”, and “Deleted” states, + this table matches the list of domains in the .gov zone file. +
-- Individual domain pages allow you to view registry-related details and edit the associated domain information. -
++ Individual domain pages allow you to view registry-related details and edit the associated domain information. +
-- Other actions available on the domain page include the ability to: -
-+ Other actions available on the domain page include the ability to: +
+- To view a domain from a domain manager’s perspective, click the "Manage domain" button. - That will allow you to make changes (e.g., update DNS settings, invite people to manage the domain) - directly inside the registrar. -
- {% elif opts.model_name == 'draftdomain' %} -- This table represents all “requested domains” that have been saved within a domain request form. - If a registrant changes the requested domain in their form, - the original name they listed and the new name will appear as separate records. -
- -- This table does not include “alternative domains,” - which are housed in the Websites table. -
- {% elif opts.model_name == 'host' %} -- Entries in the Hosts table indicate the relationship between an approved domain and a name server address - (and, if applicable, the IP address for a name server address). -
++ To view a domain from a domain manager’s perspective, click the "Manage domain" button. + That will allow you to make changes (e.g., update DNS settings, invite people to manage the domain) + directly inside the registrar. +
+ {% elif opts.model_name == 'draftdomain' %} ++ This table represents all “requested domains” that have been saved within a domain request form. + If a registrant changes the requested domain in their form, + the original name they listed and the new name will appear as separate records. +
+ ++ This table does not include “alternative domains,” + which are housed in the Websites table. +
+ {% elif opts.model_name == 'host' %} ++ Entries in the Hosts table indicate the relationship between an approved domain and a name server address + (and, if applicable, the IP address for a name server address). +
-- In general, you should not modify these values here. They should be updated directly inside the registrar. - To update a domain’s name servers and/or IP addresses, - in the registrar, go to the domain in Domains, - then click the "Manage domain" button. -
- {% elif opts.model_name == 'publiccontact' %} -- Public contacts represent the three registry contact types (administrative, technical, and security) - and their fields that are exposed in WHOIS data. -
++ In general, you should not modify these values here. They should be updated directly inside the registrar. + To update a domain’s name servers and/or IP addresses, + in the registrar, go to the domain in Domains, + then click the "Manage domain" button. +
+ {% elif opts.model_name == 'publiccontact' %} ++ Public contacts represent the three registry contact types (administrative, technical, and security) + and their fields that are exposed in WHOIS data. +
-- We don’t currently allow registrants to publish real contact information to WHOIS, - but we must publish something to WHOIS. For each of the contact types, we use default values that are - associated with the program instead of the real contact information, - which we then redact in whole at the registry/WHOIS. - We do allow registrants to set a security contact email address, - which is published to WHOIS when a user sets one. -
++ We don’t currently allow registrants to publish real contact information to WHOIS, + but we must publish something to WHOIS. For each of the contact types, we use default values that are + associated with the program instead of the real contact information, + which we then redact in whole at the registry/WHOIS. + We do allow registrants to set a security contact email address, + which is published to WHOIS when a user sets one. +
-- The public contacts in this table are a reflection of the data in the registry and should not be updated. - This information is primarily used by developers for validation purposes. -
- {% elif opts.model_name == 'transitiondomain' %} -- This table represents the domains that were transitioned from the old registry in November 2023. - This data has been preserved for historical reference and should not be updated. -
- {% elif opts.model_name == 'userdomainrole' %} -- This table represents the managers who are assigned to each domain in the registrar. - There are separate records for each domain/manager combination. - Managers can update information related to a domain, such as DNS data and security contact. -
++ The public contacts in this table are a reflection of the data in the registry and should not be updated. + This information is primarily used by developers for validation purposes. +
+ {% elif opts.model_name == 'transitiondomain' %} ++ This table represents the domains that were transitioned from the old registry in November 2023. + This data has been preserved for historical reference and should not be updated. +
+ {% elif opts.model_name == 'userdomainrole' %} ++ This table represents the managers who are assigned to each domain in the registrar. + There are separate records for each domain/manager combination. + Managers can update information related to a domain, such as DNS data and security contact. +
-- The creator of an approved domain request automatically becomes a manager for that domain. - Anyone who retrieves a domain invitation is also assigned the manager role. -
- {% elif opts.model_name == 'usergroup' %} -- Groups are a way to bundle admin permissions so they can be easily assigned to multiple users. - Once a group is created, it can be assigned to people via the Users table. -
++ The creator of an approved domain request automatically becomes a manager for that domain. + Anyone who retrieves a domain invitation is also assigned the manager role. +
+ {% elif opts.model_name == 'usergroup' %} ++ Groups are a way to bundle admin permissions so they can be easily assigned to multiple users. + Once a group is created, it can be assigned to people via the Users table. +
-- To maintain a single source of truth across all environments (stable, staging, etc.), - the groups and permissions are set and updated through the codebase. - Do not add, edit or delete user groups here. -
- {% elif opts.model_name == 'user' %} -- A user is anyone who has access to the registrar. This includes request creators, domain managers, and CISA administrators. - Within each user record, you can review that user’s permissions and user status. -
++ To maintain a single source of truth across all environments (stable, staging, etc.), + the groups and permissions are set and updated through the codebase. + Do not add, edit or delete user groups here. +
+ {% elif opts.model_name == 'user' %} ++ A user is anyone who has access to the registrar. This includes request creators, domain managers, and CISA administrators. + Within each user record, you can review that user’s permissions and user status. +
-- If a user has a domain request in ineligible status, then their user status will be “restricted.” - Users who are in restricted status cannot create/edit domain requests or approved domains, - and their existing requests are locked. They will see a 403 error if they try to take action in the registrar. -
++ If a user has a domain request in ineligible status, then their user status will be “restricted.” + Users who are in restricted status cannot create/edit domain requests or approved domains, + and their existing requests are locked. They will see a 403 error if they try to take action in the registrar. +
-- Each user record displays the associated “contact” info for that user, - which is the same info found in the Contacts table. - Updating these details on the user record will also update the corresponding contact record for that user. -
- {% elif opts.model_name == 'verifiedbystaff' %} -- This table contains users who have been allowed to bypass identity proofing through Login.gov after approval by a CISA representative. - Bypassing identity proofing means they will not be asked to provide a form of ID, PII, and so on. -
++ Each user record displays the associated “contact” info for that user, + which is the same info found in the Contacts table. + Updating these details on the user record will also update the corresponding contact record for that user. +
+ {% elif opts.model_name == 'verifiedbystaff' %} ++ This table contains users who have been allowed to bypass identity proofing through Login.gov after approval by a CISA representative. + Bypassing identity proofing means they will not be asked to provide a form of ID, PII, and so on. +
-- Additions to this table should be rare, and only after obtaining confirmation of their identity directly (or from a trusted person). - Once a verified-by-staff user has been added as a domain manager, they can be removed from this list, - (However, if they are removed as a domain manager for all domains and they attempt to sign in again, they will be identity proofed by Login.gov). -
- {% elif opts.model_name == 'websites' %} -- This section lists all the “current websites” and “alternative domains” that users have submitted in domain requests since January 2024. -
++ Additions to this table should be rare, and only after obtaining confirmation of their identity directly (or from a trusted person). + Once a verified-by-staff user has been added as a domain manager, they can be removed from this list, + (However, if they are removed as a domain manager for all domains and they attempt to sign in again, they will be identity proofed by Login.gov). +
+ {% elif opts.model_name == 'website' %} ++ This table lists all the “current websites” and “alternative domains” that users have submitted in domain requests since January 2024. +
-- This does not include any “requested domains” that have appeared within the Domain requests table. - Those names are managed in the Draft domains table. -
- {% endif %} -+ This does not include any “requested domains” that have appeared within the Domain requests table. + Those names are managed in the Draft domains table. +
+ {% else %} +This table does not have a description yet.
+ {% endif %} +