[29.x] - Bug 650481[Expense Agent] Closed travel requests are editable and are missing approver info.

[v-rohangarg20]

Fixes AB#650481

Problem

Closed travel requests can still be edited, and automatically approved travel requests do not record approver information. The requested-for name is also not shown on the travel request card.

Changes

• Restrict editable Travel Request fields to open requests.
• Record the approving user and timestamp when automatic approval is used.
• Store and display the requested-for expense user name.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept with Suggestions

What this PR does

This change makes travel-request fields editable only while the request is open, stores the requested-for name, and records complete approval details when a request is approved automatically. It also resolves the displayed user name from the user record for normal approval and rejection.

The status guards and approval metadata updates match the requested behavior. However, the new derived name can be edited independently, and unused page state currently causes the app builds to fail.

Problem-solution fit

Fit: Partial

The change covers the travel-request editing and approval-recording paths, but the editable derived name can become inconsistent with the selected expense user. The implementation also needs a small cleanup before it builds without new warnings.

Suggestions

S1 (🟠 Moderate): Verify the new automatic approval metadata
Extend the existing automatic-approval test to assert the approval time, user ID, and user name. The current test checks only the status, so these new assignments could regress unnoticed.

S2 (🟠 Moderate): Keep the derived user name read-only
Make Requested For Name read-only on the page. It is derived from Requested For, so direct edits can leave the stored name and expense user number inconsistent.

S3 (🟠 Moderate): Remove or use the unused page state
Remove OnAfterGetCurrRecord and RequestIsOpen, or use the variable in the editable expressions. The unused assignment introduces AA0206 and currently makes the app builds fail.

Risk assessment and necessity

Risk: The approval changes affect audit metadata rather than posting amounts. The main regression risks are an incorrect displayed person, missing approver details after automatic approval, and the current build failure caused by the unused variable.

Necessity: Open travel requests need editable planning details, and approved requests need an accurate approver identity. The scope is reasonable, but the derived-name consistency and build warning should be corrected.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11593 round=1 by=alexei-dobriansky at=2026-09-18T01:14:16.9015599Z lastSha=9357d1c7997d1f4434f6897bf78edde013f6f743 reviewKey=e63aee2a91063cd09224edd5f66011af1847e4f9f8a97086ae3f744d319e0ee4 suggestions=S1@5d5df62d,S2@890b9382,S3@6fb652f8

[alexei-dobriansky]

Good Sense Reviewer - Round 2

Recommendation: Accept with Suggestions

What this PR does

This update removes the unused page state that was introduced in the first round while keeping the travel-request editability, requested-for name, and disabled-agent auto-approval changes. The build-warning part of the prior review is addressed, but the derived requested-for name is still editable and the new approval metadata still has no focused test coverage.

Problem-solution fit

Fit: Partial

The change now fits the requested behavior better because the unused page state is gone. It is still partial because the stored requested-for name can still be changed independently from the selected expense user, and the new approval metadata is not covered by a regression test.

Status of previous suggestions

ID	Title	Status	Author response
S1	Verify the new automatic approval metadata	Not addressed
S2	Keep the derived user name read-only	Not addressed
S3	Remove or use the unused page state	Addressed	Removed the unused trigger and variable.

New observations (commits since round 1)

None - the latest change only removes the unused page state from the first review.

Risk assessment and necessity

Risk: The build-warning risk from the unused variable is gone. The remaining risk is data consistency: users can still edit a name that is derived from another field, and the approval metadata can regress because it is not asserted by tests.

Necessity: The edit guards and approval metadata are needed for closed travel requests and auditability. The scope is still reasonable, but the derived-name consistency and focused test coverage should be completed.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11593 round=2 by=alexei-dobriansky at=2026-09-18T07:14:54.6569924Z lastSha=97578a23ab7731ce5af09c3fc11e0a0111be100f reviewKey=be520752f8e8ba5f625d6ff91ede1906c9617228d85a2e174ce7c2e1be234633 suggestions=S1@5d5df62d:notaddressed,S2@890b9382:notaddressed,S3@6fb652f8:addressed parentRound=1

[alexei-dobriansky]

Good Sense Reviewer - Round 3

Recommendation: Accept with Suggestions

What this PR does

This round makes travel request fields editable only while the request is open, records approver identity and time for automatic approval, stores the requested-for name, and adds focused tests for approval metadata and editability behavior.

Status of previous suggestions

ID	Title	Status	Author response
S1	Assert automatic approval metadata	Addressed	Focused tests now assert approval user ID, user name, and timestamp.
S2	Keep requester name derived	Not addressed	Requested For Name is still editable on the card while open.
S3	Remove unused page state	Addressed	The unused state is gone.

New observations (commits since round 2)

S4 (🟠 Moderate): Keep the derived requester name read-only
Make Requested For Name read-only on the page. It is derived from Requested For, so direct edits can leave the stored name and expense user number inconsistent.

Risk assessment and necessity

Risk: Approval audit and closed-request edit guards are covered better now. The remaining risk is data consistency for a derived display name.

Necessity: The change is needed so closed travel requests cannot be edited and automatic approvals carry audit metadata. The derived requester name should not remain directly editable.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11593 round=3 by=alexei-dobriansky at=2026-09-21T20:34:08.9898778Z lastSha=7744c43dfbec59647abc0e0f69d68e2879f2c1b1 reviewKey=302020b4e87a7f339705fa776d90e9214755e6a9566520c7f4f55f9389dc36ff suggestions=S1@old:addressed,S2@old:notaddressed,S3@old:addressed,S4@reqreadonly:new parentRound=2

[alexei-dobriansky]

Good Sense Reviewer - Round 4

Recommendation: Accept with Suggestions

What this PR does

This round adds the remaining editability guards for travel request fields while keeping the automatic approval metadata and requester-name updates from earlier rounds. The closed-request edit path is better covered now: purpose, actual dates, and the card number field follow the open-status guard, and automatic approval still stores user and time metadata. The remaining concern is the derived requester name field.

Status of previous suggestions

ID	Title	Status	Author response
S1	Assert automatic approval metadata	Addressed	The focused approval metadata test is still present.
S2	Keep requester name derived	Not addressed	The same derived-name concern remains; Requested For Name can still be edited directly while the request is open.
S3	Remove unused page state	Addressed	The unused state remains removed.
S4	Keep the derived requester name read-only	Not addressed	A status check was added, but the card still allows direct edits while the request is open.

New observations (commits since round 3)

None - the new commits add more read-only guards, but they do not fully address S4.

Risk assessment and necessity

Risk: The main editability and automatic-approval audit paths are now covered by code and tests. The remaining risk is data consistency: a derived requester name can be changed independently from the requester number while the request is open.

Necessity: The change is needed so non-open travel requests cannot be edited and automatically approved requests carry approver metadata. The scope is appropriate for the bug, with one non-blocking consistency issue left.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11593 round=4 by=alexei-dobriansky at=2026-09-22T07:13:19.9345428Z lastSha=4a3b154e833161b9b9e41834e341037a885fbe34 reviewKey=753bf99be59fddd177cc3fd6e8c9130ba672b10103c4cffc95adf570717e45bc suggestions=S1@old:addressed,S2@old:notaddressed,S3@old:addressed,S4@reqreadonly:notaddressed parentRound=3