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.
Related
I am trying to create a PDF with the pre-defined template with this particular library called PDFKIT. The server is written in Nodejs, may I know is there any good example I could refer to? What I want to achieve is to have a User Interface as an entry form, and then there is a pre-defined PDF file in-place on the server.When the user hits the submit button, the pdf rendering engine will pick-up the data and embedded into the pdf template file.
Take a look at the PSPDFKit for Web / PSPDFKit Server API docs for handling forms which let you retrieve and update all form fields. You can then use the document APIs for downloading a PDF with the form fields set to whatever values your user submitted.
So to recap, the steps are:
Upload the template PDF to the server storing the document id in your database or in the user's session.
Fill in the form fields using the data your user submitted.
Download the PDF with the updated form fields and e.g. email it or store it somewhere.
Alternatively you can create a signed URL so that you can directly redirect your user to the generated PDF.
Have you heard about PhantomJS? There is a package which name is phantom-html-to-pdf. You may give it a try.
We are converting an application that was built in R6 to xpages. In this application, the content was created through the Notes client and viewed on the web. There are a lot of doc links in the documents. Some of the documents have readers fields and that's where theproblem arises.
When looking at a page that contains links to "secured" documents, the URL is something like:
http://servername/dbpath/db.nsf/whaterverdoclinkhere
The links that this page contains all show a URL that looks like this:
http://servername/__REPLICAID/ViewUNID/DocUNID
The problem that we have is that this seems to be considered different DBs from a securitypoint of view and even though the user is logged in when accessing the first page, he gets the login page when he clicks on a link that uses the replica ID of the database instead of its path.
Is there a way to force Domino to use the database path all the time in URLs built with doc links, not the URL with the replica ID?
When I create file download control on a document I can display the attached files from a Rich Text Field.
In a separate process I am attaching more documents to the same document. I want to periodically refresh the download control container to see if there are new attachments. I do not want to do a full refresh of the page.
I have discovered that the partialRefresh of the file download control container either programmatically or manually does not result in the contents (downloadable files) being accurately updated.
XSP.partialRefreshGet('view:_id1:fileDownload1')
A full refresh of the screen shows the newly attached documents but I want to be able to partial refresh the panel container and see the new documents without full page refresh.
I have added a Random() computed text value into the panel and I can see that it is being refreshing correctly. I have even looked at the xhr response from the server and I can see that there is an update being made - but not with the new attachments in it - the "attached files" are not refreshing without full page refresh.
I can only assume this is a feature of the filedownload control in that it does not know that new files are attached at any other time other than page load.
Suggestions?
When partially refreshing a XPage, the datasources are not reloaded, only their last state (stored in memory or hdd ) is restored. If you change the scope of your datasource to request, the XPages engine is forced to recreate the datasource instead of using the cached one on each request (which includes partial refreshs).
This should allow you to refresh your fileDownload control without a full refresh.
Marky,
Yes, I have run into this before. You must do a full refresh with attachments.
http://xpagesblog.com/XPagesHome.nsf/Entry.xsp?documentId=FBAC0D921B677EA0852578CB006678D7
The link is fairly old, but I believe it still applies.
Matt White says in the article comments: "...Basically it is not currently possible to post a file attachment over AJAX, you either have to use Flash or a virtual iFrame solution if you don't want the entire page to refresh. As far as I know there is nothing that IBM can do about this at the moment.
Matt"
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.
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.