I have two problems. First the email notifications on our InfoPath client events don't work. No errors are generated, they just seem to do nothing. This isn't that big of a deal as we couldn't customize them to do what we wanted anyway, and we couldn't do the same with the Email Notification event either. For example, we couldn't use Environment Library settings in the message -- we could add them but they would always get removed (which seems like something you would obviously want to do, but perhaps that's just my warped thinking). Thus we custom coded email notifications using a Default Server event. No big deal -- the code is fairly trivial and is as flexible as we want it to be.
Anyway, the second problem is as follows. In the message body of the email notifications is a link to the file generated in the SharePoint form library. The URL is correct, however when you click on the link an InfoPath Form Services error is generated. After quite a lot of testing/digging we have tracked the problem down. We found the following error in the SharePoint logs:
09/24/2008 17:14:34.32 w3wp.exe (0x17A0) 0x07E8 Windows SharePoint Services General 8kh7 High The specified file or folder name is too long. The URL path for all files and folders must be 260 characters or less (and no more than 128 characters for any single file or folder name in the URL). Please type a shorter file or folder name.
What is causing this is the HREF in the MSO-INFOPATHSOLUTION directive of the form. This is what the directive looks like:
<?mso-infoPathSolution solutionVersion="1.0.0.2769" productVersion="11.0.6565" PIVersion="1.0.0.0" href="http://tstmoss:37974/sites/Applications/PWR/Requests/Forms/template_-myXSD-2008-09-24T14-01-30.xsn?SaveLocation=http://tstmoss:37974/sites/Applications/PWR/Requests/&Source=http://tstmoss:37974/sites/Applications/PWR/Requests/Forms/AllItems.aspx&OpenIn=PreferClient&NoRedirect=true&XsnLocation=http://tstmoss:37974/sites/Applications/PWR/Requests/Forms/template_-myXSD-2008-09-24T14-01-30.xsn" name="urn:schemas-microsoft-com:office:infopath:Requests:-myXSD-2008-09-24T14-01-30" ?>
We played around and stripped off the XmlLocation of the generated files, put them back in the library and everything worked, including the links in our email notifications. For what it's worth, we found that we could strip all but the URL to the form out of the HREF arttribute and it still worked, so we are not entirely sure what purpose the attributes serve (perhaps they are useful if you use Form Services, which we don't). We know what some are used for, but again, removing them didn't seem to break anything.
It only affects external links as there is an onClick event on links in the Form Library that calls into SharePoint's Core.js library and performs some magic that is not affected by this.
Anyone know of a workaround? Is this a known bug? I haven't found anything in the forums or KB, but I would be surprised if someone else hasn't encountered it. I am considering writing some code that will rewrite the HREF attribute. Seems like a gross hack, but it should work.
Cheers.
P.S. Sorry for the link...The Rich Text Editor doesn't seem to work properly.
(On a side note, I think someone should moderate the Tags...Dear Lord!)