Issue

Cancelling an upload or deleting an uploaded file in the Attachment field prevents users from attaching the file a second time. 

Symptoms and Impact

Users receive "File already exists" errors when attempting to re-upload files with the same name after deletion.  This leads to confusion and inconsistent user experience. 

Steps to reproduce

1. Enable repository storage for attachments.  

2. Add an Attachment field to your View. For more information, see Configuring Views.  

3. In Pega Constellation, use an Attachment field to upload a file to a work object.  

4. Click Cancel or Delete to remove the file. 

5. Re-upload the file using the same name. Result: Error is seen onscreen:
   "The specified file/folder already exists in the target repository. Please specify a different file/folder."
    

Root Cause

This issue has been identified as a product feature gap.  

In Pega Constellation, when using Attachment fields, the upload and attach processes are separate. 

In a Flow Action which uses an attachment field, when a user adds a file, it creates a temporary attachment object, which gets stored in the repository, but is not attached until the Flow Action is submitted.   

Similarly, after adding a file, if the user deletes the file, the removal of the temporary attachment from the repository does not persist until the Flow Action is submitted. 

Solution

This issue is resolved in an upcoming Pega Infinity release.  The activity pyFormatAttachmentName has been modified to prefix Case ID and append timestamp.  Using FileName as an example, and for scenarios where Case ID exist, the format will be as follows:  

<CaseID>_FileName_<TimeStamp>.<extension> 

This ensures that each uploaded file gets a unique identifier even if it's the same document being reuploaded. This prevents the system from confusing it with the previously discarded file. 

Due to this change in the file name, users still have the ability to upload the same file multiple times.  In the new release, there will also be a background process that runs periodically to clear out orphaned attachments left in the repository.  

This known issue document will be updated when a release with a fix is made available.  

Workaround

Use the below local changes in releases where the fix is not yet implemented: 

A) Override activity  pyFormatAttachmentName to append a timestamp to the file name.  

Note that this removes the duplicate file restriction. 

B) After any Delete action, ensure that a Save or Submit is processed to ensure the delete call is sent to the server. 

References

Configuring Attachment fields 

File is not removed from repository after attachment upload failure and Case is moved into ProblemFlow  

Why Constellation's file attachment input field uses display: none 

Deleting an attachment does not delete the document in the repository  

Storing Case attachments using external storage