Bug Fixes

Issue: Edit Item Details - dropdowns save default value instead of remaining blank
Tracking Code: TAPSUP-2876
Case Number: 2021-0126-724310
Reported Version: All Versions
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Submit a workflow with dropdown form fields (leaving them unselected).
2. Check the dashboard to see that the associated dynamic columns are blank.
3. Edit a record and save changes without altering the dropdowns.

Expected Results of Steps
The associated dynamic columns stay blank.

Actual Results of Steps
The dashboard columns show '--Select one--'.

Resolution
The issue where dashboard columns displayed '--Select one--' has been resolved. Now, the associated dynamic columns will remain blank instead.

Root Cause Analysis
'--Select one--' string is displayed because the condition to ignore it is placed inside an if statement.

Impacted Areas
Edit record

Tested Areas

1. Preview and Submit the record
2. Edit the record and save
3. Edit the request and submit the record

---

Issue: The table does not appear in either the PDF or DOC documents.
Tracking Code: TAPSUP-7100
Case Number: 2023-0706-7902516
Reported Version: 1.14.3.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Add a document field and insert a table along with text.
2. Save and preview the workflow.
3. Once the request is completed, the preview document option will be available.
4. Preview the document in PDF and DOC formats; the text appears without the table.
5. After submitting the request, receive the document via email, click on review, and sign, and the document will be displayed without the table.

Expected Results of Steps
The table should be displayed in the document along with the data.

Actual Results of Steps
The table does not appear in the PDF and DOC documents.

Resolution
The issue where the table did not appear in PDF and DOC documents has been resolved. Now, the table, along with the data, will be displayed correctly in the documents.

Root Cause Analysis
The table border attribute was missing, so it has been added as required. Additionally, the table CSS was missing in the document generation CSS file.

Impacted Areas
Document Builder

Tested Areas
Document Builder content is converted to PDF or DOC format upon workflow submission.

Known issue
Table properties like table borders with width, and colors won’t work with the docx format. 

---

Issue: In the collaboration stage, when you click the save button for the 3rd time, the color and style changes. It is considering the CSS file settings of the Thank you page even before submitting to the next stage.
Tracking Code: TAPSUP-7141
Case Number: 2023-0711-7906898
Reported Version: 1.14.3.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Preview the workflow.
2. In the collaboration stage, click "Save" twice.
3. On the third click of "Save," the color changes to green, indicating it is adopting the CSS style of the Thank You page.

Expected Results of Steps
When you click save any number of times, it should only apply the CSS style of the collaboration stage until it is submitted.

Actual Results of Steps
When you click save for the third time in the collaboration stage, the color changes to green, indicating it is using the CSS style of the Thank You page.

Resolution
The issue where clicking save multiple times in the collaboration stage incorrectly applied the CSS style of the Thank You page has been resolved. Now, the CSS style of the collaboration stage is maintained regardless of how many times you click save, until it is submitted.

Root Cause Analysis
The collaboration stage update is triggering the ‘submitWorkflow’ method, which calls the Thank You page at the end. When the Thank You page is displayed, its CSS is being applied. To fix this issue, we need to check if the ‘submitType’ is a collaboration update. If it is, we should apply the stage CSS instead.

Impacted Areas
Collaboration Stage

Tested Areas

1. Collab stage update with CSS attachment (normal user)
2. Normal stage save with CSS attachment
3. Collab stage update with CSS attachment (anonymous user)

---

Issue: TAP - TeamConnect multi-select doesn't display correctly in notifications.
Tracking Code: TAPSUP-7259
Case Number: 2023-0728-7927696
Reported Version: 1.14.3.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Drag and drop a multi-select form field, and configure it to a TeamConnect multi-select table item.
2. Set it as the form result value at the relationship level.
3. Use the TeamConnect key, save the workflow, and preview the workflow.

Expected Results of Steps
The email notification should display the selected text value as it was chosen when the task was submitted.

Actual Results of Steps
The email notification displays an incorrect value (pre-key) instead of the actual text entered by the user.

Resolution
The issue where the email notification displayed an incorrect value (pre-key) instead of the selected text when the task was submitted has been resolved. Now, the email notification correctly displays the text value as chosen during task submission.

Root Cause Analysis
The TAP application once supported multi-select for TeamConnect tasks, but due to the code that was commented out in 2020, the "ValueText" isn't saved, resulting in default values being used.

Impacted Areas
Email Notifications

Tested Areas

1. Relationship Notifications
2. Stage Notifications
3. Collaboration Notifications
4. View History
5. Edit Request
6. Adhoc testing around other notifications

---

Issue: Disconnect between Dashboard and Audit Trail details.
Tracking Code: TAPSUP-7332
Case Number: 2023-0811-7946034
Reported Version: 1.14.3.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import the workflow.
2. Assign Stage 2 to the Test Role and use the email field.
3. Enter external user details in the email field and submit the first stage.

Expected Results of Steps
The current assignee on both the dashboard and audit trail should be the external user.

Actual Results of Steps
The audit trail shows 'TAP SYSTEM' as the current assignee instead of the external user details.

Resolution
The issue where the audit trail displayed 'TAP SYSTEM' as the current assignee instead of the external user has been resolved. Now, the current assignee is correctly shown as the external user on both the dashboard and the audit trail.

Root Cause Analysis
The code was not handling the situation when the current assignee was an external user and hence the current assignee was getting assigned the default value as 'TAP SYSTEM'. In the case of the external user, the user ID is empty, so in this case, we will just now assign the token's name to the current assignee.

Impacted Areas
Dashboard and Audit Trail

Tested Areas

The following are tested with both Registered and External Users:

1. ShowCompletedWorkflow
2. ShowTerminatedWorkflow
3. ShowActiveWorkflow
4. WorkflowViewHistoryReport
5. Embed/Anonymous Embed

---

Issue: Email notification received from the tap account(default.tap@thinksmart.com)  instead of the user added in the "From email roles" (eSignature support).
Tracking Code: TAPSUP-7759
Case Number: 2023-1013-8019881
Reported Version: TAP 1.15.7.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Set up an eSignature workflow that includes notifications.
2. In the notification settings, choose a user from "From email roles" and submit the workflow.
3. After the request is completed, an email notification will be received from the TAP account instead of the user specified in "From email roles".

Expected Results of Steps
Email notifications should originate from the designated user specified in "From email roles" (eSignature Support) rather than from the default TAP account (default.tap@thinksmart.com). 

Actual Results of Steps
Email notifications are being received from the default TAP account (default.tap@thinksmart.com)  instead of the designated user specified in "From email roles" (eSignature support)

Resolution
The issue where email notifications were being sent from the default TAP account (default.tap@thinksmart.com) instead of the designated user specified in "From email roles" (eSignature Support) has been resolved. Now, email notifications correctly originate from the designated user. 

Root Cause Analysis
When "EmailFrom" is not configured in the provisioning portal, the AppSettings retrieve empty values for "From". Currently, if "From" is empty, the code defaults to using a default email account for sending notifications. However, this approach ignores the role assigned in the eSignature notification, resulting in notifications continuing to be sent from the default account. The fix involves utilizing the selected user's account, and ensuring that notifications are sent using the associated user's email account.

If the custom notification doesn't have any "From" role assigned then the notification will be sent from the "From" role assigned in the workflow email settings. If neither the custom notification nor the email settings have any "From" role assigned, then the notification will be sent from the default tenant role.

Impacted Areas
eSignature notifications

Tested Areas

1. Various relationship notifications from role and default settings.
2. Multiple relationships within the workflow for notification handling.
3. Verified multiple stage notifications from role and default configurations.
4. eSignature and Echo Splitter notifications from role and default settings.
5. Verified notifications for both registered and non-registered users on eSignature notifications.
6. Different orders of sending notifications: eSignature notifications have precedence over Workflow-level roles, which in turn have precedence over Tenant-level roles.

---

Issue: Audit Trail for Canceled Record
Tracking Code: TAPSUP-7820
Case Number: 2023-1101-8039459
Reported Version: TAP 1.15.7.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import the workflow.
2. Ensure that eSign support is configured for relationship 1.
3. Submit the workflow and cancel the record from the dashboard.

Expected Results of Steps
Once the record is canceled, the audit trail should display the details of the user who performed the cancellation.

Actual Results of Steps
Once the record is canceled, the audit trail does not display the details of the user who canceled it.

Resolution
The issue where the audit trail did not display the details of the user who performed the cancellation has been resolved. Now, once the record is canceled, the audit trail correctly shows the details of the user who canceled it.

Root Cause Analysis
When setting up user ID details during the terminate workflow (via cancel API or cancel request action), an empty GUID is saved as the user ID, resulting in an empty username.

To fix this error, we now check if the GUID is empty. If it is, we get the value from appcommon.userid, which takes the value from the user session. In the case of API cancel, we pass user identity from the authorized token to the terminate workflow action.

Impacted Areas
Workflow with Esign

Tested Areas

1. Workflow with Regular Esign
2. Workflow with Splitter
3. Workflow with Cancel API 
4. Workflow without Esign

---

Issue: TeamConnect Record Search based on CSM, pre-population rule is not working on Office object in TAP.
Tracking Code: TAPSUP-8017
Case Number: 2023-0717-7913623
Reported Version: TAP 1.15.7.0
Workaround
For existing workflows with a TeamConnect company contact field:

• Reselect the value and save the workflow.

No changes are needed for new workflows or new pre-populations.

Additional Notes
Since the company contact pre-population is not working, you need to open the specific pre-population and reassign it to make the company contact pre-population function properly.

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Create a TAP form with three TeamConnect record-type fields based on TeamConnect Office and text fields for contact and email.
2. Map the office fields based on TeamConnect CSM.
3. Create two stages in the workflow and grant form access to the fields.
4. Create a pre-population rule in the first stage for the TeamConnect Office record to pull information into the contact field and any other field, such as email, on the TAP form.
5. Save the changes and initiate the workflow from TAP.
6. Export the form.

Expected Results of Steps
With the pre-population rule created for Office, it should pull the contact value and email from TeamConnect.

Actual Results of Steps
The pre-population rule is not working correctly; the contact and email fields remain blank when the office is provided in the workflow.

Resolution
The issue where the pre-population rule did not correctly pull the contact value and email from TeamConnect, resulting in blank fields when the office was provided in the workflow, has been resolved. Now, the pre-population rule accurately retrieves and displays the contact value and email as expected.

Note: It functions correctly for other fields like phone number and email, but it does not work for the contact field.

Root Cause Analysis
In TAP, the "CONTACT" type is currently not being handled properly. Instead of retrieving the exact details, the TEAMCONNECT SOAP API returns a default entity, such as ThinkSmart.TeamConnect.API.ContactRepository.contact. To obtain specific details, we need to send a specific property, i.e., contact.name. The Contact is an object nested within the office object.

Impacted Areas
Prepopulation Using TeamConnect

Tested Areas

1. Prepopulate nested objects in TeamConnect (e.g., search field in Personal Information (contact)) with field type CONTACT.
2. Various fields in TeamConnect to ensure proper prepopulation.
3. Conducted ad-hoc testing around lookup table prepopulation.

---

Issue: e-Signature support notification is not being received by the CC list.
Tracking Code: TAPSUP-8020
Case Number: 2023-1013-8019198
Reported Version: TAP 1.15.7.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Preview the workflow.
2. Add e-signature to the relationship and submit stage 1.
3. Configure notifications in Esign, including signers and CC recipients.
4. Upon request submission, the CC recipients do not receive the custom notification or attachments added in Esign.

Expected Results of Steps
The email address CC'ed should also receive the notification added in the E-signature.

Actual Results of Steps
Only the signer is receiving the email, while the CC recipient is not.

Resolution
The issue where only the signer received the email while the CC recipient did not has been resolved. Now, the email address CC'ed will also receive the notification added in the e-signature.

Root Cause Analysis
The CC list is being sent as empty in the EsignWithoutEsignature service call.

To fix this issue, we need to pass the CC emails list to the sendEmail method within the EsignWithoutEsignatureService call.

Impacted Areas
Esign custom notification

Tested Areas

1. Esign custom notification (with cc, signer, approver) – docusign (with and without esplitter)
2. Esign custom notification (with cc, signer, approver) – adobesign (with and without esplitter)

---

Issue: Workflow Documentation appears to only create page 1 of documentation instead of all the content of the workflow.
Tracking Code: TAPSUP-8022
Case Number: 2023-1122-8063722
Reported Version: TAP 1.15.7.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import the attached workflow.
2. In the workflow options, select "Documentation". However, only the details for completing page 1 of the documentation are displayed, rather than the complete workflow details.

Expected Results of Steps
The Workflow Documentation should present all the contents of the workflow.

Actual Results of Steps
The Workflow Documentation should comprehensively display all the contents of the workflow. Currently, only a single page of documentation can be created.

Resolution
The issue where only a single page of documentation was being created has been resolved. The Workflow Documentation now comprehensively displays all the contents of the workflow as expected.

Root Cause Analysis
If a user adds form mapping with a child type as multi-select and provides a value without any options, a null exception occurs, halting the entire workflow documentation flow.

To resolve this issue, we have implemented checks for null and empty values.

Impacted Areas
Workflow documentation with multi-select child type

Tested Areas

1. Workflow documentation with multi-select child type (form mapping) and value empty
2. Workflow documentation with multi-select child type (form mapping) and value non-empty

---

Issue: TAP - audit trail IP address showing Load balancer IP on the Signature field.
Tracking Code: TAPSUP-8024
Case Number: 2023-1211-8079754
Reported Version: TAP 1.15.9.1
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Create a workflow that includes a Signature field on the form.
2. Initiate the workflow and sign on the designated Signature field.
3. Review the audit trail for logged actions.

Expected Results of Steps
The user's machine IP address should be visible in the audit trail.

Actual Results of Steps
The IP address shown in the audit trail does not match the signer's IP address. You can verify this by using the ipconfig command on the command line (Windows).

Resolution
The issue where the IP address shown in the audit trail did not match the signer's IP address has been resolved. The audit trail now accurately displays the user's machine IP address, which can be verified using the ipconfig command on the command line (Windows).

Root Cause Analysis
In the current implementation, the IP address is retrieved using the following property:

public string UserIpAddress => HttpContext.Current?.Request.UserHostAddress;

This captures the host IP address and saves it as part of the signature field value.

Due to the use of a multi-node setup and load balancer in our Azure environment, the IP addresses of the host machines vary each time an e-signature field is submitted.

To resolve this issue, we need to retrieve the client's IP address and save it as part of the signature field data, ensuring it reflects the user's submission location accurately.

Impacted Areas
IP address on viewhistory 

Tested Areas

1. Checked the IP address on view history (for signature field) (single node environment)
2. Checked the IP address on view history (for signature field) (multi-node environment)

---

Issue: Cannot Find Customer Name Search Drop-Down Field.
Tracking Code: TAPSUP-8027
Case Number: 2023-1109-8049844
Reported Version: TAP 1.15.7.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import the workflow.
2. Preview the workflow. 
3. After adding requester details, attempt to search for the desired name in the "Customer or Partner Company Name" field (SFDC). 
4. However, it does not display the expected single-word details; instead, it shows other names.

Expected Results of Steps
When attempting to search for a customer name, the Customer or Partner Company Name field should display the desired single-word details.

Actual Results of Steps
When attempting to search for a customer name, the Customer or Partner Company Name field does not display the desired single-word details; instead, it shows names that contain more than one word.

Resolution
The issue where the Customer or Partner Company Name field displayed names containing more than one word instead of the desired single-word details during a search has been resolved. The field now correctly displays the single-word customer names as expected.

Root Cause Analysis

1. The first issue reported by the client does not necessitate a system change. Our current search functionality returns results containing the searched word, limited by the SalesforceSelectLimit variable set to 50 records for this client. Increasing this value, for example to 100, may resolve the issue.
2. Previously, we did not handle the ' character due to its impact on the LIKE query. This was because the initial query used that character to delimit the search term.

Impacted Areas
Customer or Partner Company Name field

Tested Areas

1. Mapping Salesforce values based on search terms using dedicated fields
2. Form mapping for Salesforce records
3. Prepopulation

---

Issue: Workflow AutoSubmit Error
Tracking Code: TAPSUP-8274
Case Number: 2024-0118-8117087
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce 

1. Ensure we have multiple tenants and workflows with eSignature setups on relationship 1, with at least one workflow using a specific eSign account under the API tab.
2. At the same time using initiate workflow API and TAP application submit created workflow's from multiple tenant's - the issue will replicate.

Expected Results of Steps
The records should move to the Esign path and be automatically submitted.

Actual Results of Steps
The records are not being automatically submitted.

Resolution
The issue where records were not being automatically submitted and moved to the e-sign path has been resolved. Records now correctly transition to the e-sign path and are automatically submitted as expected.

Root Cause Analysis
When services call methods asynchronously, the wrong tenant ID is passed to appsettings, leading to incorrect tenant settings being read. To avoid this, we are retrieving settings using the repository.

Impacted Areas
ESignature field

Tested Areas

1. ESignature for all three types
2. Enabling Send from a specific user
3. Submit using UI and API
4. In the combination of Autosubmit

---

Issue: Mapping not working for TeamConnect Field.
Tracking Code: TAPSUP-8277
Case Number: 2024-0226-8158502
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Go to the desired workflow.
2. Note that the first field, "Disposition Type," is mapped to TeamConnect and has a predefined value set on the TeamConnect end.
3. Launch the workflow and observe that the first field should display the predefined value.
4. However, you will encounter a "field required" error immediately after launching the workflow.

Expected Results of Steps
The predefined value set in TeamConnect should be displayed. Instead, an error appears, indicating that the API call from TAP to TeamConnect is not functioning correctly.

Actual Results of Steps
We see a "Field Required" error immediately after launching the workflow, with the field appearing empty.

Resolution
The issue where a "Field Required" error appeared immediately after launching the workflow, and the field displayed as empty instead of showing the predefined value set in TeamConnect, has been resolved. The API call from TAP to TeamConnect is now functioning correctly, and the predefined value is displayed as expected.

Root Cause Analysis
Form mapping to the TeamConnect lookup dropdown was not implemented.

Additionally, a bug was identified where the form mapping runs before the dropdown is populated with TeamConnect values, causing the form mapping to fail. This was addressed by implementing a timeout and retry logic to wait for the TeamConnect values. Further changes are needed to define a pipeline to execute show workflow tasks in the UI.

Impacted Areas
Form mapping with TeamConnect lookup dropdown.

Tested Areas
Form mapping with TeamConnect lookup dropdown.

---

Issue: Unable to send data from TAP to TeamConnect for hidden field and Multi-select field.
Tracking Code: TAPSUP-8415
Case Number: 2024-0314-8179426
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import and preview the workflow.
2. Note that the "Multi-Select value" field is connected to TeamConnect.
3. A formula field is linked to the Multi Select value field.
4. When previewing and selecting multiple values, they should appear in the formula field, but they are not.
5. If you change the options to "Use datasource as a field," the selected values will display correctly.

Expected Results of Steps
Even when the options are connected to TeamConnect integration, the values should be displayed.

Actual Results of Steps
Values do not appear when TeamConnect keys are added.

Resolution
The issue where values did not appear when TeamConnect keys were added, despite the options being connected to TeamConnect integration, has been resolved. The values are now correctly displayed as expected.

Root Cause Analysis
TAP lacked code to retrieve values from a dropdown or multifield originating from TeamConnect. It appears that this code was removed in 2020.

Impacted Areas
Notifications

Tested Areas

1. Relationship Notifications
2. Stage Notifications
3. Collaboration Notifications
4. View History
5. Edit Request
6. Submit & Save Field with TeamConnect
7. TeamConnect values from fields in documents
8. Formulas getting values from TeamConnect fields

---

Issue: Error in the administration section
Tracking Code: TAPSUP-8785
Case Number: 2024-0412-8212409
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Log in to TAP.
2. Navigate to administration.
3. Use an email ID with special characters and attempt to add it to the Adobe Sign Connection.
4. Enable "Send on Behalf" and add the email with special characters in the new field displayed beside it.

Expected Results of Steps
You should be able to save the field with an email ID containing special characters as well.

Actual Results of Steps
An error occurs if there is a special character in the email ID.

Resolution
The issue where an error occurred when saving a field with an email ID containing special characters has been resolved. You can now save email IDs with special characters without encountering errors.

Root Cause Analysis
When using a special character in an email account and sending it for verification, the response comes in an HTML-encoded format. Therefore, we need to decode the received email address from HTML.

Impacted Areas
Email accounts with special characters

Tested Areas

1. Tested scenarios for SendOnBehalf functionality:

   1. With existing and new users
   2. Validation using ESignAccount APIs
   3. Workflow record submissions with E-signature setups (normal, e-splitter, multiple signers)
   4. Positive and negative scenarios

2. Email accounts with and without special characters

---

Issue: Save Button E-mail Link not working for client workflow.
Tracking Code: TAPSUP-8878
Case Number: 2024-0326-8194813
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Log in to TAP.
2. Access the imported workflow.
3. Preview the workflow, fill in the email field, and click "Save".
4. A pop-up will appear with the option to send an email link.

Expected Results of Steps
When we click on "Email the URL", the email should be sent to the user ID filled in the email section.

Actual Results of Steps
The email is not being delivered to the inbox.

Resolution
The issue where emails were not being delivered to the inbox when clicking "Email the URL" has been resolved. The email is now correctly sent to the user ID specified in the email section.

Root Cause Analysis
There was an issue with the CSHTML code where the element ID details were not being passed, causing the email notification issue.

Impacted Areas
Email link

Tested Areas

1. Save button functionality 
2. Verified the email link after saving
3. Verified the email inbox for receiving the email
4. Ensured the link in the email directed to the workflow
5. Functionality for collaboration

---

Issue: Issue with Regex Expression in TAP
Tracking Code: TAPSUP-8453
Case Number: 2024-0411-8211356
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Create a workflow with a Textbox and a Text Area.
2. For the Text Area, create a formula.
3. Save and preview the workflow.
4. Enter any text in the Textbox separated by commas (",") e.g., "one, two, three, four".
5. The entered text should be converted and displayed as rows in the Text Area.
6. Example Output:
   1. One
   2. Two
   3. Three
   4. Four

Expected Results of Steps
The  input from the text field should parse and convert into a list as follows:
one
two
three
four

Actual Results of Steps
The input from the text field is not able to parse the input from the text field.

Resolution
The issue where input from the text field could not be parsed and converted into a list has been resolved. The input is now correctly parsed and converted into the list as expected:

• one
• two
• three
• four

Root Cause Analysis
This issue has been present since 2019. The system was implemented to return only single-match records, which caused it to always return the first value only.

Impacted Areas
Formulas with Regex pattern functionality

Tested Areas

1. Formulas with Regex pattern functionality
2. Use client-provided pattern
3. Use general Regex patterns

---

Issue: Certain fields are prepopulated and rendered as read-only, preventing manual editing. However, we discovered that copying and pasting information into these fields still works which shouldn't be the case.
Tracking Code: TAPSUP-8783
Case Number: 2024-0430-8230049
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Create a workflow with a field that has pre-population enabled.
2. Set the field's pre-population rule to "Read-only."
3. Preview the workflow.
4. Try to select the pre-populated field and paste the different text into it.

Expected Results of Steps
Editing the prepopulated field using the copy-paste option should not be allowed.

Actual Results of Steps
We can modify the prepopulated field by using the copy-paste option.

Resolution
The issue where the prepopulated field could be modified using the copy-paste option has been resolved. Editing of the prepopulated field through copy-paste is now restricted as expected.

Root Cause Analysis
The issue arises from the custom-paste functionality in the code. We need to implement read-only validation to prevent this.

Impacted Areas
Prepopulation Fields

Tested Areas

1. Copy-paste functionality
2. Textbox with pre-population
3. Textbox without pre-population

---

Issue: Issue with HTML Table in doc builder.
Tracking Code: TAPSUP-8547
Case Number: 2024-0515-8244999
Reported Version: TAP 1.17.1
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Go to Designer and create a new workflow
2. Add a custom HTML field to the form
3. Add a table component to it with text
4. Open the preview of the workflow

Expected Results of Steps
The table should be visible.

Actual Results of Steps
The table is currently not visible; only the text is displayed.

Resolution
The issue where only the text was displayed and the table was not visible has been resolved. The table is now correctly displayed as expected.

Root Cause Analysis
The properties defined in Base.css are taking precedence over the inline properties specified in the Custom HTML Table.

Impacted Areas
Table elements

Tested Areas

1. Inserting a table element using the Custom HTML form field.
2. Verified the properties of the Custom HTML table, including:
   1. Table border
   2. Table alignment
   3. Table cell spacing
   4. Table cell padding
   5. Table rows and columns

---

Issue: Document is stuck with "Pending to Send for E-sign" status.
Tracking Code: TAPSUP-8571
Case Number: 2024-0412-8212266
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Create a sample Workflow in the Default Docusign environment.
2. Preview and submit the Workflow.
3. Do not click on "Send" on the Thank You page.
4. Check the Audit Trail and Signature Repository to find the document in "Pending to Send for E-sign."
5. In the Signature Repository, under actions, click on "Cancel." However, the agreement status still shows as "Pending to Send for E-sign" in both TAP and the Signature Repository.
6. Check the History in the Signature Repository. It shows that the document is deleted and voided, but the Agreement status remains "Pending to Send for E-sign."
7. Similarly, if you click on "Cancel Signature" or "Edit and Cancel E-sign," it indicates that the document is canceled. However, in the Audit Trail and Signature Repository, the agreement status still displays "Pending to Send for E-sign."

Expected Results of Steps
When the document is canceled, the agreement status should be updated to "canceled" in TAP.

Actual Results of Steps
When the document is canceled, the status in TAP should update correctly and should not remain stuck at "Pending to Send for E-sign."

Resolution
The issue where the document status remained stuck at "Pending to Send for E-sign" instead of updating to "canceled" in TAP has been resolved. The agreement status now correctly updates to "canceled" when the document is canceled.

Root Cause Analysis
The scenarios where documents transition from "Pending to Send for E-sign" to "Cancelled" status were not integrated into TAP previously, but have been addressed in this ticket.

Impacted Areas
Cancel requests

Tested Areas

1. Cancel Signature Dashboard without e-Splitter.
2. Edit And Cancel Sign- With Splitter
3. Remove Record From Dashboard
4. Cancel Request From Dashboard
5. Cancel From Signature Repository
6. Cancel Documents from API

---

Issue: When we launch the workflow with the Anonymous user link, form mapping is not populating the TeamConnect Record Search field successfully.
Tracking Code: TAPSUP-9085
Case Number: 2022-0125-883115
Reported Version: TAP 1.7.4
Workaround
None

Pre-Requisites

1. Access to TAP
2. Team connect integration in TAP
3. Anonymous Access

Steps to Reproduce

1. Launch the workflow and submit the form by entering a contact name. 
2. Click outside the Contact Name field to trigger the form mapping, which sets the TeamConnect Contact field to the entered contact.
3. Access the workflow using the anonymous access link in a browser. 
4. Repeat the same steps of entering a contact name and clicking outside the Contact Name field. Note that the form mapping does not trigger, and consequently, the TeamConnect Contact field remains unset.

Expected Results of Steps
Pre-populated values should be visible based on form mapping.

Actual Results of Steps
Pre-population values are not being populated correctly.

Resolution
The issue where pre-populated values were not being populated correctly has been resolved. Pre-populated values now display as expected based on form mapping.

Root Cause Analysis
The related form mapping methods were not accessible for anonymous user access:

• showworkflow/GetTCRecordRowByParentId
• showworkflow/GetTCRecordRowByTokenId
• showworkflow/GetTCRecordsFormMapping
• showworkflow/TeamConnectRecordsFormMapping

Therefore, we have now whitelisted these methods.

Impacted Areas
Form Mapping

Tested Areas

Test scenarios include both normal workflow and anonymous workflow setups.

1. Form mapping involving a TeamConnect search field as a parent with any other form field as children.
2. Form mapping involving a TeamConnect search field as a child with any other form field as parents.

---

Issue: Next Signer Information Not Showing Up In the Dashboard.
Tracking Code: TAPSUP-9113
Case Number: 2024-0423-8222458
Reported Version: TAP 1.17.4.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import the workflow.
2. Preview the workflow and submit the form following the recording. The next signer does not appear in the dashboard.
3. Initiating the workflow from a different stage or skipping stages functions properly, and the next signer is visible.

Expected Results of Steps
The next signer should appear in the Dashboard regardless of whether the workflow is initiated from the intake stage.

Actual Results of Steps
The next signer does not appear on the Dashboard when the workflow is initiated from the intake stage.

Resolution
The issue where the next signer did not appear on the Dashboard when the workflow was initiated from the intake stage has been resolved. The next signer now appears on the Dashboard as expected, regardless of the workflow initiation stage.

Root Cause Analysis
At certain locations, local time is employed instead of UTC, leading to errors in queries reliant on date ordering and filtering.

Impacted Areas
ESignature quick check

Tested Areas

1. ESignature quick check
2. Signature repository
3. Edit request dashboard action
4. View history dashboard action
5. Dashboard and Get Dashboard data API
6. Documents dashboard action

---

Issue: Submission error
Tracking Code: TAPSUP-9142
Case Number: 2024-0402-8200454
Reported Version: TAP 1.17.4.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Go to the workflow.
2. Enter the necessary information.
3. Submit the request.

Expected Results of Steps
The workflow should proceed without any errors during submission.

Actual Results of Steps
After submission, an error with blank HTML rendering appears.

Resolution
The issue where an error with blank HTML rendering appeared after submission has been resolved. The workflow now proceeds without any errors during submission.

Root Cause Analysis
This issue occurred because the template for document fields in Document Builder documents was empty. When attempting to create a document with an empty template, the process failed. We have now written the necessary code to assign values to the template.

Impacted Areas
Document Builder documents

Tested Areas

1. Team Connect Support/Options/Attachments
2. Sales Force Support/Attachments
3. Attachments in Edit Request/ Documents/View History-Doc Builder
4. E-signature - Doc Builder
5. Relationship Notification with Attachments
6. Stage Notification with Attachments 
7. Document Builder-Add To relationship and Remove from Relationship
8. Collaboration Notification

---

Issue: In Pre-population, rule field is read-only but the user is still able to edit using copy/paste.
Tracking Code: TAP-35425
Case Number: N/A
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Import the workflow with the appropriate CSS and data sources.
2. Confirm that the "requestor" field is pre-populated.
3. Copy the content from the "requestor" field to the clipboard.
4. Paste the copied content back into the "requestor" field.

Expected Results of Steps
The field should remain uneditable, even when trying to modify it using copy and paste.

Actual Results of Steps
In the pre-population rule, the field is set to read-only, but users are still able to edit it using copy and paste.

Resolution
The issue where a field set to read-only in the pre-population rule was still editable via copy and paste has been resolved. The field now remains uneditable as expected, even when using copy and paste.

Root Cause Analysis
The issue arises due to the custom code for the paste functionality. We need to add read-only validation to resolve this.

Impacted Areas
Prepopulation Fields

Tested Areas

1. Copy-paste functionality
2. Textbox with pre-population
3. Textbox without pre-population

---

Issue: Broken Adobe Esign Configuration Process
Tracking Code: TAP-48909
Case Number: N/A
Reported Version: TAP 1.16.3
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Try to connect an AdobeSign key to any TAP environment.
2. Enter your Account ID and account credentials.
3. Observe that you are redirected to an error page.

Expected Results of Steps
TAP should redirect to a page where you can enter the Client ID and Secret. After this, the key should connect successfully.

Actual Results of Steps
An error occurs on the redirect page. To connect the key, copy the URL, paste it into a new window, and replace the oAuthredirect value with the tenant value. You will then be successfully redirected to the Client ID/Secret entry page.

Resolution
The issue where an error occurred on the redirect page, preventing successful connection of the key, has been resolved. TAP now correctly redirects to a page where you can enter the Client ID and Secret, allowing for successful key connection without needing to manually modify the URL.

Root Cause Analysis
We have a method to check the cookie for the redirect URL, but the cookie is not available when authenticating from the Adobe screen.

To address this, we added a check to verify whether the cookie is available. If it is not, the system will use the host URL from the appcommon property, which was saved when creating the Adobe key.

Impacted Areas
Automatic redirection to the Client ID and Client Secret screen after Adobe authentication.

Tested Areas
Automatic redirection to the Client ID and Client Secret screen after Adobe authentication.

---

Issue: When we launch the workflow with Anonymous user link, form mapping is not populating Salesforce Record Search field.
Tracking Code: TAP-48990
Case Number: N/A
Reported Version: TAP 1.7.4
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Launch the workflow and submit the form by typing a contact name.
2. Click out of the Contact Name field to trigger the form mapping.
3. Ensure that the Salesforce records field receives the details.
4. Use the anonymous access link in a browser and follow the exact same steps.
5. Note that the form mapping does not trigger, and the Salesforce search field does not receive any data.

Expected Results of Steps
Pre-populated values should be sourced from form mapping.

Actual Results of Steps
Pre-population values from the form mapping are not visible.

Resolution
The issue where pre-population values from form mapping were not visible has been resolved. Pre-populated values are now correctly sourced and displayed based on form mapping.

Root Cause Analysis
The related form mapping methods were not authorized for anonymous user access.
To address this, we have whitelisted the following methods:

• showworkflow/GetSFRecordsFormMapping
• showworkflow/SFRecordsFormMapping

Impacted Areas
Form Mapping

Tested Areas
Following scenarios in both normal workflow and anonymous workflow contexts:

1. Form mapping where the Salesforce (SF) search field is the parent and another form field is the child.
2. Form mapping where the Salesforce (SF) search field is the child and another form field is the parent.

---

Issue: Any call to workflows/all endpoints returns an error.
Tracking Code: TAPSUP-9256
Case Number: 2024-0624-8283564
Reported Version: TAP 1.17.4.0
Workaround
None

Pre-Requisites
Access to TAP

Steps to Reproduce

1. Create an access token using the TAP API.
2. Use TAP API to get the workflow dashboard records.

Expected Results of Steps
No error occurs in the workflow.

Actual Results of Steps
The error occurs whether filters are applied or not.

Resolution
The issue where an error occurred regardless of whether filters were applied has been resolved. The workflow now functions without any errors.

Root Cause Analysis
The AppSettings code uses static class-level fields, leading to inconsistencies in reading the toggle for using the stored procedure in a multi-tenant environment. This causes incorrect parsing of the data returned by the stored procedure, resulting in code errors.

• Short-term fix/patch: Decouple the logic to parse the field from the toggle.
• Long-term fix: Refactor the AppSettings code to prevent inconsistent settings reading.

Impacted Areas
Workflow with API calls

Tested Areas

1. "Get All" API workflow
2. Workflow with the advanced filter applied
3. Workflow with page = 0 (to check total records)
4. Stored Procedure (SP) and LINQ

---