Merge pull request #1855 from cisagov/nl/1064-Change-domain-applicati…

…on-to-domain-requests

Issue #1064: Rename "application" to "domain requests"

.github/ISSUE_TEMPLATE/bug.yml

@@ -22,7 +22,7 @@ body:
     attributes:
       label: Expected Behavior
       description: "Please add a concise description of the behavior you would expect if this issue were not occurring"
-      placeholder: "Example: When submitting a new domain application, the request should be successful, OR if there is a problem with the user's application preventing submission, errors should be enumerated to the user"
+      placeholder: "Example: When submitting a new domain request, the request should be successful, OR if there is a problem with the user's application preventing submission, errors should be enumerated to the user"
     validations:
       required: true
   - type: textarea
@@ -33,8 +33,8 @@ body:
         How can the issue be reliably reproduced? Feel free to include screenshots or other supporting artifacts
         
         Example:
-        1. In the test environment, fill out the application for a new domain
-        2. Click the button to trigger a save/submit on the final page and complete the application 
+        1. In the test environment, fill out the domain request for a new domain
+        2. Click the button to trigger a save/submit on the final page and complete the domain request 
         3. See the error
       value: |
         1.

.github/ISSUE_TEMPLATE/story.yml

@@ -19,7 +19,7 @@ body:
         
         Example:
         As an analyst
-        I want the ability to approve a domain application
+        I want the ability to approve a domain request
         so that a request can be fulfilled and a new .gov domain can be provisioned
       value: |
         As a 
@@ -36,11 +36,11 @@ body:
         
         Example:
         - Application sends an email when analysts approve domain requests
-        - Domain application status is "approved"
+        - Domain request status is "approved"
         
         Example ("given, when, then" format):
-        Given that I am an analyst who has finished reviewing a domain application
-        When I click to approve a domain application
+        Given that I am an analyst who has finished reviewing a domain request
+        When I click to approve a domain request
         Then the domain provisioning process should be initiated, and the applicant should receive an email update.
     validations:
       required: true

docs/architecture/decisions/0015-use-django-fsm.md

@@ -1,4 +1,4 @@
-# 15. Use Django-FSM library for domain application state
+# 15. Use Django-FSM library for domain request state
 
 Date: 2022-11-03
 
@@ -10,12 +10,12 @@ Accepted
 
 The applications that registrants submit for domains move through a variety of
 different states or stages as they are processed by CISA staff.  Traditionally,
-there would be a “domain application” data model with a “status” field. The
+there would be a “domain request” data model with a “status” field. The
 rules in the application code that control what changes are permitted to the
 statuses are called “domain logic”.
 
 In a large piece of software, domain logic often spreads around the code base
-because while handling a single request like “mark this application as
+because while handling a single request like “mark this domain request as
 approved”, requirements can be enforced at many different points during the
 process.
 
@@ -28,7 +28,7 @@ states and can change states (or “transition”) according to fixed rules.
 We will use the django-fsm library to represent the status of our domain
 registration applications as a finite state machine. The library allows us to
 list what statuses are possible and describe which state transitions are
-possible (e.g. Can an approved application ever be marked as “in-process”?).
+possible (e.g. Can an approved domain request ever be marked as “in-process”?).
 
 ## Consequences
 

docs/architecture/decisions/0016-django-form-wizard.md

@@ -8,17 +8,17 @@ Accepted
 
 ## Context
 
-The application form by which registrants apply for a .gov domain is presented over many pages.
+The domain request form by which registrants apply for a .gov domain is presented over many pages.
 
-Because we use server-side rendering, each page of the application is a unique HTML page with form fields surrounded by a form tag.
+Because we use server-side rendering, each page of the domain request is a unique HTML page with form fields surrounded by a form tag.
 
-Needing a way to coordinate state between the pages as a user fills in their application, we initially used the Form wizard from [django-formtools](https://django-formtools.readthedocs.io/en/latest/wizard.html). This eventually proved unworkable due to the lack of native ability to have more than one Django form object displayed on a single HTML page.
+Needing a way to coordinate state between the pages as a user fills in their domain request, we initially used the Form wizard from [django-formtools](https://django-formtools.readthedocs.io/en/latest/wizard.html). This eventually proved unworkable due to the lack of native ability to have more than one Django form object displayed on a single HTML page.
 
 However, a significant portion of the user workflow had already been coded, so it seemed prudent to port some of the formtools logic into our codebase.
 
 ## Decision
 
-To maintain each page of the domain application as its own Django view class, inheriting common code from a parent class.
+To maintain each page of the domain request as its own Django view class, inheriting common code from a parent class.
 
 To maintain Django form and formset class in accordance with the Django models whose data they collect, independently of the pages on which they appear.
 

docs/architecture/decisions/0017-ses-email.md

@@ -9,7 +9,7 @@ Approved
 ## Context
 
 Our application needs to be able to send email to applicants for various
-purposes including notifying them that their application has been submitted.
+purposes including notifying them that their domain request has been submitted.
 We need infrastructure for programmatically sending email. Amazon Web Services
 (AWS) provides the Simple Email Service (SES) that can do that. CISA can
 provide access to AWS SES for our application.

docs/architecture/decisions/0021-django-admin.md

@@ -8,8 +8,7 @@ Accepted
 
 ## Context
 
-CISA needs a way to perform administrative actions to manage the new get.gov application as well as the .gov domain
-application requests submitted. Analysts need to be able to view, review, and approve domain applications. Other
+CISA needs a way to perform administrative actions to manage the new get.gov application as well as the .gov domain requests submitted. Analysts need to be able to view, review, and approve domain requests. Other
 dashboard views, reports, searches (with filters and sorting) are also highly desired.
 
 ## Decision

docs/architecture/decisions/0022-submit-domain-request-user-flow.md

@@ -8,13 +8,13 @@ Accepted
 
 ## Context
 
-Historically, the .gov vendor managed initial identity verification and organizational affiliation for users that request a .gov domain. With the new registrar, _any user with a valid Login.gov account_ will be able to make a request. As a primary layer of abuse prevention (i.e., DDoSing the registry program with illegitimate requests), we need a way to stop new users from submitting multiple domain requests before they are known to the .gov registry. In this case, "known" means they have at least one approved domain application or existing domain.
+Historically, the .gov vendor managed initial identity verification and organizational affiliation for users that request a .gov domain. With the new registrar, _any user with a valid Login.gov account_ will be able to make a request. As a primary layer of abuse prevention (i.e., DDoSing the registry program with illegitimate requests), we need a way to stop new users from submitting multiple domain requests before they are known to the .gov registry. In this case, "known" means they have at least one approved domain request or existing domain.
 
 ## Considered Options
 
-**Option 1:** Users will not be able to submit any new applications if they have 0 prior approved applications OR prior registered .gov domains. We would add a page alert informing the user that they cannot submit their application because they have an application in one of these "3" statuses (Submitted, In Review or Action Needed). They would still be able to create and edit new applications, just not submit them. The benefits of this option are that it would allow users to have multiple applications essentially in "draft mode" that are queued up and ready for submission after they are permitted to submit.
+**Option 1:** Users will not be able to submit any new applications if they have 0 prior approved applications OR prior registered .gov domains. We would add a page alert informing the user that they cannot submit their application because they have a domain request in one of these "3" statuses (Submitted, In Review or Action Needed). They would still be able to create and edit new applications, just not submit them. The benefits of this option are that it would allow users to have multiple applications essentially in "draft mode" that are queued up and ready for submission after they are permitted to submit.
 
-**Option 2:** Users will not be able to submit any new applications if they have 0 prior approved applications OR prior registered .gov domains. Additionally, we would remove the ability to edit any application with the started/withdrawn/rejected status, or start a new application. The benefit of this option is that a user would not be able to begin an action (submitting an application) that they are not allowed to complete.
+**Option 2:** Users will not be able to submit any new applications if they have 0 prior approved applications OR prior registered .gov domains. Additionally, we would remove the ability to edit any application with the started/withdrawn/rejected status, or start a new application. The benefit of this option is that a user would not be able to begin an action (submitting a domain request) that they are not allowed to complete.
 
 ## Decision
 

docs/architecture/diagrams/get.gov registrar deployment.puml

@@ -18,13 +18,13 @@ Deployment_Node(aws, "AWS GovCloud", "Amazon Web Services Region") {
             Deployment_Node(organization, "get.gov organization") {
                 Deployment_Node(sandbox, "sandbox space") {
                     System_Boundary(dashboard_sandbox, "get.gov registrar") {
-                        Container(getgov_app_sandbox, "Registrar Application", "Python, Django", "Delivers static HTML/CSS and forms")
+                        Container(getgov_app_sandbox, "Registrar Domain Request", "Python, Django", "Delivers static HTML/CSS and forms")
                         ContainerDb(dashboard_db_sandbox, "sandbox PostgreSQL Database", "AWS RDS", "Stores agency information and reports")
                     }
                 }
                 Deployment_Node(stable, "stable space") {
                     System_Boundary(dashboard_stable, "get.gov registrar") {
-                        Container(getgov_app_stable, "Registrar Application", "Python, Django", "Delivers static HTML/CSS and forms")
+                        Container(getgov_app_stable, "Registrar Domain Request", "Python, Django", "Delivers static HTML/CSS and forms")
                         ContainerDb(dashboard_db_stable, "stable PostgreSQL Database", "AWS RDS", "Stores agency information and reports")
                     }
                 }

docs/architecture/diagrams/model_timeline.md

@@ -3,9 +3,9 @@
 This diagram connects the data models along with various workflow stages.
 
 1. The applicant starts the process at `/request` interacting with the
-   `DomainApplication` object.
+   `DomainRequest` object.
 
-2. The analyst approves the application using the `DomainApplication`'s
+2. The analyst approves the domain request using the `DomainRequest`'s
    `approve()` method which creates many related objects: `UserDomainRole`,
    `Domain`, and `DomainInformation`.
 
@@ -36,8 +36,8 @@ $ docker run -v $(pwd):$(pwd) -w $(pwd) -it plantuml/plantuml -tsvg model_timeli
 allowmixing
 left to right direction
 
-class DomainApplication {
-  Application for a domain
+class DomainRequest {
+  Request for a domain
   --
   creator (User)
   investigator (User)
@@ -66,7 +66,7 @@ note left of User
   <b>username</b> is the Login UUID
 end note
 
-DomainApplication -l- User : creator, investigator
+DomainRequest -l- User : creator, investigator
 
 class Contact {
   Contact info for a person
@@ -80,7 +80,7 @@ class Contact {
   --
 }
 
-DomainApplication *-r-* Contact : authorizing_official, submitter, other_contacts
+DomainRequest *-r-* Contact : authorizing_official, submitter, other_contacts
 
 class DraftDomain {
   Requested domain
@@ -89,7 +89,7 @@ class DraftDomain {
   --
 }
 
-DomainApplication -l- DraftDomain : requested_domain
+DomainRequest -l- DraftDomain : requested_domain
 
 class Domain {
   Approved domain
@@ -99,21 +99,21 @@ class Domain {
   <b>EPP methods</b>
 }
 
-DomainApplication .right[#blue].> Domain : approve()
+DomainRequest .right[#blue].> Domain : approve()
 
 class DomainInformation {
   Registrar information on a domain
   --
   domain (Domain)
-  domain_application (DomainApplication)
+  domain_request (DomainRequest)
   security_email
   --
   Request information...
 }
 
 DomainInformation -- Domain
-DomainInformation -- DomainApplication
-DomainApplication .[#blue].> DomainInformation : approve()
+DomainInformation -- DomainRequest
+DomainRequest .[#blue].> DomainInformation : approve()
 
 class UserDomainRole {
   Permissions
@@ -125,7 +125,7 @@ class UserDomainRole {
 }
 UserDomainRole -- User
 UserDomainRole -- Domain
-DomainApplication .[#blue].> UserDomainRole : approve()
+DomainRequest .[#blue].> UserDomainRole : approve()
 
 class DomainInvitation {
   Email invitations sent
@@ -139,10 +139,10 @@ DomainInvitation -- Domain
 DomainInvitation .[#green].> UserDomainRole : User.on_each_login()
 
 actor applicant #Red
-applicant -d-> DomainApplication : **/request**
+applicant -d-> DomainRequest : **/request**
 
 actor analyst #Blue
-analyst -[#blue]-> DomainApplication : **approve()**
+analyst -[#blue]-> DomainRequest : **approve()**
 
 actor user1 #Green
 user1 -[#green]-> Domain : **/domain/<id>/nameservers**

docs/architecture/diagrams/models_diagram.md

@@ -39,8 +39,8 @@ class "registrar.Contact <Registrar>" as registrar.Contact #d6f4e9 {
 registrar.Contact -- registrar.User
 
 
-class "registrar.DomainApplication <Registrar>" as registrar.DomainApplication #d6f4e9 {
-    domain application
+class "registrar.DomainRequest <Registrar>" as registrar.DomainRequest #d6f4e9 {
+    domain request
     --
     + id (BigAutoField)
     + created_at (DateTimeField)
@@ -77,15 +77,15 @@ class "registrar.DomainApplication <Registrar>" as registrar.DomainApplication #
     # other_contacts (ManyToManyField)
     --
 }
-registrar.DomainApplication -- registrar.User
-registrar.DomainApplication -- registrar.User
-registrar.DomainApplication -- registrar.Contact
-registrar.DomainApplication -- registrar.DraftDomain
-registrar.DomainApplication -- registrar.Domain
-registrar.DomainApplication -- registrar.Contact
-registrar.DomainApplication *--* registrar.Website
-registrar.DomainApplication *--* registrar.Website
-registrar.DomainApplication *--* registrar.Contact
+registrar.DomainRequest -- registrar.User
+registrar.DomainRequest -- registrar.User
+registrar.DomainRequest -- registrar.Contact
+registrar.DomainRequest -- registrar.DraftDomain
+registrar.DomainRequest -- registrar.Domain
+registrar.DomainRequest -- registrar.Contact
+registrar.DomainRequest *--* registrar.Website
+registrar.DomainRequest *--* registrar.Website
+registrar.DomainRequest *--* registrar.Contact
 
 
 class "registrar.DomainInformation <Registrar>" as registrar.DomainInformation #d6f4e9 {
@@ -95,7 +95,7 @@ class "registrar.DomainInformation <Registrar>" as registrar.DomainInformation #
     + created_at (DateTimeField)
     + updated_at (DateTimeField)
     ~ creator (ForeignKey)
-    ~ domain_application (OneToOneField)
+    ~ domain_request (OneToOneField)
     + organization_type (CharField)
     + federally_recognized_tribe (BooleanField)
     + state_recognized_tribe (BooleanField)
@@ -124,7 +124,7 @@ class "registrar.DomainInformation <Registrar>" as registrar.DomainInformation #
     --
 }
 registrar.DomainInformation -- registrar.User
-registrar.DomainInformation -- registrar.DomainApplication
+registrar.DomainInformation -- registrar.DomainRequest
 registrar.DomainInformation -- registrar.Contact
 registrar.DomainInformation -- registrar.Domain
 registrar.DomainInformation -- registrar.Contact

docs/developer/README.md

@@ -78,7 +78,7 @@ Get the secrets from Cloud.gov by running `cf env getgov-YOURSANDBOX`. More info
 The endpoint /admin can be used to view and manage site content, including but not limited to user information and the list of current applications in the database. To be able to view and use /admin locally:
 
 1. Login via login.gov
-2. Go to the home page and make sure you can see the part where you can submit an application
+2. Go to the home page and make sure you can see the part where you can submit a domain request
 3. Go to /admin and it will tell you that UUID is not authorized, copy that UUID for use in 4
 4. in src/registrar/fixtures_users.py add to the `ADMINS` list in that file by adding your UUID as your username along with your first and last name. See below:
 
@@ -93,14 +93,14 @@ The endpoint /admin can be used to view and manage site content, including but n
  ]
 ```
 
-5. In the browser, navigate to /admin. To verify that all is working correctly, under "domain applications" you should see fake domains with various fake statuses.
+5. In the browser, navigate to /admin. To verify that all is working correctly, under "domain requests" you should see fake domains with various fake statuses.
 6. Add an optional email key/value pair
 
 ### Adding an Analyst to /admin
 Analysts are a variant of the admin role with limited permissions. The process for adding an Analyst is much the same as adding an admin:
 
 1. Login via login.gov (if you already exist as an admin, you will need to create a separate login.gov account for this: i.e. [email protected])
-2. Go to the home page and make sure you can see the part where you can submit an application
+2. Go to the home page and make sure you can see the part where you can submit a domain request
 3. Go to /admin and it will tell you that UUID is not authorized, copy that UUID for use in 4 (this will be a different UUID than the one obtained from creating an admin)
 4. in src/registrar/fixtures_users.py add to the `STAFF` list in that file by adding your UUID as your username along with your first and last name. See below:
 
@@ -145,7 +145,7 @@ You can change the logging verbosity, if needed. Do a web search for "django log
 
 ## Mock data
 
-[load.py](../../src/registrar/management/commands/load.py) called from docker-compose (locally) and reset-db.yml (upper) loads the fixtures from [fixtures_user.py](../../src/registrar/fixtures_users.py) and [fixtures_applications.py](../../src/registrar/fixtures_applications.py), giving you some test data to play with while developing.
+[load.py](../../src/registrar/management/commands/load.py) called from docker-compose (locally) and reset-db.yml (upper) loads the fixtures from [fixtures_user.py](../../src/registrar/fixtures_users.py) and [fixtures_domain_requests.py](../../src/registrar/fixtures_domain_requests.py), giving you some test data to play with while developing.
 
 See the [database-access README](./database-access.md) for information on how to pull data to update these fixtures.