Skip to content
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

Div/appeals 54935 #23666

Merged
merged 3 commits into from
Dec 3, 2024
Merged

Div/appeals 54935 #23666

merged 3 commits into from
Dec 3, 2024

Conversation

divyadasari-va
Copy link
Contributor

@divyadasari-va divyadasari-va commented Dec 3, 2024

Resolves Details: Correspondence and Appeals Tasks: Add Task Action: Power of attorney-related

Description

Please explain the changes you made here.

Acceptance Criteria

  • Code compiles correctly

Testing Plan

  1. Log in as an inbound ops team admin user

  2. Navigate to /queue/correspondence/team and click on a correspondence

  3. Under General Information, select "Power of attorney related" correspondence type and save changes.

  4. Scroll down to the bottom and select "Create record".

  5. Continue through step 1, and scroll to "tasks not related to appeal" on step 2.

  6. Click "+ Add tasks", select an Power of attorney related task in the drop down, and add text in the textbox.

  7. Click "Continue" from the second step. Before continuing, copy the link from the address bar to use later!

  8. On step 3, click the "submit" button. Then Confirm the submission.

  9. Now that the data is set up, you can continue to test the story.

  10. Log in as a BVASYELLOW or BVASORANGE

  11. Paste the address saved from the previous step, make sure to remove the last part of /review_package or /intake

  12. This will take you to the Case details page for that appeal as the Hearings user.

  13. Click on the + button next to the "Tasks not related to appeal" section

  14. In the Actions drop down next to the other motion task, verify the "Return to Inbound Ops Team" task is present

  15. Click on the return to inbound ops, and the modal will appear.

  16. The return button should initially not be clickable until a radio button is selected.

  17. Once a radio button is selected, the return button will be clickable

  18. If "Other" is selected, the return button will remain locked until you type a reason for return.

  19. Click on the "Return" button. Now, verify in the "Tasks not related" section that the success banner appears.

  • For feature branches merging into main: Was this deployed to UAT?

Frontend

User Facing Changes

  • Screenshots of UI changes added to PR & Original Issue
BEFORE AFTER

Storybook Story

For Frontend (Presentation) Components

  • Add a Storybook file alongside the component file (e.g. create MyComponent.stories.js alongside MyComponent.jsx)
  • Give it a title that reflects the component's location within the overall Caseflow hierarchy
  • Write a separate story (within the same file) for each discrete variation of the component

Backend

Database Changes

Only for Schema Changes

  • Add typical timestamps (created_at, updated_at) for new tables
  • Update column comments; include a "PII" prefix to indicate definite or potential PII data content
  • Have your migration classes inherit from Caseflow::Migration, especially when adding indexes (use add_safe_index) (see Writing DB migrations)
  • Verify that migrate:rollback works as desired (change supported functions)
  • Perform query profiling (eyeball Rails log, check bullet and fasterer output)
  • For queries using raw sql was an explain plan run by System Team
  • Add appropriate indexes (especially for foreign keys, polymorphic columns, unique constraints, and Rails scopes)
  • Run make check-fks; add any missing foreign keys or add to config/initializers/immigrant.rb (see Record associations and Foreign Keys)
  • Add belongs_to for associations to enable the schema diagrams to be automatically updated
  • Document any non-obvious semantics or logic useful for interpreting database data at Caseflow Data Model and Dictionary

Integrations: Adding endpoints for external APIs

  • Check that Caseflow's external API code for the endpoint matches the code in the relevant integration repo
    • Request: Service name, method name, input field names
    • Response: Check expected data structure
    • Check that calls are wrapped in MetricService record block
  • Check that all configuration is coming from ENV variables
    • Listed all new ENV variables in description
    • Worked with or notified System Team that new ENV variables need to be set
  • Update Fakes
  • For feature branches: Was this tested in Caseflow UAT

Best practices

Code Documentation Updates

  • Add or update code comments at the top of the class, module, and/or component.

Tests

Test Coverage

Did you include any test coverage for your code? Check below:

  • RSpec
  • Jest
  • Other

Code Climate

Your code does not add any new code climate offenses? If so why?

  • No new code climate issues added

Monitoring, Logging, Auditing, Error, and Exception Handling Checklist

Monitoring

  • Are performance metrics (e.g., response time, throughput) being tracked?
  • Are key application components monitored (e.g., database, cache, queues)?
  • Is there a system in place for setting up alerts based on performance thresholds?

Logging

  • Are logs being produced at appropriate log levels (debug, info, warn, error, fatal)?
  • Are logs structured (e.g., using log tags) for easier querying and analysis?
  • Are sensitive data (e.g., passwords, tokens) redacted or omitted from logs?
  • Is log retention and rotation configured correctly?
  • Are logs being forwarded to a centralized logging system if needed?

Auditing

  • Are user actions being logged for audit purposes?
  • Are changes to critical data being tracked ?
  • Are logs being securely stored and protected from tampering or exposing protected data?

Error Handling

  • Are errors being caught and handled gracefully?
  • Are appropriate error messages being displayed to users?
  • Are critical errors being reported to an error tracking system (e.g., Sentry, ELK)?
  • Are unhandled exceptions being caught at the application level ?

Exception Handling

  • Are custom exceptions defined and used where appropriate?
  • Is exception handling consistent throughout the codebase?
  • Are exceptions logged with relevant context and stack trace information?
  • Are exceptions being grouped and categorized for easier analysis and resolution?

@divyadasari-va divyadasari-va changed the base branch from main to feature/APPEALS-34966 December 3, 2024 17:40
Copy link

codeclimate bot commented Dec 3, 2024

Code Climate has analyzed commit 5579f53 and detected 0 issues on this pull request.

View more on Code Climate.

@divyadasari-va divyadasari-va marked this pull request as ready for review December 3, 2024 19:04
@@ -114,6 +114,20 @@
click_button("View task instructions")
expect(all(".task-instructions")[1].text).to include("Change task type instructions")
end

it "Verfify #{task_action[:name]} task with Return to inbound ops action dropdown" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change the text from Verfify to Verify.

@cacevesva cacevesva merged commit bba1a56 into feature/APPEALS-34966 Dec 3, 2024
13 of 17 checks passed
@cacevesva cacevesva deleted the Div/APPEALS-54935 branch December 3, 2024 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants