First of all, I would like to apologize for my terrible English.
We are enthusiastic about the new “Image Capture Widget” and have already added it in a few steps.
However, we have found that an added image only appears in the “Image Capture Widget” if it is also inserted via the widget. If the image is added over the table, the widget does not show the image.
So we re-uploaded all the pictures via the widget and everything seemed OK. The images were displayed correctly in all widgets.
After a few days, the images were not displayed in the “Image Capture Widget” again. In all other widgets everything is OK.
Attached is a screenshot. A picture was uploaded about a week ago and is not displayed. The other picture was uploaded yesterday and is displayed.
hello @RalfMueller, no problem - everything is very clear (and this is an international community)!!
great to hear you’re enthusiastic about the new Image Capture Widget, I’ve also been using it a lot and agree that it’s very useful.
regarding the issue you’re describing, I haven’t heard of this in the past but our Support team is looking further into it and will be providing an update. in the meantime, could you share a screenshot of the Image Capture Widget from the App Builder side??
furthermore, do you mind if I ask what the use case if for having to re-display the Image in the Image Capture Widget?? I’m asking in case there are other solutions that could work well.
For example we use the “Image Capture Widget” for creation and editing of work instructions. If it work, we only need one widget (to show and change the image) and not another to just display the Image. See the scrennshot of our layout.
I still experimented a little. I determined the respective image URL and called it up directly in the browser.
The picture I uploaded yesterday was displayed just fine. With the picture that I had already uploaded before, the following error message appears:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
AuthenticationFailed
Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:1e3ba07d-701e-0054-3375-79e7b8000000 Time:2021-07-15T12:34:25.7027157Z
Signature not valid in the specified time frame: Start [Mon, 12 Jul 2021 12:53:42 GMT] - Expiry [Tue, 13 Jul 2021 12:53:42 GMT] - Current [Thu, 15 Jul 2021 12:34:25 GMT]
It looks like the image is getting an expiration date.
Hey Ralf,
Just wanted to follow up and let you know that we are investigating this issue!
Could you check and let us know if you can see the picture that you uploaded yesterday, 24 hours or more after it was uploaded by pulling the image URL or does that also show the same error as the ones that were uploaded even earlier (Referencing your most recent message!)?
With the image that was displayed in the “Image Capture Widget” all day yesterday without any problems, the widget remains black today.
When I call up the link I get the same error message (with different dates) as with the other, older images.
So it looks like the images in the “Image Capture Widget” are only displayed for 24 hours. In this example for the period Start [Wed, 14 Jul 2021 20:22:54 GMT] - Expiry [Thu, 15 Jul 2021 20:22:54 GMT].
In the normal “Table Record Widget”, however, all images are displayed without any problems.
Thanks for your patience. These images are stored in an AWS S3 bucket. It seems that the links are expiring after 24 hours when attempting to populate the image capture widget. As you’ve noticed, these links are signed when used to populate the display of an image from a table record.
I believe the best workaround here would be what it looks like you might already have. Instead of relying on the image capture widget to both take an image, and display an existing image - break this up into 2 different widgets, or even 2 different displays.
You could leverage the “table record widget” to display a previously taken image from a table within your app, and then use the “Image Capture Widget” to overwrite/replace that image as necessary.
this is very bad news for us
As a result, we have to switch back to the form step or have to set up a kind of form step ourselves as a replacement. Several app steps would have to be rebuilt and the “Image Capture Widget” loses its charm.
But it is even worse that the link cannot be used for longer than 24 hours and we can no longer open the image in an external application (Chrome) afterwards. This would be needed to zoom into images.
This forces us to look for alternative solutions at individual stations.
Can you say something about whether there is still a better solution in sight? Or do you have any other ideas how we could help ourselves?
By appropriately overlapping the “table record widget” with the “image capture widget” - so that the capture switch is below it, we can make it look as if everything is happening in the “image capture widget” bypassed unnecessary steps.
This solves this problem.
In addition, we have created a universal step that displays the respective image in full screen.
This is a justifiable interim solution for us. Only zooming is not yet possible. Are there any efforts to enable zooming in an image field?
The endpoint allows you to get newly signed links to images stored in Tulip, which will last an additional three hours. You can pass in an array of image URLs and will receive an array output of these newly signed links.
Below is an example of me using the endpoint for a single image:
The endpoint is /signURLs, which you can read more about at <your-instance>.tulip.co/apidocs or <your-instance>.dmgmori-tulip.com/apidocs. I’m passing in a single image URL that I’ve captured from an app and has expired.
For the request body, the endpoint expects a root object that contains an array called urls. Here you can pass in multiple image links. The API docs give the following example, but I’ve used the JSON content type to structure this a bit more easily.
Testing this function returns me an object contained an array called signedURLs, corresponding to the links I’ve passed in. These links can then be used to access the image.
