zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-08-19 07:54:16 +02:00
Code Issues Projects Releases Packages Wiki Activity

Remove inline show more

Browse source
This commit is contained in:
zandercymatics 2024-04-25 13:45:47 -06:00
parent 0bcc9ca43a
commit 309b403925
No known key found for this signature in database
GPG key ID: FF4636ABEC9682B7
3 changed files with 173 additions and 185 deletions
Download patch file Download diff file Expand all files Collapse all files

5
src/registrar/assets/js/get-gov-admin.js
View file

@ -562,6 +562,7 @@ function enableRelatedWidgetButtons(changeLink, deleteLink, viewLink, elementPk,
let descriptionDiv = document.querySelector('.dja__model-description'); let descriptionDiv = document.querySelector('.dja__model-description');
if (toggleButton && descriptionDiv) { if (toggleButton && descriptionDiv) {
toggleButton.addEventListener('click', function() { toggleButton.addEventListener('click', function() {
// Toggle the class on the description div // Toggle the class on the description div
descriptionDiv.classList.toggle('dja__model-description--no-overflow'); descriptionDiv.classList.toggle('dja__model-description--no-overflow');
@ -569,12 +570,8 @@ function enableRelatedWidgetButtons(changeLink, deleteLink, viewLink, elementPk,
// Change the button text based on the presence of the class // Change the button text based on the presence of the class
if (descriptionDiv.classList.contains('dja__model-description--no-overflow')) { if (descriptionDiv.classList.contains('dja__model-description--no-overflow')) {
toggleButton.textContent = 'Show less'; toggleButton.textContent = 'Show less';
// Move the div to where it was when the page first loaded
descriptionDiv.appendChild(toggleButton);
} else { } else {
toggleButton.textContent = 'Show more'; toggleButton.textContent = 'Show more';
descriptionDiv.insertAdjacentElement('afterend', toggleButton);
} }
}); });
} }

8
src/registrar/assets/sass/_theme/_admin.scss
View file

@ -636,15 +636,7 @@ div.dja__model-description{
} }
.dja__model-description + button {
margin-top: 25px !important;
height: 10px !important;
}
div.dja__model-description.dja__model-description--no-overflow { div.dja__model-description.dja__model-description--no-overflow {
display: block; display: block;
overflow: unset; overflow: unset;
button {
margin-top: unset;
}
} }

345
src/registrar/templates/admin/model_descriptions.html
View file

@ -1,188 +1,187 @@
<span class="display-inline-flex">
<div class="dja__model-description text-normal">
{% if opts.model_name == 'domainrequest' %}
<p>
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.
</p>
<p> <div class="dja__model-description text-normal">
Once a domain request has been adjudicated, the details of that request should not be modified. {% if opts.model_name == 'domainrequest' %}
To update attributes (like an organization’s name) after a domain’s approval, <p>
go to <a href="{% url 'admin:registrar_user_changelist' %}">Domains</a>. This table contains all domain requests that have been started within the registrar and the status of those requests.
Similar fields display on each Domain page, but edits made there will not affect the corresponding domain request. Updating values here will immediately update the corresponding values that users see in the registrar.
</p> </p>
{% elif opts.model_name == 'domaininformation' %}
<p>
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 <a href="{% url 'admin:registrar_domain_changelist' %}">Domains</a> table.
</p>
<p> <p>
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.
</p> To update attributes (like an organization’s name) after a domain’s approval,
go to <a href="{% url 'admin:registrar_user_changelist' %}">Domains</a>.
Similar fields display on each Domain page, but edits made there will not affect the corresponding domain request.
</p>
{% elif opts.model_name == 'domaininformation' %}
<p>
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 <a href="{% url 'admin:registrar_domain_changelist' %}">Domains</a> table.
</p>
<p> <p>
Domain information is similar to <a href="{% url 'admin:registrar_domainrequest_changelist' %}">Domain requests</a>, Updating values here will immediately update the corresponding values that users see in the registrar.
and the fields are nearly identical, </p>
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.
</p>
{% elif opts.model_name == 'contact' %}
<p>
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 <a href="{% url 'admin:registrar_user_changelist' %}">Users</a> table.
Updating someone’s contact information here will not affect that person’s Login.gov information.
</p>
{% elif opts.model_name == 'auditlog' %}
<p>
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
(<a href="{% url 'admin:registrar_domainrequest_changelist' %}">Domain requests</a>) and click on the “History” button.
</p>
{% elif opts.model_name == 'domain'%}
<p>
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.
</p>
<p> <p>
Individual domain pages allow you to view registry-related details and edit the associated domain information. Domain information is similar to <a href="{% url 'admin:registrar_domainrequest_changelist' %}">Domain requests</a>,
</p> 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.
</p>
{% elif opts.model_name == 'contact' %}
<p>
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 <a href="{% url 'admin:registrar_user_changelist' %}">Users</a> table.
Updating someone’s contact information here will not affect that person’s Login.gov information.
</p>
{% elif opts.model_name == 'auditlog' %}
<p>
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
(<a href="{% url 'admin:registrar_domainrequest_changelist' %}">Domain requests</a>) and click on the “History” button.
</p>
{% elif opts.model_name == 'domain'%}
<p>
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.
</p>
<p> <p>
Other actions available on the domain page include the ability to: Individual domain pages allow you to view registry-related details and edit the associated domain information.
</p> </p>
<ul>
<li>Extend a domain’s expiration date</li>
<li>Place a domain “On hold”</li>
<li>Remove a domain from the registry</li>
<li>View the domain from a domain manager’s perspective
</ul>
<p> <p>
To view a domain from a domain manager’s perspective, click the "Manage domain" button. Other actions available on the domain page include the ability to:
That will allow you to make changes (e.g., update DNS settings, invite people to manage the domain) </p>
directly inside the registrar. <ul>
</p> <li>Extend a domain’s expiration date</li>
{% elif opts.model_name == 'draftdomain' %} <li>Place a domain “On hold”</li>
<p> <li>Remove a domain from the registry</li>
This table represents all “requested domains” that have been saved within a domain request form. <li>View the domain from a domain manager’s perspective
If a registrant changes the requested domain in their form, </ul>
the original name they listed and the new name will appear as separate records.
</p>
<p>
This table does not include “alternative domains,”
which are housed in the <a href="{% url 'admin:registrar_website_changelist' %}">Websites</a> table.
</p>
{% elif opts.model_name == 'host' %}
<p>
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).
</p>
<p> <p>
In general, you should not modify these values here. They should be updated directly inside the registrar. To view a domain from a domain manager’s perspective, click the "Manage domain" button.
To update a domain’s name servers and/or IP addresses, That will allow you to make changes (e.g., update DNS settings, invite people to manage the domain)
in the registrar, go to the domain in <a href="{% url 'admin:registrar_domain_changelist' %}">Domains</a>, directly inside the registrar.
then click the "Manage domain" button. </p>
</p> {% elif opts.model_name == 'draftdomain' %}
{% elif opts.model_name == 'publiccontact' %} <p>
<p> This table represents all “requested domains” that have been saved within a domain request form.
Public contacts represent the three registry contact types (administrative, technical, and security) If a registrant changes the requested domain in their form,
and their fields that are exposed in WHOIS data. the original name they listed and the new name will appear as separate records.
</p> </p>
<p>
This table does not include “alternative domains,”
which are housed in the <a href="{% url 'admin:registrar_website_changelist' %}">Websites</a> table.
</p>
{% elif opts.model_name == 'host' %}
<p>
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).
</p>
<p> <p>
We don’t currently allow registrants to publish real contact information to WHOIS, In general, you should not modify these values here. They should be updated directly inside the registrar.
but we must publish something to WHOIS. For each of the contact types, we use default values that are To update a domain’s name servers and/or IP addresses,
associated with the program instead of the real contact information, in the registrar, go to the domain in <a href="{% url 'admin:registrar_domain_changelist' %}">Domains</a>,
which we then redact in whole at the registry/WHOIS. then click the "Manage domain" button.
We do allow registrants to set a security contact email address, </p>
which is published to WHOIS when a user sets one. {% elif opts.model_name == 'publiccontact' %}
</p> <p>
Public contacts represent the three registry contact types (administrative, technical, and security)
and their fields that are exposed in WHOIS data.
</p>
<p> <p>
The public contacts in this table are a reflection of the data in the registry and should not be updated. We don’t currently allow registrants to publish real contact information to WHOIS,
This information is primarily used by developers for validation purposes. but we must publish something to WHOIS. For each of the contact types, we use default values that are
</p> associated with the program instead of the real contact information,
{% elif opts.model_name == 'transitiondomain' %} which we then redact in whole at the registry/WHOIS.
<p> We do allow registrants to set a security contact email address,
This table represents the domains that were transitioned from the old registry in November 2023. which is published to WHOIS when a user sets one.
This data has been preserved for historical reference and should not be updated. </p>
</p>
{% elif opts.model_name == 'userdomainrole' %}
<p>
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.
</p>
<p> <p>
The creator of an approved domain request automatically becomes a manager for that domain. The public contacts in this table are a reflection of the data in the registry and should not be updated.
Anyone who retrieves a domain invitation is also assigned the manager role. This information is primarily used by developers for validation purposes.
</p> </p>
{% elif opts.model_name == 'usergroup' %} {% elif opts.model_name == 'transitiondomain' %}
<p> <p>
Groups are a way to bundle admin permissions so they can be easily assigned to multiple users. This table represents the domains that were transitioned from the old registry in November 2023.
Once a group is created, it can be assigned to people via the <a href="{% url 'admin:registrar_user_changelist' %}">Users</a> table. This data has been preserved for historical reference and should not be updated.
</p> </p>
{% elif opts.model_name == 'userdomainrole' %}
<p>
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.
</p>
<p> <p>
To maintain a single source of truth across all environments (stable, staging, etc.), The creator of an approved domain request automatically becomes a manager for that domain.
the groups and permissions are set and updated through the codebase. Anyone who retrieves a domain invitation is also assigned the manager role.
<strong>Do not add, edit or delete user groups here.</strong> </p>
</p> {% elif opts.model_name == 'usergroup' %}
{% elif opts.model_name == 'user' %} <p>
<p> Groups are a way to bundle admin permissions so they can be easily assigned to multiple users.
A user is anyone who has access to the registrar. This includes request creators, domain managers, and CISA administrators. Once a group is created, it can be assigned to people via the <a href="{% url 'admin:registrar_user_changelist' %}">Users</a> table.
Within each user record, you can review that user’s permissions and user status. </p>
</p>
<p> <p>
If a user has a domain request in ineligible status, then their user status will be “restricted.” To maintain a single source of truth across all environments (stable, staging, etc.),
Users who are in restricted status cannot create/edit domain requests or approved domains, the groups and permissions are set and updated through the codebase.
and their existing requests are locked. They will see a 403 error if they try to take action in the registrar. <strong>Do not add, edit or delete user groups here.</strong>
</p> </p>
{% elif opts.model_name == 'user' %}
<p>
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.
</p>
<p> <p>
Each user record displays the associated “contact” info for that user, If a user has a domain request in ineligible status, then their user status will be “restricted.”
which is the same info found in the <a href="{% url 'admin:registrar_contact_changelist' %}">Contacts</a> table. Users who are in restricted status cannot create/edit domain requests or approved domains,
Updating these details on the user record will also update the corresponding contact record for that user. and their existing requests are locked. They will see a 403 error if they try to take action in the registrar.
</p> </p>
{% elif opts.model_name == 'verifiedbystaff' %}
<p>
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.
</p>
<p> <p>
Additions to this table should be rare, and only after obtaining confirmation of their identity directly (or from a trusted person). Each user record displays the associated “contact” info for that user,
Once a verified-by-staff user has been added as a domain manager, they can be removed from this list, which is the same info found in the <a href="{% url 'admin:registrar_contact_changelist' %}">Contacts</a> table.
(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). Updating these details on the user record will also update the corresponding contact record for that user.
</p> </p>
{% elif opts.model_name == 'website' %} {% elif opts.model_name == 'verifiedbystaff' %}
<p> <p>
This table lists all the “current websites” and “alternative domains” that users have submitted in domain requests since January 2024. This table contains users who have been allowed to bypass identity proofing through Login.gov after approval by a CISA representative.
</p> Bypassing identity proofing means they will not be asked to provide a form of ID, PII, and so on.
</p>
<p> <p>
This does not include any “requested domains” that have appeared within the <a href="{% url 'admin:registrar_domainrequest_changelist' %}">Domain requests</a> table. Additions to this table should be rare, and only after obtaining confirmation of their identity directly (or from a trusted person).
Those names are managed in the <a href="{% url 'admin:registrar_draftdomain_changelist' %}">Draft domains<a/> table. Once a verified-by-staff user has been added as a domain manager, they can be removed from this list,
</p> (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).
{% else %} </p>
<p>This table does not have a description yet.</p> {% elif opts.model_name == 'website' %}
{% endif %} <p>
</div> This table lists all the “current websites” and “alternative domains” that users have submitted in domain requests since January 2024.
<button id="dja-show-more-model-description" class="usa-button usa-button--unstyled text-no-underline" type="button">Show more</button> </p>
</span>
<p>
This does not include any “requested domains” that have appeared within the <a href="{% url 'admin:registrar_domainrequest_changelist' %}">Domain requests</a> table.
Those names are managed in the <a href="{% url 'admin:registrar_draftdomain_changelist' %}">Draft domains<a/> table.
</p>
{% else %}
<p>This table does not have a description yet.</p>
{% endif %}
</div>
<button id="dja-show-more-model-description" class="usa-button usa-button--unstyled text-no-underline margin-top-1" type="button">Show more</button>