diff --git a/src/registrar/assets/sass/_theme/_admin.scss b/src/registrar/assets/sass/_theme/_admin.scss index 9100fb945..0e6768268 100644 --- a/src/registrar/assets/sass/_theme/_admin.scss +++ b/src/registrar/assets/sass/_theme/_admin.scss @@ -679,7 +679,7 @@ div.dja__model-description{ @media (prefers-color-scheme: dark) { p, li { - color: var(--primary); + color: var(--body-bg); } } @@ -689,7 +689,7 @@ div.dja__model-description{ &.dja__model-description--no-overflow { display: block; - overflow: unset; + overflow: auto; } } diff --git a/src/registrar/templates/admin/model_descriptions.html b/src/registrar/templates/admin/model_descriptions.html index 6469f6188..3236ce57a 100644 --- a/src/registrar/templates/admin/model_descriptions.html +++ b/src/registrar/templates/admin/model_descriptions.html @@ -1,202 +1,35 @@
{% if opts.model_name == 'domainrequest' %} -

- 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. -

+ {% include "django/admin/includes/descriptions/domain_request_description.html" %} {% 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. -

- -

- 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. -

+ {% include "django/admin/includes/descriptions/domain_information_description.html" %} {% elif opts.model_name == 'domaininvitation' %} -

- Domain invitations contain all individuals who have been invited to manage a .gov domain. - Invitations are sent via email, and the recipient must log in to the registrar to officially - accept and become a domain manager. -

- -

- An “invited” status indicates that the recipient has not logged in to the registrar since the invitation was sent. - A “received” status indicates that the recipient has logged in. -

- -

- If an invitation is created in this table, an email will not be sent. - To have an email sent, go to the domain in Domains, - click the “Manage domain” button, and add a domain manager. -

+ {% include "django/admin/includes/descriptions/domain_invitation_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/contact_description.html" %} {% elif opts.model_name == 'logentry' %} -

- 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. -

+ {% include "django/admin/includes/descriptions/logentry_description.html" %} {% 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. -

- -

- 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. -

+ {% include "django/admin/includes/descriptions/domain_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/draft_domain_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/host_description.html" %} {% 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. -

- -

- 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. -

+ {% include "django/admin/includes/descriptions/public_contact_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/transition_domain_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/user_domain_role_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/user_group_description.html" %} {% 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. -

- -

- 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. -

+ {% include "django/admin/includes/descriptions/user_description.html" %} {% 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). -

+ {% include "django/admin/includes/descriptions/verified_by_staff_description.html" %} {% 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. -

+ {% include "django/admin/includes/descriptions/website.html" %} {% else %}

This table does not have a description yet.

{% endif %} diff --git a/src/registrar/templates/django/admin/includes/descriptions/contact_description.html b/src/registrar/templates/django/admin/includes/descriptions/contact_description.html new file mode 100644 index 000000000..c264f238f --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/contact_description.html @@ -0,0 +1,7 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/domain_description.html b/src/registrar/templates/django/admin/includes/descriptions/domain_description.html new file mode 100644 index 000000000..c6e4a0fa6 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/domain_description.html @@ -0,0 +1,25 @@ +

+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. +

+ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/domain_information_description.html b/src/registrar/templates/django/admin/includes/descriptions/domain_information_description.html new file mode 100644 index 000000000..ccf683e59 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/domain_information_description.html @@ -0,0 +1,19 @@ +

+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. +

+ +

+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. +

diff --git a/src/registrar/templates/django/admin/includes/descriptions/domain_invitation_description.html b/src/registrar/templates/django/admin/includes/descriptions/domain_invitation_description.html new file mode 100644 index 000000000..495c64eb4 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/domain_invitation_description.html @@ -0,0 +1,16 @@ +

+Domain invitations contain all individuals who have been invited to manage a .gov domain. +Invitations are sent via email, and the recipient must log in to the registrar to officially +accept and become a domain manager. +

+ +

+An “invited” status indicates that the recipient has not logged in to the registrar since the invitation was sent. +A “received” status indicates that the recipient has logged in. +

+ +

+If an invitation is created in this table, an email will not be sent. +To have an email sent, go to the domain in Domains, +click the “Manage domain” button, and add a domain manager. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/domain_request_description.html b/src/registrar/templates/django/admin/includes/descriptions/domain_request_description.html new file mode 100644 index 000000000..03cb2a0fa --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/domain_request_description.html @@ -0,0 +1,11 @@ +

+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. +

diff --git a/src/registrar/templates/django/admin/includes/descriptions/draft_domain_description.html b/src/registrar/templates/django/admin/includes/descriptions/draft_domain_description.html new file mode 100644 index 000000000..818b74b3b --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/draft_domain_description.html @@ -0,0 +1,10 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/host_description.html b/src/registrar/templates/django/admin/includes/descriptions/host_description.html new file mode 100644 index 000000000..99f7968fb --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/host_description.html @@ -0,0 +1,11 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/logentry_description.html b/src/registrar/templates/django/admin/includes/descriptions/logentry_description.html new file mode 100644 index 000000000..29185f27b --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/logentry_description.html @@ -0,0 +1,7 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/public_contact_description.html b/src/registrar/templates/django/admin/includes/descriptions/public_contact_description.html new file mode 100644 index 000000000..beab93929 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/public_contact_description.html @@ -0,0 +1,18 @@ +

+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. +

+ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/transition_domain_description.html b/src/registrar/templates/django/admin/includes/descriptions/transition_domain_description.html new file mode 100644 index 000000000..6eb450015 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/transition_domain_description.html @@ -0,0 +1,4 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/user_description.html b/src/registrar/templates/django/admin/includes/descriptions/user_description.html new file mode 100644 index 000000000..d50c210a1 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/user_description.html @@ -0,0 +1,16 @@ +

+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. +

+ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/user_domain_role_description.html b/src/registrar/templates/django/admin/includes/descriptions/user_domain_role_description.html new file mode 100644 index 000000000..45f45957b --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/user_domain_role_description.html @@ -0,0 +1,10 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/user_group_description.html b/src/registrar/templates/django/admin/includes/descriptions/user_group_description.html new file mode 100644 index 000000000..22a692a8a --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/user_group_description.html @@ -0,0 +1,10 @@ +

+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. +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/verified_by_staff_description.html b/src/registrar/templates/django/admin/includes/descriptions/verified_by_staff_description.html new file mode 100644 index 000000000..3f2580ec8 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/verified_by_staff_description.html @@ -0,0 +1,10 @@ +

+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). +

\ No newline at end of file diff --git a/src/registrar/templates/django/admin/includes/descriptions/website.html b/src/registrar/templates/django/admin/includes/descriptions/website.html new file mode 100644 index 000000000..1e48a1495 --- /dev/null +++ b/src/registrar/templates/django/admin/includes/descriptions/website.html @@ -0,0 +1,8 @@ +

+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. +

\ No newline at end of file