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.
Related
The context here is that, in a CMS type of app, the users that create content like to reproduce Notes' way of having attachments anywhere in the text, not just a list of attachments at the bottom of the page. When creating a page, they want to be able to create links to the attachments right away, using a link and an img tag, not saving the document first and then edit it again.
I have found the YouAtNotes HTML5 Multi File Upload control, which enables the users to upload the attachments before the document is actually saved. The URL for attachment uploaded befor ethe doc is saved is then:
http://myserver/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I use this URL in the CKEditor to create an image and it looks OK: the image shows up in the editor and has this URL:
/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/insanity.jpg
I then save the document, and it still looks good. The image is showing up and the URL is still:
http://myserver/mydb.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I close my browser, and open up the page again, and now I see that my image is not showing up, but the URL is still:
/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
But if I look at the URL that is used by the download control, this is what is has:
http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg
Why did it change?
Is there documentation on how that whole attachmentprocess works, so I can understand it and give proper indications to the users so they can create valid links.
We also have a particularity in our publishing code: we need to keep the UNID of the published document so links that were made using UNIDs are still working. It is an app with a lot of content and many external apps link to it. So when we publish, we actually copy all the content of the draft into the already published document, so the UNID is different from the draft document, and we have issues with attachment links because of that. But that is something else...
The URL "/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg" relates to a temporary location before the docment has been saved. This is standard functionality because
For SSJS / Java to save an file into an NSF, it's got to have been uploaded to the server prior to the commit.
The user has not chosen to save the file yet, so it shouldn't be added to the NSF.
The document hasn't been saved yet, so even if it should be saved to the NSF, no document yet exists to save it to.
The components of the URL are:
"/Belair/xBiblio.nsf", the URL of the database it will finally need to be committed to.
"xsp/.ibmmodres/persistence", a URL that corresponds to a physical folder location where temporary files for this NSF are stored, based on xsp.properties of the NSF; if nothing is defined in xsp.properties of the NSF, xsp.properties of the server is used; if nothing is defined there, a default location is used.
"DominoDoc-NEW_569", a temporary reference to the new, unsaved dominoDocument datasource. If you close the browser and re-open it, you'll be getting a different temporary dominoDocument datasource reference, so I wouldn't expect the image to show up. Otherwise, different users could get one another's attachments.
"-Body", the field the file needs saving into.
"/indifference.jpg" the file name.
Once the document is saved, the file is stored into the Body field of the relevant document, and the file system cleaned up. The URL has to change, because otherwise the attachment would not be available on other replicas, because only the database gets replicated, and it could not be managed by DAOS.
The new URL "http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg" corresponds to:
"myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment", shorthand URL to open the relevant attachment.
"/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE", the location of the document the attachment is stored in.
"/Body", the field name.
"/indifference.jpg", the attachment name (the field could have multiple attachments, of course).
The information above is based on what has been documented in XPages Portable Command Guide (for xsp.properties settings for changing the default temporary locations) and Mastering XPages 2nd Edition.
I'm not sure what the YouAtNotes uploader does, so I can't say whether it should be changing the URL or not on save. But in more recent versions of Domino, attachments can be uploaded without a full refresh, which may be of use as an alternative.
When you're copying documents, if you're storing HTML that references images by their URLs, including UNIDs, you'll need to modify those references.
If you want to keep UNIDs, remember that they are read-write - you can set them as well as get them. However, bear in mind that you'll have problems if you change the URL to the same URL of an existing document. Bear in mind this is also XPages, so the data accessed via the XPages applications don't have to be in the same database.
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.
I'm currently implementing the OpenNTF Multiple File Uploader by Mark Leusink.
This very nice custom control uses an xAgent to embed the selected file attachment into the target Notes document. Everything was working fine until I added Authors and Readers fields to the Notes documents. Now I'm getting a security error (402) when uploading the file.
My thought is the Upload xAgent can't edit the target document to attach the file. If I remove the security fields, everything works again.
My question is, do xAgents run with the same security as the current user? If not, can I set a "run as" user for the xAgent like I can for a Lotus Script agent?
I'd suggest that you look at the xAgent's code and rewrite it to use sessionAsSigner to access the database/document to upload the file. This will cause it to run as the signer of the application and bypass the security issues that your running into.
Both Tom's and Declan's answers are correct, but this doesn't count for the file uploader.
It uses a Flash component to do the actual uploading (called SWFUpload). Since browser cookies aren't shared with Flash, it can't send along the user's session cookie with the file and therefore to the Domino server the user performing the upload is nog logged in (aka Anonymous). That's why the uploader requires anonymous users to be allowed to read/write public documents in the ACL and the XPage/ XAgent handling the uploaded files (aUpload.xsp) is set to allow "public access users". It uses the sessionAsSigner object to access the database's content
Normally, the above settings would allow everyone to anonymously upload files. That's why I implemented a custom authentication solution based on an idea by Mark Barton: before every file is uploaded, a request is made to an XPage to retrieve a unique key. That XPage (aGetAuth.xsp) does run under the user's credentials and stores the key in a document in the database. This key is send along with the uploaded file and compared with the stored key. The upload is only allowed if the keys match.
First thing I'd check in your case if the code in the aUpload.xsp XAgent can read and write the target document using the sessionAsSigner call.
Mark, Declan, and Tim, thanks for jumping in.
I modified the xAgent **aGetAuth.xsp** to use sessionAsSigner to get the current database. At first I got the error "sessionAsSigner not found".
Google showed a quick answer was to re-sign the template before testing. After re-signing the template, twice, and preforming a "clean" everything works brilliantly.
Earlier versions of the Notes client would automatically turn a sent URL into a clickable link for the recipient (regardless of mail client) but with 6.5 (and presumably later) this no longer happens; that is, the URL is sent as plain text. The Notes UI allows it to be done via the Create->Hotspot->Link Hotspot menu but this gets tedious.
I'm looking for a way to create a Link Hotspot in LotusScript. My research to date leads me to believe that this isn't possible but there may be a hack of some kind.
The automatic conversion of urls into clickable links is a user preference.
In 6.5 it is set via File/Preferences/User Preferences/Basics. In 8 it is set via File/Prefences/Basic Notes Client Config.
I don't think you can create a url link hotspot explicitly using lotusscript. You can create a doc link, but there is no obvious way to turn it into a url link.
You could try an approach where the form is set to render passthrough html on the client and then construct the relevant html for a link.
Update in response to comment.
The scenario is that we want to to control what a user receiving mail sees. We have a few cases we should think about.
The recipient is using Notes and received the mail directly via notes to notes routing.
The recipient is out on the internet using any client and allows email in a rich format.
The recipient is out on the internet using any client and only allows email in plain text.
In the first case the user will see links if they turn on the option for that. You could also create pass-through html in the rich text and that will render on the Notes client assuming the form option is set in the design. If it's straight email and you don't really need any other rich Notes features you could also construct a MIME message.
In the next two cases you just want to send properly formatted MIME messages. In the first of those cases the user will accept rich formatting and therefore you can construct the message as simple html and include links that way. In the second case the user will not, and you have to make do with plain text. Luckily most mail clients will automatically turn urls received in plain text messages into links for you. This may be an option as in the Notes client.
It is best practice when sending rich mail content to also include a MIME section for plain text. That way you don't need to care what version the user prefers.
You need to cheat and create a MIME entry to get your links. Going that route you also can take the opportunity to make it look really nice. The sample code is on this site
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/