feat: emit ApprovalStateChangedEvent on approval state changes

[xyonium]

Motivation

Apps reacting to approval state changes (e.g. via workflow engine rules on the approval tags) currently cannot know who requested an approval:

• the session user at that moment is the approver (on approve/reject)
• the approval_activity row holding the requester is replaced by storeAction() before the tag change is triggered

This was reported in nextcloud/workflow_script#363, where a flow script needs the requester's user id to route the file after approval.

What this PR does

Adds OCA\Approval\Events\ApprovalStateChangedEvent, dispatched via dispatchTyped() when an approval is

• requested (ApprovalService::request())
• requested via manual/auto tag assignment (requestViaTagAssignment())
• approved (approve())
• rejected (reject())

The event carries:

getter	content
getFileId()	the file id
getRuleId()	the approval rule id
getNewState()	Application::STATE_PENDING / STATE_APPROVED / STATE_REJECTED
getActorUserId()	the user performing the action (requester on request, approver otherwise)
getRequesterUserId()	the user who requested the approval, if known

On approve/reject the requester is read via getLastAction(..., STATE_PENDING) before storeAction() replaces that row, and the event is dispatched before the tags change, so listeners reacting to the tag assignment events (like workflow engines) already have the context within the same request.

A unit test asserts the events and their payloads on request and approve.

Counterpart

This enables nextcloud/workflow_script#363 — consumed by nextcloud/workflow_script#534 which adds a %r placeholder for the requester's user id.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[lukasdotcom]

Thanks @xyonium for the pr. Sorry for the slow review.

[xyonium]

Thanks @lukasdotcom! Addressed both points in b126370: the docblock now clarifies the event only fires on service-driven state changes (not manual tag assignment), and ApprovalStateChangedEvent is now webhook-compatible per the mail#12936 pattern (getWebhookSerializable() + unit tests). Ready for another look when you get a chance. Note: workflow_script#534 consumes this event for the %r placeholder, so it depends on this landing first.

[lukasdotcom]

Thanks @lukasdotcom! Addressed both points in b126370: the docblock now clarifies the event only fires on service-driven state changes (not manual tag assignment), and ApprovalStateChangedEvent is now webhook-compatible per the mail#12936 pattern (getWebhookSerializable() + unit tests). Ready for another look when you get a chance. Note: workflow_script#534 consumes this event for the %r placeholder, so it depends on this landing first.

Could you make sure to sign your newest commit so the DCO check passes?

[xyonium]

Signed ✅ — thanks for pointing it out. I rewrote the branch so every commit is now authored by and carries Signed-off-by: xyonium <shark_xc@hotmail.com> (and dropped the stray AI co-author trailer). DCO checks are green now.

[lukasdotcom]

Thanks. Just for future information: Don't remove the Co-authored by claude portions. Those are required by the AI policy at Nextcloud.

[xyonium]

OK, I'll keep that in mind.