├── .github ├── ISSUE_TEMPLATE │ ├── bug-report.md │ ├── custom.md │ ├── devex-opex.md │ ├── feature_request.md │ ├── flaky-test.md │ ├── logging-improvement.md │ ├── offboarding.md │ ├── onboarding.md │ ├── team-experiment-template.md │ └── ustc-story-template.md ├── PULL_REQUEST_TEMPLATE │ ├── merge-to-master.md │ └── pr-to-ustc.md └── workflows │ ├── api.yml │ ├── client.yml │ ├── lint.yml │ ├── scripts.yml │ └── shared.yml └── README.md /.github/ISSUE_TEMPLATE/bug-report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug Report 3 | about: 'Template for USTC bugs. ' 4 | title: 'BUG: ' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the Bug** 11 | A clear and concise description of what the bug is. 12 | 13 | **Business Impact/Reason for Severity** 14 | 15 | **In which environment did you see this bug?** 16 | 17 | **Who were you logged in as?** 18 | 19 | **What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.)** 20 | 21 | **To Reproduce** 22 | Steps to reproduce the behavior: 23 | 1. Go to '...' 24 | 2. Click on '....' 25 | 3. Scroll down to '....' 26 | 4. See error 27 | 28 | **Expected Behavior** 29 | A clear and concise description of what you expected to happen. 30 | 31 | **Actual Behavior** 32 | A clear and concise description of what actually happened. 33 | **Screenshots** 34 | If applicable, add screenshots to help explain your problem. 35 | 36 | **Desktop (please complete the following information):** 37 | - OS: [e.g. iOS] 38 | - Browser [e.g. chrome, safari] 39 | - Version [e.g. 22] 40 | 41 | **Smartphone (please complete the following information):** 42 | - Device: [e.g. iPhone6] 43 | - OS: [e.g. iOS8.1] 44 | - Browser [e.g. stock browser, safari] 45 | - Version [e.g. 22] 46 | 47 | **Cause of Bug, If Known** 48 | 49 | 50 | **Process for Logging a Bug:** 51 | * Complete the above information 52 | * Add a severity tag (Critical, High Severity, Medium Severity or Low Severity). See below for priority definition. 53 | 54 | **Severity Definition:** 55 | * Critical Defect 56 | Blocks entire system's or module’s functionality 57 | No workarounds available 58 | Testing cannot proceed further without bug being fixed. 59 | 60 | * High-severity Defect 61 | Affects key functionality of an application 62 | There's a workaround, but not obvious or easy 63 | App behaves in a way that is strongly different from the one stated in the requirements 64 | 65 | * Medium-severity Defect 66 | A minor function does not behave in a way stated in the requirements. 67 | Workaround is available and easy 68 | 69 | * Low-severity Defect 70 | Mostly related to an application’s UI 71 | Doesn't need a workaround, because it doesn't impact functionality 72 | 73 | ## Definition of Ready for Bugs(Created 10-4-21) 74 | 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.) 75 | 76 | The following criteria must be met in order for the development team to begin work on the bug. 77 | 78 | The bug must: 79 | - Be focused on solving a user problem 80 | - Contain data for all fields in the bug template, so the team can pick it up and begin working immediately 81 | 82 | 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. 83 | 84 | 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. 85 | 86 | ## Definition of Done (Updated 4-14-21) 87 | **Product Owner** 88 | - [ ] Bug fix has been validated in the Court's test environment 89 | 90 | **Engineering** 91 | - [ ] Automated test scripts have been written 92 | - [ ] Field level and page level validation errors (front-end and server-side) integrated and functioning 93 | - [ ] Verify that language for docket record for internal users and external users is identical 94 | - [ ] New screens have been added to pa11y scripts 95 | - [ ] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html 96 | - [ ] READMEs, other appropriate docs and swagger/APIs fully updated 97 | - [ ] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required) 98 | - [ ] Interactors should validate entities before calling persistence methods 99 | - [ ] Code refactored for clarity and to remove any known technical debt 100 | - [ ] Deployed to the Court's `test` environment if prod-like data is required. Otherwise, deployed to any `experimental` environment for review. 101 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/custom.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Custom issue template 3 | about: Describe this issue template's purpose here. 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/devex-opex.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: USTC Devex/Opex Template 3 | about: Document Devex/Opex tasks for the USTC project 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | 12 | ## Pre-Conditions 13 | 14 | 15 | ## Acceptance Criteria 16 | 17 | 18 | ## Pain Avoided/Frustration Saved 19 | 20 | 21 | ## Breadth/Pervasiveness of Problem 22 | 23 | 24 | ## Complexity of Problem (Low, Medium, High) and Why it's Complex 25 | 26 | 27 | ## Notes 28 | 29 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: '' 6 | assignees: mmarcotte 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Describe alternatives you've considered** 17 | A clear and concise description of any alternative solutions or features you've considered. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the feature request here. 21 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/flaky-test.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Flaky Test Report 3 | about: 'Template for documenting tests that fail inconsistently and are often unrelated to the work you are doing. Often times a simple retry (or two) does the trick.' 4 | 5 | title: 'FLAKY TEST: ' 6 | labels: 'flaky-test' 7 | assignees: '' 8 | 9 | --- 10 | 11 | ## Path to Test File 12 | 13 | ``` 14 | ./relative/path/to/testfile.test.ts 15 | ``` 16 | 17 | ## Readout of the failure 18 | 19 | Include any helpful output from the failure(s) here. 20 | 21 | ## Workflows of Failrure(s) 22 | 23 | Paste any CircleCI or Github Actions runs where this test failed 24 | 25 | ## What were you working on? 26 | 27 | What were you working on when this test failed? 28 | 29 | ## Notes 30 | 31 | ## Definition of Done (Updated 4-14-21) 32 | 33 | **Engineering** 34 | 35 | - [ ] Documentation has been added to this card with any helpful information relating to the test failures. 36 | - [ ] Test has been fixed or removed. 37 | - [ ] Test has been reattempted 5 times without fail. 38 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/logging-improvement.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Logging Improvement 3 | about: 'Template for improving what DAWSON logs and ' 4 | title: '' 5 | labels: 'log-improvement' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the Improvement** 11 | 12 | As an engineer, so that I can better troubleshoot ____, I need ____. 13 | 14 | Should we log something differently? 15 | Should we include it in our Kibana index? 16 | What's the information you think we are missing or would rather not be including? 17 | 18 | **Provide any examples** 19 | 20 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/offboarding.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Offboard a team member 3 | about: Used for employees of the U.S. Tax Court and vendor teams to revoke access 4 | to all relevant accounts and tools when an employee departs. 5 | title: Offboard [Person] 6 | labels: '' 7 | assignees: '' 8 | 9 | --- 10 | 11 | - [ ] All access is revoked to tools listed in [the onboarding template](https://github.com/ustaxcourt/ef-cms/blob/staging/.github/ISSUE_TEMPLATE/onboarding.md) (copy the relevant accounts to checklist items below). 12 | 13 | Verify the offboarding person: 14 | 15 | - [ ] Does not have active AWS IAM accounts in staging and production AWS accounts. 16 | - [ ] Does not have active AWS Organization accounts in staging and production AWS accounts. 17 | - [ ] Does not have Cognito access to Kibana logs in staging and production AWS accounts. 18 | - [ ] Does not have privileged Cognito access to DAWSON environments. 19 | - [ ] Does not have access to private GitHub repositories. 20 | - [ ] Does not have push access to public GitHub repositories. 21 | - [ ] Does not have access to Zendesk. 22 | - [ ] Does not have access to Slack. 23 | - [ ] Does not have access to Trello boards. 24 | - [ ] All sensitive secrets the person had access to are rotated. 25 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/onboarding.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Onboard a new team member 3 | about: Used for new hires within the U.S. Tax Court and vendor teams to grant access 4 | to all relevant accounts and tools. 5 | title: Onboard [Person] 6 | labels: '' 7 | assignees: '' 8 | 9 | --- 10 | 11 | Welcome to the team! 🎉 😎 12 | 13 | #### Access to tools 14 | 15 | - [ ] GitHub — speak with your team lead to determine the appropriate repositories and levels of access in the [ustaxcourt](https://github.com/ustaxcourt) and [flexion](https://github.com/flexion) organizations. 16 | - [ ] [Slack](https://ustaxcourt.slack.com) — look for important channels to join in [How We Work](https://github.com/ustaxcourt/ef-cms/blob/staging/docs/how-we-work.md). 17 | - [ ] Zoom — speak with your team lead to get access to Zoom if you will be hosting meetings. 18 | - [ ] Zendesk — get access only if you will be providing customer support. 19 | - [ ] Trello — used for some backlogs (see the [README](https://github.com/ustaxcourt/ef-cms/blob/staging/README.md)). Work with your team lead to gain access. 20 | 21 | #### Access to application data 22 | 23 | - [ ] Get access to AWS accounts through AWS Organizations. 24 | - [ ] Configure access to relevant DAWSON environments through Cognito. 25 | - [ ] Configure Kibana logging access through Cognito. 26 | 27 | #### Install relevant tools 28 | 29 | - [ ] Zoom and Slack desktop clients (recommended). 30 | - [ ] ZenHub [browser extension](https://www.zenhub.com/extension) (used to view backlogs). 31 | - [ ] If you will be running or developing on the application locally, follow the setup steps in the [README](https://github.com/ustaxcourt/ef-cms/blob/staging/README.md). 32 | 33 | #### Optional tasks 34 | 35 | - [ ] Join any of the [Digital.gov Communities of Practice](https://digital.gov/communities/) email lists which may be beneficial to your role. These are communities used to collaborate and share resources with others across government. 36 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/team-experiment-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Team Experiment Template 3 | about: 'Experiment for team improvement. ' 4 | title: 'Experiment: ' 5 | labels: Experiment 6 | assignees: ccolluro 7 | 8 | --- 9 | 10 | As a product team, so that we_______, we need ________. 11 | 12 | 13 | ## Problem/Observation 14 | 15 | 16 | ## Hypothesis 17 | 18 | 19 | ## Experiment Details 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | ## Data to Measure 28 | 29 | 30 | 31 | ## Timebox 32 | 33 | ## Tasks 34 | 35 | 36 | 37 | 38 | ## Observation/Outcome 39 | 40 | 41 | ## Open Questions 42 | 43 | 44 | ## Notes 45 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/ustc-story-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: USTC Story Template 3 | about: Document stories for the USTC project 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | As a _______, so that ________, I need ________. 11 | 12 | 13 | ## Pre-Conditions 14 | 15 | ## Acceptance Criteria 16 | 17 | 18 | ## Notes 19 | 20 | 21 | ## Tasks 22 | 23 | ## Test Cases 24 | 25 | ## Story Definition of Ready (updated on 12/23/22) 26 | The following criteria must be met in order for the user story to be picked up by the Flexion development team. 27 | The user story must: 28 | - [ ] Is framed in business/user need, the value has been addressed. 29 | - [ ] Includes acceptance criteria 30 | - [ ] Has been refined 31 | - [ ] Pre conditions have been satisfied. 32 | 33 | **Process:** 34 | Flexion developers and designers will test if the story meets acceptance criteria and test cases in Flexion dev and staging environments (“standard testing”). If additional acceptance criteria or testing scenarios are discovered while the story is in progress, a new story should be created, added to the backlog and prioritized by the product owner. 35 | 36 | 37 | ## Definition of Done (Updated 5-19-22) 38 | **Product Owner** 39 | - [ ] Acceptance criteria have been met and validated on the Court's migration environment 40 | - [ ] Add scenario to testing document, if applicable (https://docs.google.com/spreadsheets/d/1FUHKC_YrT-PosaWD5gRVmsDzI1HS_U-8CyMIb-qX9EA/edit?usp=sharing) 41 | 42 | **UX** 43 | - [ ] Business test scenarios have been refined to meet all acceptance criteria 44 | - [ ] Usability has been validated 45 | - [ ] Wiki has been updated (if applicable) 46 | - [ ] Story has been tested on a mobile device (for external users only) 47 | 48 | **Engineering** 49 | - [ ] Automated test scripts have been written, including visual tests for newly added PDFs. 50 | - [ ] Field level and page level validation errors (front-end and server-side) integrated and functioning. 51 | - [ ] Verify that language for docket record for internal users and external users is identical. 52 | - [ ] New screens have been added to pa11y scripts. 53 | - [ ] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html. 54 | - [ ] READMEs, other appropriate docs, and swagger/APIs fully updated. 55 | - [ ] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required). 56 | - [ ] Interactors should validate entities before calling persistence methods. 57 | - [ ] Code refactored for clarity and to remove any known technical debt. 58 | - [ ] If new docket entries have been added as seed data to `efcms-local.json`, 3 local s3 files corresponding to that docketEntryId have been added to `web-api/storage/fixtures/s3/noop-documents-local-us-east-1` 59 | - [ ] Acceptance criteria for the story has been met. 60 | - [ ] If there are special instructions in order to deploy into the next environment, add them as a comment in the story. 61 | - [ ] If the work completed for the story requires a reindex without a migration, or any other special deploy steps, apply these changes to the following flexion branches: 62 | - [ ] experimental1 63 | - [ ] experimental2 64 | - [ ] experimental3 65 | - [ ] experimental4 66 | - [ ] experimental5 67 | - [ ] experimental6 68 | - [ ] develop 69 | - [ ] Reviewed by UX on a deployed environment. 70 | - [ ] Reviewed by PO on a deployed environment. Can be deployed to the Court's `test` environment if prod-like data is required. Otherwise deployed to any `experimental` environment. 71 | - [ ] Deployed to the Court's `staging` environment. 72 | 73 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE/merge-to-master.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ![Known Vulnerabilities](https://snyk.io/test/github/ustaxcourt/ef-cms/sprint-##/badge.svg) Snyk 4 | 5 | ## Summary 6 | 7 | Explain here, in a paragraph or two, what has changed since the prior merge to master. 8 | 9 | ## New Features 10 | - 11 | - 12 | - 13 | 14 | ## Bug Fixes 15 | 16 | ## Breaking Changes 17 | 18 | ## Sprints Encompassed 19 | - 20 | 21 | ## Notes 22 | 23 | # Checklist 24 | 25 | - [ ] There are standardized release notes 26 | - [ ] All dependencies are pinned 27 | - [ ] No dependencies are deprecated 28 | - [ ] Major events are logged 29 | - [ ] Output from vulnerability scan with OWASP ZAP is included 30 | - [ ] Dependency analysis (with e.g. Code Climate, Snyk, NPM Audit) reveals no non-trivial vulnerabilities that would be deployed to production, and has the output included 31 | - [ ] Code security analysis (with e.g. Code Climate, Bandit, or Sonarcloud) reveals no non-trivial vulnerabilities, and has the output included 32 | - [ ] All volatile data storage is on redundant infrastructure 33 | - [ ] Periodic snapshots of all volatile data storage are configured 34 | - [ ] There is monitoring, alerting a specific person, for both downtime and error/performance problems 35 | - [ ] There is a system/network diagram 36 | - [ ] There is a README badge for dependency analysis 37 | - [ ] There is a README badge for static code analysis 38 | - [ ] A “beta” label is prominently featured on every page 39 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE/pr-to-ustc.md: -------------------------------------------------------------------------------- 1 | # Sprint {##} 2 | ## Issues 3 | *List of issues the work in this PR encompasses* 4 | 5 | ## Data Migrations 6 | *Describe any data migrations included and their purpose* 7 | 8 | ## Manual Deployment Steps 9 | *List out and reference documentation to any manual deployment steps or other manual updates needing to be taken in relation to the included changes.* 10 | -------------------------------------------------------------------------------- /.github/workflows/api.yml: -------------------------------------------------------------------------------- 1 | name: Node.js CI 2 | 3 | on: [pull_request] 4 | 5 | jobs: 6 | API: 7 | runs-on: ubuntu-latest 8 | 9 | strategy: 10 | matrix: 11 | node-version: [14.x] 12 | 13 | steps: 14 | - uses: actions/checkout@v2 15 | - name: Use Node.js ${{ matrix.node-version }} 16 | uses: actions/setup-node@v1 17 | with: 18 | node-version: ${{ matrix.node-version }} 19 | - name: NPM Install 20 | run: npm ci --no-optional && npm rebuild 21 | - name: API 22 | run: npm run test:api 23 | -------------------------------------------------------------------------------- /.github/workflows/client.yml: -------------------------------------------------------------------------------- 1 | name: Node.js CI 2 | 3 | on: [pull_request] 4 | 5 | jobs: 6 | Client: 7 | runs-on: ubuntu-latest 8 | 9 | strategy: 10 | matrix: 11 | node-version: [14.x] 12 | 13 | steps: 14 | - uses: actions/checkout@v2 15 | - name: Use Node.js ${{ matrix.node-version }} 16 | uses: actions/setup-node@v1 17 | with: 18 | node-version: ${{ matrix.node-version }} 19 | - name: NPM Install 20 | run: npm ci --no-optional && npm rebuild 21 | - name: API 22 | run: npm run test:client:unit 23 | -------------------------------------------------------------------------------- /.github/workflows/lint.yml: -------------------------------------------------------------------------------- 1 | name: Node.js CI 2 | 3 | on: [pull_request] 4 | 5 | jobs: 6 | Lint: 7 | runs-on: ubuntu-latest 8 | 9 | strategy: 10 | matrix: 11 | node-version: [14.x] 12 | 13 | steps: 14 | - uses: actions/checkout@v2 15 | - name: Use Node.js ${{ matrix.node-version }} 16 | uses: actions/setup-node@v1 17 | with: 18 | node-version: ${{ matrix.node-version }} 19 | - name: NPM Install 20 | run: npm ci --no-optional && npm rebuild 21 | - name: Lint 22 | run: npm run lint 23 | - name: Shellcheck 24 | run: ./run-shellcheck.sh 25 | -------------------------------------------------------------------------------- /.github/workflows/scripts.yml: -------------------------------------------------------------------------------- 1 | name: Node.js CI 2 | 3 | on: [pull_request] 4 | 5 | jobs: 6 | Scripts: 7 | runs-on: ubuntu-latest 8 | 9 | strategy: 10 | matrix: 11 | node-version: [14.x] 12 | 13 | steps: 14 | - uses: actions/checkout@v2 15 | - name: Use Node.js ${{ matrix.node-version }} 16 | uses: actions/setup-node@v1 17 | with: 18 | node-version: ${{ matrix.node-version }} 19 | - name: NPM Install 20 | run: npm ci --no-optional && npm rebuild 21 | - name: Scripts 22 | run: npm run test:scripts 23 | -------------------------------------------------------------------------------- /.github/workflows/shared.yml: -------------------------------------------------------------------------------- 1 | name: Node.js CI 2 | 3 | on: [pull_request] 4 | 5 | jobs: 6 | Shared: 7 | runs-on: ubuntu-latest 8 | 9 | strategy: 10 | matrix: 11 | node-version: [14.x] 12 | 13 | steps: 14 | - uses: actions/checkout@v2 15 | - name: Use Node.js ${{ matrix.node-version }} 16 | uses: actions/setup-node@v1 17 | with: 18 | node-version: ${{ matrix.node-version }} 19 | - name: NPM Install 20 | run: npm ci --no-optional && npm rebuild 21 | - name: Shared 22 | run: npm run test:shared 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Flexion EFCMS Fork 2 | 3 | Please navigate to the [https://github.com/ustaxcourt/ef-cms](https://github.com/ustaxcourt/ef-cms) repo for the up to the date documentation and readme for this project. New features and bug fixes should be created off of the ustaxcourt/staging branch. 4 | --------------------------------------------------------------------------------