Save button deactivated on Questions tab when changing a value

[TeriStevenson]

I have question templates with conditional questions that are required for end users on some requests.  The requests have multiple approval levels.  All questions have been answered but sometimes the analyst needs to change the value of a response, which then makes the conditional question appear so they can add a new value.  This works fine, however, before the final approval with the request still active, the Save button on the questions tab is deactivated and the analyst cannot save the changes.  I tried updating WD_PackageRequests 'HasPendingQuestion' with a value of 0 but all that did was place the red exclamation on the question tab. 

I thought as long as the request has not gone through all approval levels an end user should be able to change a value in the response and Save.  App Portal version is 2021 R2. I'm trying to not have to make updates to the WD_ResponseQuestionAuditTrail or other tables.

[jdempsey]

Does the analyst have full admin permissions?  If not, have you tried with a user that does have full admin permissions?  I'm not sure exactly what permissions are required for someone to modify answers if they are not the requester, target user, or approver.  Also, is the question marked as required for Requester, Approver, or Both?  Are the answers static or provided via web service?  Is it only happening with a specific question type (e.g. drop-down list)?

[TeriStevenson]

The analyst does have permission and as the admin with all permissions, I am not able to make the save button activate.  The answers are set as required for the requester and its happening on all question types, but not on all requests, which is throwing me.  Some requests in the same approval level have the save button available, other ones don't and I can't determine what is causing it to not activate. The responses are done in the request in App Portal, no API or web service.

[CharlesW]

There does not seem to be much going on in the code... The following is the pertinent code:

If isCurrRequestApprovedByFinalApprover Or Not isAnsweredQuestionFound Then
       tbEditAnsweredQuestions.Items(0).Enabled = False
       If isCurrRequestApprovedByFinalApprover Then
                 tbEditAnsweredQuestions.Items(0).ToolTip = String.Format("The Request: {0} is already approved.", hdnRequestID.Value)
       End If
Else
      tbEditAnsweredQuestions.Items(0).Enabled = True
End If

where the line tbEditAnsweredQuestions.Items(0).Enabled = True is what enables the save button.. It almost looks like if none of the questions had been answered previously, or if the request had gone through the final approval, then you can not save the questions. Were any of the questions answered previously?

[TeriStevenson]

I'm able to reproduce this after doing some research.  We have a few approval levels for the requests.  When the approval group has people changes and the approval process is modified, the save button is deactivated. Is this expected behavior based on the code?

Steps to reproduce:

Create a test item with some required questions for requester.
Create an approval workflow with 3 levels of approval and at least 2 approvers at each level
Add the workflow to the catalog item
Submit a request and have one of the approvers at level 1 approve.
Save button is enabled and responses can be changed

Modify the approval group at level 2 and add another user.
Open the request, delete level 2 approval, Save the approval.
Add level 2 back to the request and add the same original approval group which should now show the new user. Save
Have one of the user approve at level 2. It doesn't seem to matter what users approves, but more that additional users have been added.
I also tested removing a user from the original group, deleting the level, save, add level back and the save button is also disabled for this.

It seems that any changes made to the approval group, the level deleted, then readded back with the changes causes the save button to be disabled.

The requests are still pending approval and no final approval has been done because of the three levels and only modifying the process at level 2.

[CharlesW]

Well, I can't imagine it's expected behavior. Probably more like a corner case that was never considered.. Based on your reproduction steps, it must be the "isCurrRequestApprovedByFinalApprover" flag that is getting set incorrectly, when the approval process is changed.  I "believe" that it is the following query that is being run to set this flag:

SELECT Processed FROM dbo.wd_ApprovalProcess WHERE RequestID_FK = <requestID> AND Position = (SELECT MAX(Position) FROM dbo.wd_ApprovalProcess WHERE RequestID_FK = <requestID>

Can you try running this query against a request which is reproducing the  behavior and again for a request that is not reproducing the behavior? My assumption is that one request will return "0" and one will return "1". 

[CharlesW]

P.S. Don't forget to swap out <RequestID>  in the query with a the actual RequestID.

[TeriStevenson]

You're right!  The request that doesn't work Processed=1 and the one that does work Processed=0 using the query.  Any thoughts on how we can workaround this?  Will I need to set the flag at the database on the ones that have the issue?

[CharlesW · Accepted solution]

Well, I think that the only option will be to hack together a fix. Basically I'm thinking to hard code it so that it does not consider the approval stated at all when enabling/disabling the save button. Trying to fix the issue where the processed flag is set differently when you modify the approval process is likely to be something that will be complicated to fix. So I want to take the easy route.  Can you check your web folder to see if you have a RequestDetails.aspx.vb? If so, can you email it to me.  It seems like I had sent you a custom one years ago, but I may be thinking of somebody else.. If the file does not exist, then I'll send you some new files to bypass the approved check. 

[TeriStevenson]

I only found RequestDetails.aspx but not RequestDetails.aspx.vb.  I'll mail the RequestDetails.aspx

[jdempsey]

Did we ever manage to come to a resolution on this?

[TeriStevenson]

No, we're still trying to find a resolution for this one.