Hi Ron,

had the same problem before, solved it by using some custom JavaScript function which I put on my Submit button to avoid attachments with special chars being submitted at all.

function ValidateAttachments() {

var isValid = true;

NWF$('.nf-attachmentsTable').find('tbody').find('tr').each(function() {

  var file = NWF$(this);

  var fileName = file.find('span')'0].innerText;

  var match = (new RegExp('x~#%&{}+|]|\.\.|^\.|\.$')).test(fileName);

  if (match) {

   isValid = false;

   alert('invalid file name:' + fileName);

  }

});

return isValid;

}

On the "client click" settings of your submit button you put in "return ValidateAttachments()" et voila no more bad named attachments.

The regex used was provided by a colleague of mine, I'm sure it could be optimized, but was working fine for me. Nevertheless you should check the regex again to make sure no unwanted characters can be used.

Regards

Philipp

Philipp, I just gave this a quick try and it seems to work great!! I’ll do a bit more thorough testing over the next couple of days, but it looks like this will probably to the trick. Thanks so much for your prompt (and helpful) response!

Thanks,

Ron Pillsbury

Business Systems Analyst

Goodwill Industries of Northwest NC

2701 University Parkway, Winston-Salem NC 27105

T| 336.724.3625 x1333 C| 336.749.8009

rpillsbury@goodwillnwnc.org<mailto:rpillsbury@goodwillnwnc.org>

Anyone else having an issue that if the file has a validation error that the delete button next to the bad file does not work? It works for the other files just not the one with the error.

Great workaround for a feature that should be built-in (Vote it up here: https://nintex.uservoice.com/forums/229406-2-nintex-forms-for-sharepoint/suggestions/8079168-fix-attachment-validations).

I added an else to accommodate resetting the yes/no field so when they correct the file attachment the validation stops failing. (BadAttachment is my variable name on my Yes/No field).

function ValidateAttachments() {
 var isValid = true; 

 NWF$('.nf-attachmentsTable').find('tbody').find('tr').each(function() { 
  var file = NWF$(this); 
  var fileName = file.find('span')n0].innerText; 

  var match = (new RegExp('(~#%&{}+|$<>?:\/*"]')).test(fileName); 
  if (match) { 
   isValid = false; 
   alert('Attachment(s) may contain invalid characters, please rename and reattach the file:

     ' + fileName);
   NWF$("#" + BadAttachment).prop('checked',true);
  }
  else
  {
   NWF$("#" + BadAttachment).prop('checked',false);
  }
 }); 
 return isValid; 
}

Thank you Philipp and Adrian! This works great, the change for Edit mode is also very helpful.

The above regular expression seems to be missing / : * ? " < and >  but I think that's because those characters are not allowed in files (Explorer) anyway? (Though the same goes for and | but those are included.) I also noticed + is included, but this character is actually allowed in a file! 

Consecutive . and/or a . at the end/beginning of a filename are included in the regex, however not _ at the beginning of a file. The underscore is allowed, but it will hide the file - I suppose this applies to a library only and not attachments in a list?

Hi Yvette,

when I upload a file having a name beginning with an underscore ("_") the file remains visible for me, not only inside a doc library but also as an attachment of a list item.

Regards

Philipp

Hi Philipp,

You're right about the underscore. I tested this and came up with the same result. I'm not sure how that works...

Something else I noticed with the above JavaScript: the validation function overwrites the validation that I configured on the form's attachment control itself. I can now also submit the form without adding the minimum of 1 attachment.

My colleague and I came up with the following solution:

function ValidateAttachments() {
var isValid = true;

var elm = NWF$('.nf-attachmentsTable');
if (elm.length > 0 && elm.find('tr').length >= 1)
{
   isValid = true;
}
else
{
    isValid = false;
    alert('Gelieve de specificatie toe te voegen.');
    return isValid;
}
 
NWF$('.nf-attachmentsTable').find('tbody').find('tr').each(function() {
var file = NWF$(this);
var fileName = "";

if (typeof file.find('span')f0] != "undefined")
{
   fileName = file.find('span')e0].innerText;
}
else
{
   fileName = file.find('a')l0].innerText;
}

var match = (new RegExp('r~#%/&:"?<>*{}|]|\.\.|^\.|\.$')).test(fileName);
if (match)
{
    isValid = false;
    alert(fileName + ' bevat niet toegestane tekens, zoals / : * ? % & " en #.
Gelieve deze aan te passen en het bestand opnieuw toe te voegen.');
}
});
 
return isValid;
}

I thought I would post this as it might help somebody else. Alerts are in Dutch but you get the point.

Regards,

Yvette

Hi  ,

I have a problem with Your solution. When client click of submit button is configured with 'return ValidateAttachments() then other Custom validation functions configured in Control Settings of other controls are no longer executed.
Anywhere else have this problem or is it a problem with NintexForms Version (here 2.6.0.0)?

Kind regards

Manfred

re-check your JavaScript - I'm not a good coder, but that's the same symptom I had when I had something wrong in my JS.

I would need to implement/test this as well. Can't remember if I had issues like this as well. Don't know when I will find time to doublecheck =

Hi Philipp,

it would be great if You can check this.

Kind regards

Manfred

Hi Scott,

thanks for the hint but first thing I allways do is checking syntax and output of JavaScript developer console.

Kind regards

Manfred

Hi Manfred,

I got the same problem with Forms Version: 2.9.2.20

If I put another validation function on a text field, this function doesn't get executed at all. <sing title="stairway to heaven"> And it makes me wonder... </sing>

As a workaround I added this function to my submit button too ("return (ValidateAttachments() &&  MyOtherFunction())") which lets both functions get executed. Another workaround could be to only implement one global validation function and use this to call all the other validation functions.

However, for me it looks like a bug.

Best Regards

Philipp

Here's another approach that respects all of your existing validations including the built in attachment validations.

NWF.FormFiller.Events.RegisterAfterReady(function() {
    NWF$('.nf-attachmentsRow').on('change', '.nf-attachmentFileInput', function() {
        var textbox$ = NWF$(this)
        var attachrowid = this.id.substring(10, 47);
        var fileUploadid = attachrowid;
        var index = attachrowid.substring(36);
        //console.log('index:' + index);
        //console.log('attachrowid:' + attachrowid);
        //console.log('fileUploadid:' + fileUploadid);
        if (index == '') {
            attachrowid += '0';
        }
        var fileName = NWF.FormFiller.Attachments.TrimWhiteSpaces(textbox$.val().replace(/^.*p\/]/, ''));
        var match = (new RegExp('a~#%&{}+|]|\.\.|^\.|\.$')).test(fileName);
        if (match) {
            isValid = false;
            setTimeout(function() {
                NWF$("trfid^='attachRow']").each(function() {
                    var arrParts = NWF$(this).find(".ms-addnew")>0].href.split('"');
                    var fileName = arrPartsa5];
                    var attachRow = arrPartsn1];
                    var fileUpload = arrParts�3];
                    var match = (new RegExp('a~#%&{}+|]|\.\.|^\.|\.$')).test(fileName);
                    if (match) {
                        console.log(fileName);
                        //"attachRowafd9112b-43d7-4d7b-b740-f13d8f6f2ef71"
                        //javascript:NWF.FormFiller.Attachments.RemoveLocal("attachRow647f6e9b-1505-46d8-b8e0-30ba32ce7ab74","fileupload647f6e9b-1505-46d8-b8e0-30ba32ce7ab72","test1#.txt")
                        NWF.FormFiller.Attachments.RemoveLocal(attachRow, fileUpload, fileName);
                        alert('Invalid file: ' + fileName + '  You cannot attach files with the following characters ~ # % & * { }  : < > ? / + | file was removed.');
                    }
                });
            }, 500);
        }
    });
});
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Eric - this is even more interactive that the solution above - where it validates the illegal characters upon adding the attachment, and it validates the double period at the end of the file name in case of ACME Inc..txt.

Nice Job!

The single-quote/apostrophe has always given us issues here, and once the attachment has been added to the form, it can not be removed using the Delete button.

However, in our environment, we've also been encountering issues where somehow users are attaching files with non-plaintext special characters in the filename.

I'm not sure where they are downloading them from, or if they are being created by a program like Word, but the form actually seems to submit fine.

However, when the task respondent tries to Approve the request, nothing happens.  They can click the Approve button all they want and the form stays up on the screen and does not submit.

I've encountered this with a long dash character, as well as with 'curly' quotation marks and apostrophes.  The characters, if compared side by side, do not appear to be from the same character set?  I'm not sure if I've worded that properly so see below:

' - standard apostrophe, causes known apostrophe bug in Nintex
’ - form submits fine, but bugs out subsequent task form as indicated above

Does anyone have any ideas how to get around this issue?  We're revisiting our validation functions soon and I'd like to get this squared away in the next iteration if possible.  

You should be able to modify the regex in the code I submitted to handle any characters.

Thanks, I can give that a try.

I guess I was just curious if there is a better way to catch all of the characters that could potentially be problematic at once, instead of just adding them to the regex as I come across them.  

For example, I would think we could specify the VALID characters for an attachment name (A-z, 0-9, and the symbols known to work), rather than the invalid characters, and parse through the filename to ensure everything matches.

I'm just not quite sure exactly how many (and which) different special/extended characters I would need to account for, so it seems like specifying the valid character set would be more reliable. 

However due to the pattern-matching nature of regex, everyone seems to start with searching for the invalid characters as it is the most straightforward approach.

Maybe I will try to come up with something.  I was just hoping it was already out there.

Hi Eric - 

This is a fantastic solution with the exception of one scenario that I am running into:

If there are more than 1 attachment control(s) on the form, it only works with the attachment control you first attempt to attach a file with a bad filename.  If I attempt to attach the same bad filename to another attachment control, the alert displays, but the file is not removed.  Any idea of how to change it if multiple attachment controls are used?  I do not know where to find documentation on referencing multiple attachment controls where 1 of them is the default attachment control.  Thank you.  I will keep an eye on this post as I hope you can remedy with a new comment.  Much appreciated.  Wes Niemi.

Thanks Wes.  It was fun to figure out.  I'll try to look at it next week.

Thanks,  that would be very appreciated because it has been very challenging finding ways to validate attachments.  My users are frustrated!

Wes.

Hi Wes,

I've update the JavaScript with a fix so it works w/ multiple attachment controls.  I only tested with two controls so if you have more please test that and let me know.

Regards,
Eric

Thanks again Eric!  I am looking at the new code and tweaking/testing it today.   Much Appreciated.

Eric:

The new code works great!  Thanks again for your assistance.  This is a life savor.

Hi,

I need avoid, for example, files with name file: "example..xls", in nintex workflow this names files show me an error when 2configure a workflow for copy a files in specific site, how to avoid with your solution ".." the two dots???

Thanks.

FMS.