Find-replace "domain application", "domain_application", "domain-application" with "domain request", "domain_request", "domain-request". Preserved camel-cases through strict find-replace conditions.

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,7 +10,7 @@ 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”.
 

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

@@ -18,7 +18,7 @@ However, a significant portion of the user workflow had already been coded, so i
 
 ## 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/0022-submit-domain-request-user-flow.md

@@ -8,7 +8,7 @@ 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
 

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 application using the `DomainRequest`'s
    `approve()` method which creates many related objects: `UserDomainRole`,
    `Domain`, and `DomainInformation`.
 
@@ -36,7 +36,7 @@ $ docker run -v $(pwd):$(pwd) -w $(pwd) -it plantuml/plantuml -tsvg model_timeli
 allowmixing
 left to right direction
 
-class DomainApplication {
+class DomainRequest {
   Application for a domain
   --
   creator (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