-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#3317: Don't allow non-org model domain requests for federal agencies in a portfolio [ZA] #3408
base: main
Are you sure you want to change the base?
Conversation
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
1 similar comment
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
{% if domain_request.organization_name %} | ||
{% if domain_request.unlock_organization_contact %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change syncs the unlock state of each step to the incomplete dialog on the domain request page -- which further reduces code duplication.
I've just added it to this specific step and unlock_other_contacts for now
@@ -10,3 +11,18 @@ def flag_is_active_for_user(user, flag_name): | |||
request = HttpRequest() | |||
request.user = user | |||
return flag_is_active(request, flag_name) | |||
|
|||
|
|||
def flag_is_active_anywhere(flag_name): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We intend to use the organization_requests flag kind of like a y/n switch, where we intend to turn it on for everyone at once. This function is a drop-in replacement for doing flag_is_active(request=None, "organization_requests"
because that relies moreso on an implementation bug and breaks when only specific users are defined. So - relying on something we define rather than a hack
@dave-kennedy-ecs -- you worked on this area extensively though, any thoughts on this? An alternative is of course just using said approach with those caveats
🥳 Successfully deployed to developer sandbox za. |
) | ||
|
||
self.domain_request.other_contacts.add(other) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test will be moved to another file. I'm leaving it in test_models for now so its easier to read the git log
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
return ( | ||
self.federal_agency is not None | ||
or self.organization_name is not None | ||
or self.address_line1 is not None | ||
or self.city is not None | ||
or self.state_territory is not None | ||
or self.zipcode is not None | ||
or self.urbanization is not None | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the original logic for this unlock_contact page - but would we want this to be an and statement on all required fields?
def _is_interstate_complete(self): | ||
# Interstate -> "About your organization" page can't be empty | ||
return self.about_your_organization is not None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of these functions actually presently exist on the DomainRequestWizard!
@@ -434,20 +424,38 @@ def db_check_for_unlocking_steps(self): | |||
Queries the DB for a domain request and returns a list of unlocked steps.""" | |||
return [key for key, is_unlocked_checker in self.unlocking_steps.items() if is_unlocked_checker(self)] | |||
|
|||
def form_is_complete(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a modification of the old logic, org_steps_complete = len(self.db_check_for_unlocking_steps()) == len(self.steps)
. The domain request form on the org model had a key difference as compared to the standard one: it didn't have "conditional" steps. Length comparison only works without those, so this approach is more complete and takes into account all required steps and all currently unlocked steps
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
Ticket
Resolves #3317
Changes
Context for reviewers
In the near future, we intend to enable the organization_requests waffle flag. When we do so, we anticipate that some users, particularly those with started domain requests, may not be on said portfolio. Since federal agency and portfolio are the same contextually -- and since we only want "verified" users to be making requests -- we want to hide "in-use" federal agencies for those users from the dropdown list.
To achieve this, I opted to not set the underlying federal agency to none. I instead am targeting the queryset, and I modified the organization_contact step unlock logic to take this into account. This logic is then piped (all using the same function) to the summary page as well, and the final _form_complete step.
During the ticket that implemented the domain request flow for portfolio, this form complete logic was simplified by only using a length compare on db_check_for_unlocking_steps. It was chosen at the time to keep the old logic intact, but this PR finishes the refactor of that area and cleans that bit of the code up. The reason is that I had to take the portfolio logic into account on the summary page, form compete page, and also the side bar unlock.
It is worth noting that a script will be ran that will clean up the federal agency field on started domain requests, so this logic will primarily target new domain requests after that is ran. But it is designed to be robust enough to handle misses.
Setup
Testing new domain requests
AMTRAK
.Testing existing domain requests
AMTRAK
.Code Review Verification Steps
As the original developer, I have
Satisfied acceptance criteria and met development standards
Ensured code standards are met (Original Developer)
Validated user-facing changes (if applicable)
As a code reviewer, I have
Reviewed, tested, and left feedback about the changes
Validated user-facing changes as a developer
Note: Multiple code reviewers can share the checklists above, a second reviewer should not make a duplicate checklist. All checks should be checked before approving, even those labeled N/A.
As a designer reviewer, I have
Verified that the changes match the design intention
Validated user-facing changes as a designer
References
Screenshots