Repository: cisagov/manage.get.gov

Issue:
Bug: Starting a new application takes user back to existing application
When I try to start a 2nd new application the button on the dashboard takes me into an existing application.

To replicate
1. Click "Start a new domain request" on the dashboard
2. Fill out the first few pages of the form to make it distinct 
3. Navigate back to home 
4. Click "Start a new domain request" on the dashboard
5. Check the first few page you filled out before to confirm this is the same application

Additionally, other bugs associated with this request:

AC:

- Update functionality to allow for multiple applications in the same session

See: https://gsa-tts.slack.com/archives/C03QM0JGSQG/p1675441631322649

A note for anyone picking this up to fix it: this is more challenging than it first appears. The current application is being saved in state to allow a user to navigate between the pages of the application without losing progress. We don't have any ability to know when they have "exited" the application. (We should avoid any JavaScript hacks to try to "guess" since all of these approaches are buggy and rely on the user having JavaScript enabled/working.) We could *very easily* reset state each time they visit the "front page" of an application (as they do when clicking "apply"), however, we would then need to ensure they had some way of getting back to previously saved applications (since the "front page" will now always show them a fresh blank application).

The code to fix this bug might be pretty simple, but there are plenty of ramifications to think through. 🙂 


Discussion:
Designer considerations @PaulKuykendall @Katherine-Osos 
Apparently the original purpose for this start new application button was to resume the current application, hence the bug shows that the user sees the most recent application. Therefore, one ramification of changing this to be display a fully new application is a user may not find their most recent app as easily. Also if the user keeps clicking start a new application, they will get more and more in progress applications but currently will have no way to delete them from the list. 

Some suggestions that came up when looking this over is that you all may want two buttons "resume current" and "start new application" or have a warning to the user that they already have an in progress app. 

Engineering should confirm with design before implementing this ticket that there are no requirement changes from what is described in the current AC. 
My immediate thoughts are your second suggestion Alysia — to warn the user that they have one in progress and giving the option to either resume or start a new application. This has its own implications to consider. Design will review this and discuss next week. 
As Gaby noted, the designers will discuss on Monday. But in preparation, a couple questions: 
- Why isn't there a "delete" option for applications that have not been submitted yet? Are there technical reasons why that can't be included? 
- Applicants could, in theory, have a couple apps started and are waiting to confirm a few details before submitting. So "resume current" could apply to multiple apps (and there's already an "Edit" button next to each in-progress app that does the same thing.) Is there a concern that people won't understand the "Edit" button?
To summarize our conversation: 

- as a general rule, we want to disincentivize folks from submitting multiple applications.
- Some user groups will need the ability to submit more than one application at once, these groups include federal agencies and IT contractors that manage domains for multiple government orgs
- For MVP, @h-m-f-t has recommended we gate them at one application per user at a time. If they fall under the two groups mentioned above, we should offer a line of communication to request the ability to create more than one application. 
- We'll need messaging that gives them that line to CISA and point them to some FAQs to help them determine whether they really do need multiple domains and not just sub-domains.
- If they are determined to have a real need for submitting multiple applications at once, there will be a future engineering need to figure out how they would be ungated. @abroddrick 


There's currently no technical barrier preventing a user from submitting multiple requests. Also, in my testing, coming in fresh and clicking START NEW APPLICATION will start a new application. Clicking the button again in the same session will edit the application that was already started. Clicking START NEW APPLICATION in a new session (I used another browser) will indeed start a new application. Clicking on an EDIT button will reset the application tracker (the locks in the sidenav) but will always pull the correct data from the DB

**In other words:** 

Multiple applications but one status tracker per session.

- Clicking EDIT will land you on screen one for the relevant application, with the right data loaded on all screens (even the locked ones). 
- Clicking START NEW APPLICATION in a fresh session will start a new application, no matter how many other active applications you may have.
- You can come back to a previously started application _in a given session_ and can continue where you left off.
- You can come back to a previously edited application _in a given session_ and can continue where you left off.
- Clicking START NEW APPLICATION in a session where you have already started an application OR edited an existing one, you'll just load the latest application you were last looking at. <- This is the bug
I can see 2 major design approaches. 1) Track each application separately, in session or in the DB and 2) Just reset the tracker when you click start new application. 1 will probably be very expensive. 2 can probably be done by creating 2 first pages in the stepper form, one for new apps and one for existing apps. It also means that whenever you start a new application in a session, going back to an existing application that you were editing will land you on the first page (which is similar to current behavior).
From Gaby, 

> For MVP, @h-m-f-t has recommended we gate them at one application per user at a time. If they fall under the two groups mentioned above, we should offer a line of communication to request the ability to create more than one application.

@rachidatecs - I believe that we need to change the AC from this bug to "Allow only ONE in-progress application per identity, regardless of session or state." (This is the MVP functionality) So, no irrespective of session or state or browse or compute, a logged in user may have just one.

1. User may start, edit, submit, withdraw, or DISCARD an application in progress.
2. We need to create informational content "Need more than one domain??? Contact CISA here...." to get help. There needs to be a conversation (for now) about why multiple domains are needed and whether subs are more appropriate.
3. If, in fact, a requestor legitimately needs a "bundle" of domains, then we need to create special Analyst tooling to accommodate that. This should be a rare/occasional case.

@rachidatecs, @abroddrick  - how does that affect the engineering position? 
 One in-progress application will require putting some new guardrails on the user model and the Manage your domains UI (and some UI/UX revisions there as well). We could/should probably leave the setpper form and session storage alone.

Special Analyst tooling: can't speak to that without more details.
There's another level of nuance here that I think we're still missing and I didn't touch on in my earlier comment. From what I'm seeing, there are two user groups:

User group 1: new registrants who have never submitted an application. These users should only be allowed one in-progress application. 
User group 2: registrants who have submitted an application and had it approved. These users can submit more than one application. 

I'm getting this from our status transitions doc, specifically:


> ### **Domain applications**
> **Started**
> An applicant has begun to fill in their data to request a .gov domain.
> 
> Actions available:
> 
> - Edit any fields of the application (subject to normal user permissions)
> - Delete application
> 
> 
> Actions forbidden:
> 
> - Edit nameservers and DNSSEC data for unapproved domain
> - Add security email for unapproved domain
> - Add domain management contacts for unapproved domain
> 
> [none] → started
> Preconditions:
> 
> - User is logged in
> - User has either 0 applications or 1+ approved applications _(user with no previously approved applications cannot submit more than one application)_
Noting that this bug is 🚫blocked🚫 until we have further discussion with business, product, and design.
Thanks for the bump, Gaby. Your [comment last week](https://github.com/cisagov/getgov/issues/394#issuecomment-1589511288) gets this exactly right.

Resolving patch:
diff --git a/src/registrar/views/application.py b/src/registrar/views/application.py
--- a/src/registrar/views/application.py
+++ b/src/registrar/views/application.py
@@ -67,7 +67,7 @@ class ApplicationWizard(TemplateView):
     URL_NAMESPACE = "application"
     # name for accessing /application/<id>/edit
     EDIT_URL_NAME = "edit-application"
-
+    NEW_URL_NAME = "/register/"
     # We need to pass our human-readable step titles as context to the templates.
     TITLES = {
         Step.ORGANIZATION_TYPE: _("Type of organization"),
@@ -144,6 +144,7 @@ def application(self) -> DomainApplication:
         self._application = DomainApplication.objects.create(
             creator=self.request.user,  # type: ignore
         )
+
         self.storage["application_id"] = self._application.id
         return self._application
 
@@ -195,7 +196,6 @@ def from_model(self, attribute: str, default, *args, **kwargs):
 
     def get(self, request, *args, **kwargs):
         """This method handles GET requests."""
-
         current_url = resolve(request.path_info).url_name
 
         # if user visited via an "edit" url, associate the id of the
@@ -213,12 +213,15 @@ def get(self, request, *args, **kwargs):
         #     send users "to the application wizard" without needing to
         #     know which view is first in the list of steps.
         if self.__class__ == ApplicationWizard:
+            # if starting a new application, clear the storage
+            if request.path_info == self.NEW_URL_NAME:
+                del self.storage
+
             return self.goto(self.steps.first)
 
         self.steps.current = current_url
         context = self.get_context_data()
         context["forms"] = self.get_forms()
-
         return render(request, self.template_name, context)
 
     def get_all_forms(self, **kwargs) -> list:
@@ -242,7 +245,6 @@ def get_forms(self, step=None, use_post=False, use_db=False, files=None):
         and from the database if `use_db` is True (provided that record exists).
         An empty form will be provided if neither of those are true.
         """
-
         kwargs = {
             "files": files,
             "prefix": self.steps.current,


Test patch:
diff --git a/src/registrar/tests/test_views.py b/src/registrar/tests/test_views.py
--- a/src/registrar/tests/test_views.py
+++ b/src/registrar/tests/test_views.py
@@ -145,7 +145,6 @@ def test_application_form_submission(self):
         # ---- TYPE PAGE  ----
         type_form = type_page.form
         type_form["organization_type-organization_type"] = "federal"
-
         # test next button and validate data
         self.app.set_cookie(settings.SESSION_COOKIE_NAME, session_id)
         type_result = type_page.form.submit()
@@ -161,6 +160,7 @@ def test_application_form_submission(self):
         # ---- FEDERAL BRANCH PAGE  ----
         # Follow the redirect to the next form page
         self.app.set_cookie(settings.SESSION_COOKIE_NAME, session_id)
+
         federal_page = type_result.follow()
         federal_form = federal_page.form
         federal_form["organization_federal-federal_type"] = "executive"