[WIP] Support configuration for IDV shortened flow

[Copilot]

Thanks for the feedback on #443. I've created this new PR, which merges into #443, to address your comment. I will work on the changes and keep this PR's description up to date as I make progress.

Original PR: #443
Triggering comment (#443 (comment)):

@copilot do To implement the feature allowing RPs (Relying Parties) to omit certain screens in the flow by using the suppressed_screens configuration property, you should follow this detailed plan. Note that any backend (BE) implementation can require additional considerations based on specific architecture and technology stacks; however, the steps below should provide a comprehensive guidance for a common environment.

Implementation Plan

1. Requirements Analysis

• Review the full specification and context to ensure understanding of how the suppressed_screens property should operate.
• Confirm with stakeholders and the IDV team regarding the list of screens that can be suppressed.

2. Data Model Update

• Update Configuration Model:
  • Modify the existing sdk_config model/schema to include the new property suppressed_screens. This property should be optional.
  • Ensure that this property accepts an array of strings, where each string represents a screen identifier that can be suppressed.

3. Backend Logic Implementation

• Update Configuration Parsing:

  • Modify the configuration loader logic to correctly parse and validate the new suppressed_screens property.
  • Ensure that unsupported or unrecognized screen identifiers are handled gracefully, possibly with logging or error messages.

• Control Flow Modification:

  • Identify all backend points where the screen rendering flow is determined.
  • Modify the flow control logic to check for the presence of the suppressed_screens array and exclude any listed screens from being processed or returned in the flow sequence.
  • Implement fallback scenarios if, for some reason, suppressed_screens is not specified and defaults are necessary.

4. Frontend Adjustments

• Work with the frontend team to ensure they understand how suppressed_screens will affect the user interface.
• Ensure that the frontend can interpret the modified session or configuration data and omit the screens dynamically.

5. Testing

• Unit Tests:

  • Write unit tests for the configuration model to ensure it properly accepts the suppressed_screens data.
  • Develop unit tests covering edge cases like missing configurations, unrecognized screen values, etc.

• Integration Tests:

  • Create integration tests to ensure that the suppressed_screens logic correctly modifies the flow in a staging environment.
  • Validate that the database or configuration service correctly stores and retrieves this information.

• Acceptable User Test (UAT):

  • Coordinate with QA to perform User Acceptance Testing, ensuring the flow can be correctly altered via the suppressed_screens property.
  • Test across different RPs that might have unique configuration needs.

6. Documentation

• Update relevant documentation to include information about the suppressed_screens configuration option.
• Provide examples and guidance on how RPs can implement this new feature effectively.

7. Deployment

• Plan a deployment strategy that includes rollback procedures in case of unforeseen issues.
• Communicate with all stakeholders about the deployment schedule and potential impacts.

8. Monitoring and Feedback

• Post-deployment, monitor logs and analytics to ensure no unintended behavior is occurring.
• Collect feedback from early adopters to refine the feature if necessary.

By following the steps outlined above, the implementation of the suppressed_screens feature can be performed systematically, ensuring the desired functionality is delivered efficiently.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.