[Archivesspace_Users_Group] problem with collection-level Digital Object links

[Majewski, Steven Dennis (sdm7g)]

Originally the code had method=“POST” on the form action. 
None of my links worked with POST, and after asking about the logic of why view was coded this way and getting no response, I submitted request to change that to method=“GET”, being unaware that form processing strips parameters off of URLs for GETs. 

So that change fixed some links but broke or didn’t fix others. 

That current pull request just proposes to change method=“GET” back to original method=“POST” , which still will not work for some links. 

I was just looking at this history and the code again when your email arrived: still trying to figure out the original logic — is the a reason it’s coded as a form action instead of just an anchor link ? 

It could be fixed up in local plugin javascript, but it may still require some other context being included to figure out what needs to be done.  ( Not all of the digital_object or file_version attributes are exposed in the public view as they are in the staff view. May need to include more context in a hidden form object. ) 


— Steve Majewski



> On Dec 4, 2017, at 3:07 PM, Edgar Garcia <edgar-garcia at northwestern.edu> wrote:
> 
> Benn,
>  
> There is a pull request that I believe touches on this: https://github.com/archivesspace/archivesspace/pull/1047 <https://github.com/archivesspace/archivesspace/pull/1047>
>  
> I think this is why it happens.
>  
> I’ve been trying to look over this code because this pull request I think will break because our digital repository doesn’t accept POST requests for our object pages and it was requiring us to refresh the page for it to load.
>  
> I *think* when a thumbnail is missing, the page uses a form as a link instead of an anchor tag and that is where GET/POST. I haven’t been able to figure out why this was the decision.
>  
> Does anyone else know the answer to this? I’d rather some generic icon/img be used with an anchor tag to avoid this form/POST issue.
>  
> Edgar
> ----------
> Edgar Garcia
> Senior Software Developer
> Discovery Platform Services
> Metadata & Discovery Services
> Digital Strategies
> Northwestern University Libraries
> Northwestern University
> Evanston, IL 60208
>  
> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Benn Joseph <benn.joseph at northwestern.edu>
> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
> Date: Monday, December 4, 2017 at 1:53 PM
> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
> Subject: [Archivesspace_Users_Group] problem with collection-level Digital Object links
>  
> Hi all,
> Strange problem here, but perhaps there’s an easy solution. For some of our Resource records we’re trying to create a collection-level Digital Object that will contain a link to the area on our repository that contains digitized content from those collections. For a collection of glass slides, for instance, will create a collection-level Digital Object with this link as the File URI:
>  
> http://images.northwestern.edu/catalog?f[institutional_collection_title_facet][]=George%20Silas%20Duntley%20%281879-1957%29%20Photographs%2C%20circa%201899-1918 <http://images.northwestern.edu/catalog?f%5binstitutional_collection_title_facet%5d%5b%5d=George%20Silas%20Duntley%20%281879-1957%29%20Photographs%2C%20circa%201899-1918>
>  
> What we’ve discovered, though, is that even though the whole link is in there, ArchivesSpace somehow drops everything after the question mark and leaves you with:
>  
> http://images.northwestern.edu/catalog <http://images.northwestern.edu/catalog>?
>  
> …which is just a link to the main Images Repository intro page (not very helpful).
>  
> So, we decided to get around this by creating an ARK for each publicly available image collection in our Images Repository and using that as the File URI in ArchivesSpace. This works great! But only in Firefox and Internet Explorer. Chrome and Safari take the ARK (http://n2t.net/ark:/81985/n2t19k <https://urldefense.proofpoint.com/v2/url?u=http-3A__n2t.net_ark-3A_81985_n2t19k&d=DwMFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=qL9mtrzN5YM9JLty72jmSvS2xXL_z4-MUTBxVwpL3SM&m=nIbrgvRzWkv6cogejgr_s-4XfBKELuEIFInE9xtIm9E&s=ucJHzb1my_-9169XBGPTll1pyR6sXv7L3cguGNwvRkg&e=>, for example) and add a question mark (“?”) to the end of the url, which results in a page displaying an error message relating to our ARK setup. It appears that ArchivesSpace is adding this question mark, but whereas Firefox just ignores it (and makes it go away), Chrome gets tripped up.
>  
> We tried using a bit.ly link in desperation, and it works just fine in all browsers…but we’d prefer not to actually start using bit.ly links in finding aids on our production server. Does anyone know how we can go about creating collection-level Digital Object links to our digitized materials in a stable manner? Seems like ArchivesSpace can link to an image file no problem, but it gets confused with other types of urls.
>  
> Best,
> --Benn
>  
> Benn Joseph
> Head of Archival Processing
> Northwestern University Libraries
> Northwestern University
> www.library.northwestern.edu <x-msg://7/www.library.northwestern.edu>
> benn.joseph at northwestern.edu <mailto:benn.joseph at northwestern.edu%0d>
> 847.467.6581
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171204/4a19b923/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4943 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171204/4a19b923/attachment.bin>