Add new suborganizations on domain request approval #3025
Comments
gabydisarli
changed the title
gabydisarli
added
design
katypies
changed the title
katypies
added
Feature: 🧮 Analyst Experience
@katypies / @gabydisarli Should we also include rejected and ineligible here? |
|
@zandercymatics Good question. For rejected, I'd say include. Ineligible too, but, I imagine that won't be an issue in org model right? |
|
@zandercymatics - we're not creating a suborg upon rejection or ineligible, right? I think we're only creating a suborg if the initial request was approved. So, we shouldn't need to "undo" the creation of the suborg, since it wouldn't have been created if the request was put into a different state besides approved? |
|
@katypies I am referring to the pathway of APPROVED -> REJECTED or APPROVED -> INELIGIBLE (so for instance an analyst accidentally approves when they meant to reject so they swap from approved to rejected). A suborg is only created on approval, but we need to do some cleanup after the fact if we change states in that scenario.
Awesome, thanks. To answer your question: for ineligible I see that being very rare but I can see a path of where it may be desired. For example, say an org-level administrative mistake occurred and a user was granted request permissions when they weren't supposed to have them, or they otherwise misuse that permission. Said org gets an approval email and wants to rectify it after the fact, hence requiring this flow. I may just be too deep in theoretical territory though, bcc: @h-m-f-t |
|
Modified the ticket to add rejection and ineligible since it seems like we generally want that for now. I can change it back later if the result of this conversation differs, though |
|
Hey Zander, we just discussed this in the org model meeting and agree with your direction. cc: @h-m-f-t @katypies @zandercymatics |
|
@CocoByte assigned you as you are assisting with the PR as it is in review |
Description
When a portfolio user makes a new domain request, they can specify that the request is for the parent org, an existing suborg, or a new suborg. If they add a new suborg, we don't want that suborg added to the suborg table until the request is approved, since an analyst might request a change, or make a change directly to the suborg on the request.
Once the request is approved, though, the suborganization should be added as part of the request approval, to the suborganizations table.
Acceptance Criteria
---in our system) which will remove all suborg data from the request (okay to have this apply on save)Additional Context
After some discussion on ticket #2935, we determined that we'd like a quick and easy solution for analysts before we build a more robust flow to allow them to approve, update or deny manual suborganizations requests coming in from portfolio / org model users
Issue Links
The text was updated successfully, but these errors were encountered: