When you click on the link for an attachment in the File Download control in XPiNC, you are promoted to save the attachment. Is it possible to configure the File Download control to open the attachment directly instead of prompting the user to save it? We're using 8.5.2 FP3.
Handling of an "attachment" is primarily done by the Browser (XPiNC being a firefox browser inside Notes). If for example, a PDF plugin is installed in the browser and the servers sends the corresponding "application/pdf" mime-type with the file, the browser uses that plugin to display the file. The correlation between mime-type and plugin or external application in the browser is something the server/webapplication can not influence.
What you can do on the server side is sending the mime-type "application/octet-stream" instead of the one corresonding to the file type, causing the browser to display the "Select application or download" dialog. So in Xpages, you would have to redirect the download through a XPage, where you set the corresponding HTTP Headers as shown in Set cache headers on an XPage and How to force PDF files to open in browser?
I haven't used the file download control or XPINC, but it is definitely possible to make your xpage or view control open an attachment directly. This method bypasses the download control.
Please see this post from Stephan Wissel: http://www.wissel.net/blog/d6plinks/SHWL-86QKNM, which gives you some SSJS that you can use to build the URL. You can use it in the onClick method of a button. You are essentially duplicating the functionality of the download control in a way that does what you want it to do.
If you want to do the same thing from a view control, then see this post: http://notesspeak.blogspot.com/2013/02/how-to-launch-attachment-from-view.html
Note that different browsers behave slightly differently but it works in all the majors.
Michael,
Here is code I used:
var unid = rowValue.getUniversalID()
var url = getAttachmentURL(unid, "storetransfer.pdf", "Testing//test.nsf")
url = "/" + url + ";"
view.postScript("window.open('" + url + "', '_blank', 'height=120,width=650,top=10,left=10,resizable=yes');");
I did modify Stephan's code a bit since my data is in a different NSF than my code. You probably know this but the view.postScript allows you to call clientside javascript from SSJS. It always is the last thing to run, hence the name. This is the same code from the Notesin9 video mentioned in the comments. I just tested this and it works like I think you want, but in firefox it does try to block the popup, and then has to push "open". Hope this helps.
Related
We have a web admin panel in which the agents can see conversations with customers.
Those conversations are the result of importing normal emails thru an IMAP connection. We grab the "untouched" mailbox files and we store them in a database. Then we post-process the files to index by "from", "to", "date" and so on and so forth.
Up to here, okey. We can seek all the emails involved with a client and render them at will.
Then when the agent looks for a customer in the web admin panel and opens it, the full email conversation appears. And we display the HTML version of the email within an iframe (or the text version if the html version is not there). 90% of the customers send HTML.
What happens? Upon the agent opening the email in our web, the iframe loads the "full html" and renders it. This makes "remote loading" (images, sounds, styles if so, and whatever) to be downloaded. This allows customers to "track" if we opened the email by appending tracking id's to the assets (typical http://track.example.com/image.jpg?id=123456789)
I've tried the "sandbox" attribute of the iframe html tag with no luck (it still downloads the images).
Question
How can I programmatically tell the iframe to not load ANY remote content, and just render the initial HTML without any remote call?
Mozilla's iframe documentation listing all available attributes for the is here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
If you look at "sandbox" there is no restriction specific to image or other includes, just restrictions on things like running JavaScript. There are no other attributes that would restrict images and includes.
To solve the problem of images and includes in your HTML you will need to filter the HTML either at the server before sending it or in the client after it arrives.
Server:
Before storing it into the database.
In the code that retrieves the HTML and returns it to the iframe.
Client:
Use AJAX to fill the iframe with the HTML, with code that filters a
response. With this approach you could also use a div instead of an
iframe if that works better for your layout.
If all of your users will use Chrome or Firefox, you could look at writing a browser extension
I am generating a pdf on the server that I would like browsers to attempt to open in-tab (those browsers that can do so) instead of downloading.
I was pretty sure that this is a matter of having or not having some header but I can't find it. Is it possible to control whether the user's browser displays or downloads your asset?
Acrobat Reader X have a checkbox under Edit > Preferences > Internet to enable or disable in-browser view, regardless of the status of the browser plugin.
If that check is ok, or you have a more recent version, you can check if the plugin is active in you browser, every browser have different plugin.
A fast check is to open a local pdf file in your browser, something like file://localhost/C:/dir1/.../file.pdf, if Adobe Reader have the right check and the plugin is working the file will be showed in the browser otherwise, even if it is a local file, the browser will ask a folder to download it.
So in my specific case I was sending the wrong content-type (thanks #admdrew for pointing me in the right direction) due to coding a constant wrong.
However, the answer is that there is indeed a header - at least when working with pdfs that will suggest to chrome at least whether it should open or download a file. This header is Content-Disposition. In my case setting it:
Response.Headers["Content-Disposition"] = #"attachment; filename="foo.pdf"
triggered a download, while omitting it triggered in-page opening.
In addition, the above link states
If this header is used in a response with the application/octet-
stream content-type, the implied suggestion is that the user agent
should not display the response, but directly enter a `save response
as...' dialog.
Though I found using Content-Type: application/pdf worked ok in both cases.
I'm making a chrome extension which displays desktop notifications on particular events. I am receiving and displaying the desktop notifications just fine, but the problem comes when I try to put attribute tags into notification. Instead of being the text as tags to be appended to the notififcation's DOM, Chrome seems to just interpret them as plaintext, resulting in the content of the notification being just html source code.
Is there any way that I can have the body of my messages be appended as HTML instead of just text or am I just out of luck?
It used to be possible, but now it's not. But you could use a "Rich Notification" and put the link on a button. See https://stackoverflow.com/a/13328513/488287 for details.
Xpages for Client Side: Download Control does not have the option of opening a saved attachment , it always gives the option of saving the attachment and then reopening.Any workaround for this?
The scheme by Mark doesn't work in XPiNC ( which I think is what Client Side meant in the question ), however, Mark has since come up with another scheme which he mentioned to me and it works.
If you use a url link to open a classic notes document ( i.e. not xpages ) with the launch property open first attachment set then the attachment will be launched immediately - it works really well.
I will write something up and put it on my blog then add a link here. If you had more than one attachment you might need to construct a temporary document with just the attachment you wanted.
I haven't found a way to let users directly open files using the standard download control, but as a workaround you could create links to the files using the (old school) syntax:
/<yourdb.nsf>/0/<document-unid>/$file/<filename>
This won't add the content-disposition header that causes the file download dialog.
I have a form that Legal will use to track trademark claims. They want to be able to attach logos to this for for easy reference. It's easy enough to create a file attachment, but is there any way to show a preview of the attached image?
The solution has to be usable in a browser enabled form.
Attachments are stored in base64 format. You'd need to somehow post that data to the server, encode it correctly, and send it back to the client as a jpg. It's a bit of work, but i'm sure it's doable.
You could add a link column (named preview) to your form library that leads to an .aspx page in the layouts directory, where you read the form xml and generate a preview of the document including the attachment previews.
This way you are able to handle the different attachment formats (e.g using C# code) and bypass the limited functions of the form service.
You could add a "edit this form" button to that page that redirects to the original formservice url.
Most browsers support base64 decoding, so you could very easily just point to the base64 data directly.
You might want to checkout base64 in internet explorer: http://dean.edwards.name/weblog/2005/06/base64-sexy/