I have a problem on our website in that attachments from one of our documents aren’t linking correctly.
I have found that the Identifier (2nd last tab when looking at the document properties) directly relates to the website link.
The link to the Word or PDF document on the website (Victorian legislation | legislation.vic.gov.au), shows a different ‘Identifier’ to the one shown in the actual Notes Document (Eg, website link shows 5da7442d8f61e92bca256de50013d008/8614533DD8A9CA9ECA2573B500158D45/$FILE/Status 2007.pdf, whereas Identifier shows 2C172782F4A6CE87CA256F42000E5BB2/CA2570CE0018AC6DCA2573B500158D45).
This is obviously the reason why the PDF and Word documents aren’t displaying correctly, but why would the link be changing for the attachment, and why just for this document? I’ve tried recreating a new document but it causes the same problem.
I forgot to mention, the database is replicated to a web server from our home server. The Identifier I’m looking at is on the document on our Home server.
You didn’t tell us yet, how these links are created.
If the link should refer to an attachment stored in the document itself, there certainly is something broken. The point is: The two documents your are comparing are different documents.
You don’t have to worry about the first part of the identifier as you showed it, this just refers to the view and is irrelevant for web use (could replace it with anything, e.g. 0), if you open documents by DocumentUniqueID. That’s what the second part of the identifier is. As you can see, the DocumentUniqueIDs are different, so these documents are not replica documents of each other.
They still might have the same content (at the moment) and it is possible that they show up in the same location in views on the different servers), but any changes made to the document on the home server will never replicate to the other document you are looking at on the web server.
As you can see, the docid is ok when linking to the form itself, but the attachment docid gets messed up somewhere.
Is anyone able to explain why this may be happening? I’ve tried creating a new form (with the same attachments) and I have the same problem. I’ve also tried deleting and re-adding (the same attachments) but also get the same problem. Could it be the attachments themselves causing a problem?
First off, we’re talking about documents here, not forms. That’s an important difference and since you’ve been using the right terms until now, lets not start to do otherwise.
Next, I wonder, if you problem still persists. In particular, the exact document you linked to in your original posting works perfectly fine and the attachments work as they should. The blank in the attachment name is not nice, but modern browsers and servers can deal with it and convert them to a URL save format automatically, so that’s not the problem.
Furthermore, you still didn’t tell, how the links to the attachments are created. If you are using some third party content management system, I can’t tell you how this works. One thing is for sure: The attachments are not shown as they would be, if they were simply added to a RichText field and Domino would generate the links to them. That means, that whoever wrote this application must have created some code to create the link in pass-through HTML. However, without knowing, what formula he/she might or might have not used, it’s impossible to tell, what the cause of the problem is.
One final note: Even if these documents are supposed to be public, they do reveal more information than necessary to the anonymous surfer, at least for my taste. While the full canonical Notes user name of the author is not considered to be a secret by some, many organizations are pretty picky about not displaying them to anybody. Not only does the surfer get information about the organizational structure of your institution, the Notes name may also be used for attempting a web login. Domino has no native means of limiting the number of login attempts over the web, so a brute force attack is actually a lot easier, if you already know the use name as one half of the puzzle. IMHO, you should consider a redesign here.