There have been a handful of Attachment Viewer questions already (here, here, and here, but none seem to capture quite the behavior I'm seeing.
The "No Attachments Found" error is only occurring for Community accounts. The applications works fine and displays attachments for anyone with a regular organizational account with access to the group where the application lives. However, if one uses a community account to access the application they'll have access just fine, but they'll see a "No Attachments Founds" error.
If logged into a Community account, however, one can navigate to the group, the layer which is used in the app, and then view the attachments in the Data tab, so it doesn't seem to be an issue with access or credentials, per se.
I would like to know if there is a workaround or if the product is non-functional at the moment, as we'd like to keep using our community accounts for this purpose.
Paging @RyanLibed, @KellyHutchins or @ManishPatel, who seem to be familiar with these issues from previous threads.
I don't think this issue has been brought up yet. Do you have a link to a sample app that reproduces this behavior? Or if you can provide the webmap and/or feature services that you see this behavior happening?
Also, if you open the developer tools in your browser, do you see any errors in the console?
I will send item id as a message.
And yes there was an error in DevTools: failed to load Web Map.
This also seems to occur for any out-of-org account, not just Community accounts.
Additional follow-up - we made the application public in the attempt to circumvent the credentials. No dice.
Even once public in an incognito tab the instant app still asks for credentials, and then responds as described above. Non-org accounts cannot view the associated attachments, while org accounts can.
Based on what you described, I'm thinking that the web map and/or feature service requires credentials to view the attachments. This is probably why the app is prompting for credentials.
That's correct. I had other components that were not public, and that resolved that issue.
However, we would prefer to not have to make this public. Any thoughts on the original problem?
The Attachment Viewer app queries for the attachments and can succesfully retrieve and display them if the feature service that has the attachments is either public, or if the account that is logged in has the proper permissions to get and display the attachments when viewing the app.
I believe that the Attachment Viewer app is failing to load the attachments in this case because it sounds like the account that is logged in does not have the proper permissions to request and view the attachments.
Unfortunately, I don't think there's a way to bypass the request to get and view attachments if an account doesn't have the permissions to do so.
Basically, the accounts that are logged in need to have the proper permissions to get and view the attachments, or the service that has the attachments needs to be public.
Ryan,
Unfortunately this is not correct. If you re-read the original post you will see that I mention that it is very much possible to navigate to the group in one of those accounts and view the attachments in the data tab for the layer. So the permissions issue is not global in AGOL, but being expressed entirely through the application.
Ok, do you think you can open up a support case through Esri Support to get a reproducible case created? I think it'll be much easier to troubleshoot if we have sample that demonstrates the issue.
Thanks,
Ryan