Feature: Conditional action buttons for Verification Requests with Auth-aware Redirection

[LuizFNJ]

Background Information

Currently, the Verification Request (VR) interface only displays an "Edit" button for authorized users. We need to expand the interaction options by adding two new navigation points: History and Tracking.

The visibility and behavior of these buttons must adapt based on the user's role and authentication status to ensure a secure and personalized experience. This addition aims to provide quick access to verification logs and status tracking without cluttering the main UI for unauthorized or guest users.

When the user is logged in:

When user is not logged in

How

• Button Implementation: Create and position the "History" and "Tracking" buttons adjacent to the existing "Edit" button within the VR component.
• Role-Based Access Control (RBAC):
  • Admin / Fact-checker: Display all buttons (Edit, History, and Tracking).
  • Regular User: Display only the Tracking button.
  • Unauthenticated User (Guest): Display only the Tracking button.
• Authentication Flow:
  • Implement a guard for the Tracking button: if a guest user clicks it, redirect them to the Login/Sign-up page.
  • Use a returnTo or redirectTo query parameter to ensure the user is automatically redirected back to the Tracking page immediately after a successful authentication.
• UI Preservation: Do not modify the existing "Edit" button logic; use its current positioning as the reference for the new layout.

Expected Behavior

Authorized personnel (Admins/Fact-checkers) should have full access to all management tools, while regular and guest users should only see the option to track the request. Guests must be seamlessly redirected back to their tracking destination after logging in.