APPEALS-64612: Modify Issue classes to use the description when serialized by the IssueSerializer

[craigrva]

Resolves APPEALS-64612

Description

• Modifies the api_status_description method in RequestIssue and DecisionIssue to return the actual issue description, instead of a generic string based on the issue's diagnostic code, when the feature toggle is enabled
• Adds an "API Keys" section to the demo test users page /test/users which allows testers to generate an API key via that page, instead of needing to generate them via the Rails console
• Add seed data
• Add tests

Acceptance Criteria

• Code compiles correctly

Testing Plan

• Navigate to /test/users
• Click "Generate API Key"
• Copy the key string displayed below the button when it is generated
• Open Bruno
• Open the collection contained in caseflow/api_collections/api/v2/appeals_status/bruno.json
• Click the "localhost" GET request in the left navigation pane
• Change the URL from 127.0.0.1:3000 to the base URL for the demo environment being tested
• Click the "Auth" tab below the URL box
• In the "Token" box, remove the existing token and paste the token copied from the "Generate API Key" step
• Click the "Headers" tab
• Verify that an SSN is present. If not, the test veteran SSNs begin with 123_000_001
• Click the right arrow button to the right of the URL box to send the request
• Once a response is successfully received, navigate to that veteran's Case Details page by searching for the SSN in the Bruno HTTP request headers
• Verify that the issues in the HTTP response body have a "description" field which matches the text seen in the Issues section of the case details page
• Repeat for various veteran SSNs

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

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?