validuntil gets lost during approval

[asattler]

Is this a regression?

Yes

Severity

🔴 Critical – blocks key functionality

Please provide the branch(es) you discovered this issue in

v93

Environment Details

9.3 v93-348245

Please provide a minimal set of steps to reproduce the issue

1. Have a product with an approval workflow where some user needs to approve (for better visibility I recommend having 2 approval steps, each having a user to approve)
2. Request this product with a valid until date (e.g. 25.06.2026)
3. Login as 1st approver
4. go the the pending requests view
5. click on approve of the just requested product, the sidesheet opens.
6. notice that the valid until date is shown as requested before. Do not click into the input element or change anything.
7. click on approve to submit the approval
8. login as 2nd approver and repeat steps 4 + 5
9. notice that valid until date is empty now

Description

Requests will loose its previously set valid until date during approval.
This leads to very bad data situations, as it's impossible to check if this modification was done by the approver or by this bug.
From my point of view this is critical. If you think of audits etc...

The problem came in with commit #483 and is related to the changes in imxweb/projects/qer/src/lib/itshopapprove/workflow-action/workflow-action.service.ts:

if (request.canSetValidUntil(itShopConfig) && actionParameters.validUntil) {
          const until = actionParameters.validUntil.column.GetValue();
          if (until) {
            request.ValidUntil.value = addTimeNowToDate(until);
          } else {
            // The value was removed, so set it to null in order to not send an invalid date to the backend
            await request.ValidUntil.Column.PutValue(null);
          }

I verified this by removing the lines added by the commit. Primary
await request.ValidUntil.Column.PutValue(null);

I'm pretty sure that the same applies to the valid from date, but I did not test it.

Based on my analysis the root cause for this is, actionParameters.validUntil is only used if you approve more than 1 object at the same time and use the "common editor" at the top of the sidebar.
In other cases the changes are directly performed on the object "request".

Describe what you expected to happen versus what actually happened

I would expect that if the approver doesn't touch the given valid until date, that this date is kept.

Relevant logs or console output

Add a screenshot(s) if that helps illustrate the problem

Initial Request

1st approver approves without editing anything

2nd approver finds the valid until date to be empty

Suggested Fix

No response

Anything else?

No response

Before submitting...

• I have searched for existing issues that match this one on github and on the community support page
• I have included all necessary details to reproduce this issue

[asattler]

I've tried to think of a solution for the issue.
From my point of view the code change done with the mentioned commit is wrong. It doesn't cover the designed UI.

For single approvals the WorkflowSingleActionComponent is used. It does not use the actionParameters, so the result of const until = actionParameters.validUntil.column.GetValue(); is always null.

You could e.g. check in the if-clauses for a multiselection by requests.length > 1, so that you don't run into the code for that.

But also multi-approvals are broken by the original fix.
Using the WorkflowMultiActionComponent you can either change the ValidUntil for all selected requests, or modify each one-by-one.
This means that actionParameters is needed, but actionParameters.validUntil.column.GetValue(); can again be null without the intention to empty this for all selected requests.

So I think the original problem (to clear the date for all selected items) needs a new solution, the implemented one breaks everything else...

[kovtib]

Thanks @asattler, we already have an internal ticket for this error and we are working on it.

[kovtib]

/link-devops 709042

[github-actions]

✅ DevOps work item #709042 linked and label added by @kovtib. Closing this issue - keep an eye out for branch syncing to resolve this work item.