Describe the Bug
A clear and concise description of what the bug is.
While testing the story that changed the way we displayed the caption with the surviving spouse (#10152), we noticed some discrepancies with how the "c/o" text is displayed.
When there is a c/o value added to the petitioner in various case types, the c/o information isn't consistently being displayed. The display of the "c/o" changes throughout the petition creation flow, the Petition QC flow, as well as how it is displayed on the party information card and printable docket record after service of the Petition to the IRS.
There are two scenarios outlined below. 1) Surviving Spouse as well as any other case type with a c/o value, and 2) Petitioner and Deceased Spouse. There are some slight differences between the two scenarios.
1) The c/o value is present prior to service of the petition, but then later disappears from display after service of petition.
2) We see a "c/o undefined" value appear on the petitioner after service of petition.
Business Impact/Reason for Severity
low
In which environment did you see this bug?
Test
Who were you logged in as?
Court users, Public users, Parties to a case
What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.)
Testing other functionality
To Reproduce
Steps to reproduce the behavior:
Surviving Spouse Case types and any other Case type that has a "c/o" value (guardian, trust, etc.)
log in as a petitioner
Click Create Case
Upload your documents, and be sure to select Other, and then select Deceased Spouse
Fill in the deceased spouse information, as well as the surviving spouse info. Notice at this point, the field name is Name of Surviving Spouse. (See Screen Grab 1 below).
Next, finish entering your info and get to the review your filing page. Notice at this point there is a c/o in front of the Surviving Spouse's name. (See Screen Grab 2 below).
Submit the case to the Court, and then navigate back to the case and click on the Case information/Parties tab. Notice at this point, the petitioner card displays a "c/o" in front of the Surviving Spouses Name. (See Screen Grab 3 below).
Log out and log back in as a Petitions Clerk. QC the Petition. Notice that the field name is "Name of Surviving spouse". (See Screen Grab 4 below).
Click Review and Serve button. Notice on the Review and Serve Petition page, the Petitioner's information has the c/o next to the Surviving Spouse's name. (See Screen Grab 5 below).
Serve the Petition to the IRS, and then go back into the case. Click on the Case information/Parties tab. Notice that the c/o text has disappeared from the petitioner card. (See Screen Grab 6 below).
Click on the printable docket record link. Notice that there is no c/o information displayed here either. (See Screen Grab 7 below).
It DOES display appropriately on the address on the NOTR. (See Screen Grab 8 below).
Petitioner and Deceased Spouse Case type
log in as a petitioner
Click Create Case
Upload your documents, and be sure to select Other, and then select Petitioner and Spouse, indicate your spouse is deceased
Fill in the surviving spouse info, followed by the deceased spouse info. Notice at this point, the field name is "In Care of": (See Screen Grab 9 below).
Next, finish entering your info and get to the review your filing page. Notice at this point there is a c/o in front of the "In care of" person's name. (See Screen Grab 10 below).
Submit the case to the Court, and then navigate back to the case and click on the Case information/Parties tab. Notice at this point, the petitioner card displays a "c/o" in front of the "In care of's" Name. (See Screen Grab 11 below).
Log out and log back in as a Petitions Clerk. QC the Petition. Notice that the field name is "In Care of". (See Screen Grab 12 below).
Click Review and Serve button. Notice on the Review and Serve Petition page, the Spouse's information has the c/o next to the In Care of's name. (See Screen Grab 13 below).
Serve the Petition to the IRS, and then go back into the case. Click on the Case information/Parties tab. Notice that the c/o text is still present for the In Care of, but now we are also seeing a "c/o undefined" for the Petitioner. (See Screen Grab 14 below).
Click on the printable docket record link. Notice that there is no c/o information displayed for the deceased spouse, but there is the "c/o undefined" displaying for the petitioner. (See Screen Grab 15 below).
The NOTR for the petitioner and deceased spouse case doesn't serve the person listed in the "In care of" for the deceased spouse.
Expected Behavior
A clear and concise description of what you expected to happen.
1) For any case type that has a c/o value for a petitioner, the "c/o" text should remain on the petitioner card before the in care of persons name, and the "c/o" text should display as such on the printable docket record throughout the case creation/QC/and after service of the petition.
2) For Petitioner and Deceased spouse cases, we need to remove the "c/o undefined" that appears on the Petitioner card and printable docket record after service of the petition, as well as display the c/o and name of the person that is in care of for the deceased petitioner on the printable docket record.
Actual Behavior
A clear and concise description of what actually happened.
1) The c/o text is disappearing from display on the petitioner card as well as the printable docket record after service of the petition
2) Text that states "c/o undefined" appears on the petitioner card and on the printable docket record and the c/o for the deceased petitioner does not display on the printable docket record.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]
Smartphone (please complete the following information):
Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]
Cause of Bug, If Known
Process for Logging a Bug:
Complete the above information
Add a severity tag (Critical, High Severity, Medium Severity or Low Severity). See below for priority definition.
Severity Definition:
Critical Defect
Blocks entire system's or module’s functionality
No workarounds available
Testing cannot proceed further without bug being fixed.
High-severity Defect
Affects key functionality of an application
There's a workaround, but not obvious or easy
App behaves in a way that is strongly different from the one stated in the requirements
Medium-severity Defect
A minor function does not behave in a way stated in the requirements.
Workaround is available and easy
Low-severity Defect
Mostly related to an application’s UI
Doesn't need a workaround, because it doesn't impact functionality
Definition of Ready for Bugs(Created 10-4-21)
Definition used: A failure or flaw in the system which produces an incorrect or undesired result that deviates from the expected result or behavior. (Note: Expected results are use cases that have been documented in past user stories as acceptance criteria and test cases, and do not include strange behavior unrelated to use cases.)
The following criteria must be met in order for the development team to begin work on the bug.
The bug must:
Be focused on solving a user problem
Contain data for all fields in the bug template, so the team can pick it up and begin working immediately
Process: If the unexpected results are new use cases that have been identified, but not yet built, new acceptance criteria and test cases should be captured in a new user story and prioritized by the product owner.
If the Court is not able to reproduce the bug, add the “Unable to reproduce” tag. This will provide visibility into the type of support that may be needed by the Court. In the event that the Court cannot reproduce the bug, the Court will work with Flexion to communicate what type of troubleshooting help may be needed.
Definition of Done (Updated 4-14-21)
Product Owner
[ ] Bug fix has been validated in the Court's test environment
Engineering
[ ] Automated test scripts have been written
[ ] Field level and page level validation errors (front-end and server-side) integrated and functioning
[ ] Verify that language for docket record for internal users and external users is identical
Describe the Bug A clear and concise description of what the bug is. While testing the story that changed the way we displayed the caption with the surviving spouse (#10152), we noticed some discrepancies with how the "c/o" text is displayed.
When there is a c/o value added to the petitioner in various case types, the c/o information isn't consistently being displayed. The display of the "c/o" changes throughout the petition creation flow, the Petition QC flow, as well as how it is displayed on the party information card and printable docket record after service of the Petition to the IRS.
There are two scenarios outlined below. 1) Surviving Spouse as well as any other case type with a c/o value, and 2) Petitioner and Deceased Spouse. There are some slight differences between the two scenarios.
1) The c/o value is present prior to service of the petition, but then later disappears from display after service of petition. 2) We see a "c/o undefined" value appear on the petitioner after service of petition.
Business Impact/Reason for Severity low
In which environment did you see this bug? Test
Who were you logged in as? Court users, Public users, Parties to a case
What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.) Testing other functionality
To Reproduce Steps to reproduce the behavior: Surviving Spouse Case types and any other Case type that has a "c/o" value (guardian, trust, etc.)
Petitioner and Deceased Spouse Case type
Expected Behavior A clear and concise description of what you expected to happen. 1) For any case type that has a c/o value for a petitioner, the "c/o" text should remain on the petitioner card before the in care of persons name, and the "c/o" text should display as such on the printable docket record throughout the case creation/QC/and after service of the petition. 2) For Petitioner and Deceased spouse cases, we need to remove the "c/o undefined" that appears on the Petitioner card and printable docket record after service of the petition, as well as display the c/o and name of the person that is in care of for the deceased petitioner on the printable docket record.
Actual Behavior A clear and concise description of what actually happened. 1) The c/o text is disappearing from display on the petitioner card as well as the printable docket record after service of the petition 2) Text that states "c/o undefined" appears on the petitioner card and on the printable docket record and the c/o for the deceased petitioner does not display on the printable docket record.
Screenshots If applicable, add screenshots to help explain your problem.
Screen Grab 1 Private Zenhub Image
Screen Grab 2: Private Zenhub Image
Screen Grab 3: Private Zenhub Image
Screen Grab 4: Private Zenhub Image
Screen Grab 5: Private Zenhub Image
Screen Grab 6: Private Zenhub Image
Screen Grab 7: Private Zenhub Image
Screen Grab 8: Private Zenhub Image
Screen Grab 9: Private Zenhub Image
Screen Grab 10: Private Zenhub Image
Screen Grab 11: Private Zenhub Image
Screen Grab 12: Private Zenhub Image
Screen Grab 13: Private Zenhub Image
Screen Grab 14: Private Zenhub Image
Screen Grab 15: Private Zenhub Image
Desktop (please complete the following information):
Smartphone (please complete the following information):
Cause of Bug, If Known
Process for Logging a Bug:
Severity Definition:
Critical Defect Blocks entire system's or module’s functionality No workarounds available Testing cannot proceed further without bug being fixed.
High-severity Defect Affects key functionality of an application There's a workaround, but not obvious or easy App behaves in a way that is strongly different from the one stated in the requirements
Medium-severity Defect A minor function does not behave in a way stated in the requirements. Workaround is available and easy
Low-severity Defect Mostly related to an application’s UI Doesn't need a workaround, because it doesn't impact functionality
Definition of Ready for Bugs(Created 10-4-21)
Definition used: A failure or flaw in the system which produces an incorrect or undesired result that deviates from the expected result or behavior. (Note: Expected results are use cases that have been documented in past user stories as acceptance criteria and test cases, and do not include strange behavior unrelated to use cases.)
The following criteria must be met in order for the development team to begin work on the bug.
The bug must:
Process: If the unexpected results are new use cases that have been identified, but not yet built, new acceptance criteria and test cases should be captured in a new user story and prioritized by the product owner.
If the Court is not able to reproduce the bug, add the “Unable to reproduce” tag. This will provide visibility into the type of support that may be needed by the Court. In the event that the Court cannot reproduce the bug, the Court will work with Flexion to communicate what type of troubleshooting help may be needed.
Definition of Done (Updated 4-14-21)
Product Owner
Engineering
test
environment if prod-like data is required. Otherwise, deployed to anyexperimental
environment for review.