Cfodev 1669 review archival rules who and when can archive

[Vinay Saini (vks333)]

This pull request introduces a new business rule to control who is authorized to archive a participant, ensuring that only the participant's owner or users from the same or higher-level tenant can perform the archive action. It updates both backend and frontend logic to enforce this rule, adds relevant data to DTOs, and includes comprehensive unit tests for the new rule and its effects.

Authorization and Business Rule Enforcement

• Added a new business rule class ParticipantMustBeArchivableByUser to enforce that only the participant's owner or users from the same or higher-level tenant can archive a participant.
• Refactored the ArchiveCase command handler to use the new Archive method, which applies the business rule, and now requires ICurrentUserService for user context. [1] [2] [3]
• Implemented the Archive method in the Participant entity, which checks the business rule before allowing the status transition.

Frontend and DTO Updates

• Updated ParticipantSummaryDto and related mapping to include OwnerId and OwnerTenantId, enabling the frontend to determine archive permissions. [1] [2] [3]
• Modified the participant action menu UI to only show the "Archive" option if the current user is authorized according to the new rule.

Testing

• Added unit tests for ParticipantMustBeArchivableByUser covering various scenarios (owner, higher/same/lower tenant, different branch).
• Added tests to verify that unauthorized users cannot archive a participant and that authorized users can. [1] [2]

🔗 Related Work

• Closes: #
• Related: #

---

📌 Summary

What does this PR do? Keep it short but clear.

---Unauthorised users should not be able to archive i.e. if they are not case owner or are not at same level as owner's tenant or higher.

🎯 Purpose / Motivation

Why does this change exist? What problem are we solving?

---

🧠 Approach

Key implementation details, trade-offs, or design decisions.
Mention anything reviewers should pay attention to.

---As pipeline runs validation before authorization, so chose to move access checks in validators to handler because they are better enforced in the authorization path

🔄 Changes

• Added:
• Updated:
• Removed:

---

🧪 How to Test

Step-by-step instructions to verify this works.

1. As case owner or at the same tenant level as owner or above I should be able to archive a case
2. If logged in user is in different tenant than the case owner or at lower level tenant than the case owner they should be able to archive:
   a. Archive should be hidden
   b. (IT Only)To test if server side validations works, make Archive button visible by removing ParticipantArchiveAccess.CanArchive from ParticipantActionMenu.razor page and try to archive, it should show error message that "You are not authorized to archive this participant".

Expected result:

What should happen if everything is correct?

---

📸 Screenshots / Output (if applicable)

UI changes, logs, API responses, etc.

---

⚠️ Risks & Impact

• Breaking change
• Database change
• Performance impact
• Security impact

Details:

Anything reviewers should be cautious about.

---

🙋 Notes for Reviewers

Anything specific you want feedback on.
e.g. "Unsure about approach in X", "Focus on Y logic"

[Carl Sixsmith (carlsixsmith-moj)]

Not a fan of random static classes enforcing business rule.

We have IBusinessRule that can implement the guard and offer the lowest level of protection at the aggregate level.

The UI button logic can be managed through a simple check of the users tenantid and the tenantid of the owner of the case.