Unable to delete form submissions from code

Ed Wilson

Vote:

We have a scheduled job almost identical to the one detailed here : http://www.herlitz.nu/2018/10/15/episerver-forms-cleanup-for-gdpr/ for deleting user data when that database is used in a non-production environment. When this runs there is an NullReferenceException exception thrown on 3/70 forms when its attempting to delete the submissions

Object reference not set to an instance of an object
at EPiServer.Forms.Core.Data.FormDataRepository.DeleteUploadFile(ISubmissionStorage submissionStorage, FormIdentity formIden, String submissionId)
at EPiServer.Forms.Core.Data.FormDataRepository.DeleteSubmissionData(ISubmissionStorage submissionStorage, FormIdentity formIden, String[] submissionIds)
at EPiServer.Forms.Core.Data.FormDataRepository.DeleteSubmissionData(FormIdentity formIden, String[] submissionIds)

I then tried clearing one submission at a time on the problem forms

foreach (var sub in submittedData)
{
	sub.Data.Clear();
	submissionStorage.SaveToStorage(formIdentity, sub);
}

which revealed that there was one submission each form that had an issue and the exception is now a FormatException

Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
at System.Guid.GuidResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument, String failureArgumentName, Exception innerException)
at System.Guid.TryParseGuidWithDashes(String guidString, GuidResult& result)
at System.Guid.TryParseGuid(String g, GuidStyles flags, GuidResult& result)
at System.Guid.Parse(String input)
at EPiServer.Forms.Core.Data.DdsPermanentStorage.SaveToStorage(FormIdentity formIden, Submission submission)

If I create a form submission myself I can see that the id of the submission was 8658704:CFA0CC6C-2973-493E-A3A8-B6C05DC07DA8 and there is no exception when it is cleared by the job.

But for one of the submissions that is throwing the exception the submission id is 7883982:5D8D3B79-D542-4543-BF59-21786095E7F5 which looks valid but still throws that exception.

My plan was to alert us to the exception with information about the form and the submission id so that we could go to the Production CMS, find that submission and delete it so that it wouldn't bother us again. I've discovered though, if I select that single submission in the CMS and click Delete, then I get the NullReferenceException again and the submission isn't deleted.

System.NullReferenceException: Object reference not set to an instance of an object.
   at EPiServer.Forms.Core.Data.FormDataRepository.DeleteUploadFile(ISubmissionStorage submissionStorage, FormIdentity formIden, String submissionId)
   at EPiServer.Forms.Core.Data.FormDataRepository.DeleteSubmissionData(ISubmissionStorage submissionStorage, FormIdentity formIden, String[] submissionIds)
   at EPiServer.Forms.EditView.Controllers.FormsDataStore.DeleteData(ContentReference contentLink, String[] submissionIds)
   at lambda_method(Closure , ControllerBase , Object[] )
   at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(Controller

However, if I select all entries on the form and then click the Delete icon then it does clear all the form submissions without any issues. Deleting all the submissions in Production isn't something that we can do or the client wouldn't be very happy!

I'm wondering if anyone could

a) Suggest what might be wrong with the form submission and a way to fix or delete it. The stack traces suggest it might be something to do with the uploaded file on the submission, but looking at them in the CMS there is no file upload shown on the submission - perhaps it has a partial record of an upload?

b) Help me understand how the submissions are deleted en masse from the CMS Delete icon when all form items are selected so that I can use this different approach in the scheduled job.

For some background, the site has recently been upgraded from EPiServer 9.10 to EpiServer 11.11 and its hosted in DXC. However, all the problem submissions are prior to the upgrade.

Thanks

#202975

Apr 04, 2019 18:39

Binh Nguyen Thi

Vote:

Is there any file upload elements in your form? Could you check the value of that file upload element for failure cases (by debugging or looking at the database)?

I guest that there are some users uploading file within unallowed file type. For example: you have only media types for pdf and image but I uploaded a word file. So what's happen?

You won't see file upload value in that submission view but there is still invalid file upload value behind the scene.

#202982

Apr 05, 2019 3:20

Binh Nguyen Thi

Vote:

Here are some cases you can check with your case:

https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2019/3/form-file-upload-not-working/#201950

https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2019/1/episerver-forms-file-upload---control-of-file-destination/

#202983

Apr 05, 2019 3:24

Ed Wilson

Vote:

It turns out the problem submissions were ones with stored data against an upload field but where the source of that field value was empty.

Looking into the code behind DeleteUploadFile

...
string source = propertyBag[elementName].ToString();
string[] separators = new string[1]{ "|" };
foreach (string splitBySeparator in source.SplitBySeparators(separators))
{
  IContent content = this._urlResolver.Service.Route(new UrlBuilder(splitBySeparator));
  if (content != null && content is IContentMedia)
	this._contentRepository.Service.Delete(content.ContentLink, true, AccessLevel.NoAccess);
}
...

if source is an empty string then SplitBySeparators returns null so this line was the cause of the NullReferenceException I was seeing.

When I then tried to process each submission manually, the FormatException was caused by the fact that the submission id's seem to be stored in a string like "8658704:CFA0CC6C-2973-493E-A3A8-B6C05DC07DA8". When these ids are passed into DeleteSubmissionData it must extract the guid. However, the same is not true with SaveToStorage - it wants the submission passed in to already be just a guid.

So, I've managed to solve the problem and my job now removes these problem submissions. The code isn't very pretty though I'm having to catch exceptions, manipulate the submissions and then try the alternative approach of clearing.

#203003

Apr 05, 2019 15:53

valdis

Vote:

would recomment to submit bug for them

#203264

Apr 14, 2019 15:00

Ed Wilson

Vote:

Thanks - I've let them know.

#203272

Apr 15, 2019 10:33

Quan Tran

Vote:

Thank you all for letting us know.

This has been fixed in new version 4.24.3.

#203790

May 07, 2019 12:33