Trying to open an attachment with this url and it doesn't work. Any idea why?
https://Blah-apps.com/Development/StrongB.nsf/0/(Attach)/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf!%20&OpenElement
Thanks for any ideas
The attachment was originally created on the web and was an embedded object. I then wrote code to move it to a Rich Text Field and that didn't help. The error I get is
HTTP Web Server: Couldn't find design note
This is from a note that I pulled together for HCL some time ago listing the issues we had with Domino 11 having upgraded from 9. This might help although it is not clear what version you are on.
Broken Download links for LZ1 compressed attachments. - CS0313452
After upgrading to FP5 customers found that they could not download some attachments.
We were able to reproduce this issue 100% and provided HCL with a database.
https://eon.focul.net/eon/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB FoCul determined that this happens to attachments that are automatically compressed with LZ1 even when the database settings do not enable compression.
+SPR# GRHEBVYNW7 - Server - DAOS - Fixed an issue where after upgrading to 11.x,
running dbmt -c on DAOS enabled databases results in duplicate DAOS objects being stored.
This regression was introduced in 11.0.
The URL syntax affected is the old style https://<>//<>/<database.nsf>>/<>/$FILE/<>.jpg
whereas the newer “XPage”style syntax works fine
We modified our applications to use the XPages style syntax as a good work around.
This is the XPages url style
https://acme.focul.net/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB
Your use of /0/(Attach)/0 looks wrong. Try this format instead: http://host/Database/View/Document/$File/Filename?OpenElement (source: https://help.hcltechsw.com/dom_designer/9.0.1/appdev/H_ABOUT_URL_COMMANDS_FOR_OPENING_IMAGE_FILES_ATTACHMENTS_AND_OLE_OBJECTS.html)
So in your case:
https://blah-apps.com/Development/StrongB.nsf/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf?OpenElement
Related
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
This question is not a duplicate to another question that asks about the same message, but in another context. The context of this question is just about uploading screenshot images and getting the message.
Today, I had a new message when uploading images to App Store Connect:
Invalid GeoJSON: Your routing app coverage file is invalid.
This makes absolutely no sense since, at this time, I had not even chosen a build for the upload.
Retrying to upload the images, it worked. But unfortunately, the message appeared for each language and format.
Is this a bug by Apple or am I missing something? I would guess that uploading images has nothing to do with GeoJSON.
I used Safari. Others seem to have the problem with Chrome. So it occasionally seems to happen on all browsers.
I had this same problem today while uploading App Store Icon on Preparing for submission page. Solved it by removing "-" from my image name.
This is an unusual bug. Apple might be already working on it. It's not coming on any specific browser. It occurs mostly when we are trying to upload more than one images at once.
Apple always keeps their live site maintenance work active, so this is most likely a bug occurring in their live site maintenance. It will be fixed soon.
For now, if you are finding difficulties handling screenshot uploads, you can try to upload them one by one rather than uploading in a bulk.
Important Note:
I am stating this on basis of the last few uploads I have experienced. Also, the solution I have given is tried from my side and it worked for me well. So, you can just try it out and I'm sure that it's not a browser issue. It can occur on any browser.
It did not work for me even if I provided English file names. It kept giving the above error.
Only thing that worked for me was to remove all underscores. So instead of iphone_xs_max_1.png, it worked when I renamed it to iphone1.png and uploaded.
Make sure screenshot files name in English.
Make sure screenshot files all the directory path(and folder name) in English.
it worked for me.
I had the same bug today. Some of the images uploaded without problems, others didn't.
I was uploading in Chrome when I got the issue. Opening the site in Safari and uploading the images there, solved the problem.
What solved this for me was removing strings of numbers and periods from the filenames. It appears the system is running the filenames through some kind of geocoder, and if there are strings of characters that could be interpreted as locations, it will error out.
Make sure after editing the image you save the file with an extension like myimage.png or myimage.jpg
In my case, I forgot to save the file with extension after removing alpha and transparency properties and no need to change browser etc.
First of all: I know about the security concerns regarding ftp, so please no discussion about this here - ftp has to be used.
My app has to log into a server with ftp (with username/password), search for and download a file, delete it from the server, then upload an edited version.
I've been searching for tutorials on how to even get a connection to a server via ftp but all I found were Apple's documentation from 2012 here and their documentation about the different functions here (and a bunch of weird "Swift FTP" biking videos on youtube...). Every other example I found (usually <2015) uses some additional framework or library but there don't seem to be any proper tutorial for Swift 5 or even Swift 4.
Is it even still possible to use FTP with Swift 5 (is it still supported?) and if so, how? Or is there simply no point trying to get any of Apple's stuff to work and better to just use an extra framework like FileProvider?
At first I was using FileProvider, unfortunately the library is pretty buggy currently, with functions being called twice (which you can kind of prevent by using a "firstTimeCalled" bool check) and if the server's slow(-ish), you also might not get e.g. the full list of files in a directory because FileProvider stops receiving answers before the server's actually done.
I haven't found any other FTP libraries for Swift that work (and are still supported), so now I'm using BlueSocket (which is able to open sockets, send commands to the server and receive commands from it) and built my own small library that can send/receive,... files (using the FTP codes) around it.
I am writing a Program in Rub On Rails 4.x and I have to take PDF files with defined fields that can be filled out, fill in data from a form submission(This part is DONE!), and lastly allow the user to modify the saved PDF file on the server and overwrite said PDF after making their modifications.
Like I said I have already gotten the PDF files filled out with what has been submitted in the form through pdftk . What I now need to do is provide a server side editing capability to the said PDF files on server generated from the first step of the process.
I have seen similar posts but none wanting to do the same thing I do. If I am wrong links would be great. Thanks in advance for all your help!
After lots of digging and research here is what I have found to be the facts surrounding this issue and implementing a program to allow embedding the PDF file, editing it, and saving it back to the server. This process would be great however from what I can tell there is nothing out there that really does this for Ruby On Rails. To quote #Nick Veys
Seems like you need to find a Javascript PDF editor you can load your PDF into, allow the user to modify it, and ultimately submit it back to the server. Seems like they exist, here's one for ASP projects
You are correct but still wrong in the sense that yes there is one for ASP projects however that is Microsoft Based, yes I know that it can run on Linux environments through Mono. However to the point it would appear in this instance that a Ruby On Rails specific solution is indeed needed.
The solution that we have come up with is as follows
1. Use a PDF editing package in the linux repositories like PDFtk
2. You then render a page with the PDF embeded on one side and a form representing the live fields in the PDF to take input.
3. Once submitted you use PDFtk to write the values into a new template PDF file and overwrite what was previously stored.
This requires a few additional steps to process the data than I really care for myself. However it is the best solution that our team could come up with, without bleeding the project budget dry for just 1 piece of functionality.
I hope this helps anyone else looking to do the same thing in Ruby On Rails.
I have done something like this using my company's .NET product. It can also be done using its Java version too.
http://www.gnostice.com/nl_article.asp?id=255&t=Save_Form_Submit_Data_Back_To_Original_PDF_Document_In_NET
MOSS 2007 SP2 64 bit. Multi-server install.
How do I figure out the where to find the document library upload error I am getting?
I have document library with a custom workflow attached that will have a PDF document OCR'd during the upload. This library has some custom meta data fields from a content type that are exposed during the upload. As part of the workflow it OCR's the PDF doc and puts it back into the library and keeps it at version 1. During the upload I am getting an error for the PDF documents but it is uploading the document and the meta data fields are not getting updated with the user input. Below is the wonderful error message I get back. I have tried looking at the logs and I am not seeing anything pertaining to this error.
Go back to site
Error
The file 0746850076 Workers Compensation/a.pdf has been modified by DOMAIN\user on 14 Oct 2009 11:05:44 -0400.
Troubleshoot issues with Windows SharePoint Services.
Make sure the current user has proper rights and that you're not having an access collision with another user. Smells like a concurrency issue. Ensuring that you have proper locking in place should eliminate your woes
You probably is running into a concurrency issue; this message occurs when you do update some metadata and that document already has been modified by someone else (sometimes even you).
Before changing your metadata, try to reload your SPLIstItem/SPFile object to reflect your most actual metadata values.