This has been open for 8 years! Is there a reason why users wouldn't want LCN-linked TARL records to be updated from the LMS on a regular/targeted basis?

Keen to hear of any use-cases for 'not' wanting this functionality.

This functionality really needs to be developed, there is a real need to use a system tool to update records, especially the 856 field, that does inevitably change over time. What is required is a tool that can do a full or limited (if we could create a set of problem records using 856 value) and update bookmarks based on an LCN look up match.
Staffing resources at University libraries are limited and when changes to links occur, a huge amount of time is spent fixing things. At present we are having to maintain data in two places. The LMS and the Reading list system. The bulk update tool developed by Joe Munzer has limitations. Firstly, you need to install software on a University device (most staff don't have permission to do this). You still have to clean up the data manually into a txt file before using the tool. Last time we used it, it inserted extra weblinks rather than replace the old with a new. Thirdly, I'm not sure if it is currently working.

At Sheffield Hallam, we have tidied specific platform links up in the last year or two, only to find broken links being re-introduced via academics old book-marks. If we had a refresh tool, it would fix these with errors with minimal staff intervention.

Yes please.

I don't mind how it's done, but I agree that Aspire really needs a way to ensure we can update ebook URLs in batch. Having just been through an OpenAthens project this year where I updated every single URL in our catalogue, I am glad we did this before launching our new Aspire! Plus we will always encounter things like platform changes eg Safari moving to O'Reilly, MyiLibrary moving to Ebook Central...

We've had quite a few instances recently of ebook platform changes where we've had to identify those bookmarks that need changes then go in and edit them individually. It would be hugely helpful if Aspire could provide the ability to edit links in bulk.

Similarly we sometimes end up with links from a source bookmarked from different URLs/different routes in to a resource eg some have gone through dx.doi.org/.... and others through the URL, and we've gone through one by one making these links consistent across Aspire. Again it would save time if we could do this in bulk.

As referenced this is relevant to those of us with MyiLibrary and Askews & Holts ebook records to name a couple. We are in need of automated processes to address these types of bulk changes for urls, not by manual correction. It was also suggested on the LIS-Aspire list for exlcusions to be available in the process or partial refresh of certain fields which would address variations in bookmarking processes across different tenancies (e.g. teams who add ebook urls to print bookmarks etc). Thanks

we have had a few migrations recently involving Ebrary and MyiLibrary ebooks. For MyiLibrary alone we've had to amend 2980 records so any development in this area would be appreciated

This idea would be quite useful as we have had several vendors change their domains and not all of them offered redirection services. However the metadata refresh wouldn't cover database articles. The ability to bulk update fields (specifically links) would be immensely useful.

LSE would also like this functionality enabled.

We had this run as a custom script for us in the summer, and have requested that this be released to the the system. We would definitely back it, as per previous comments this will rely on our staff implementing manual processes to update the e-book link.

Yep would be great to update an edition in one place and have that replicated across all lists.

Just noticed this in the archive - similar idea.

http://ideas.talisaspire.com/forums/32805-talis-aspire-ideas-archive/suggestions/3182989-dynamic-856-data

This (refresh of all book data, specifically concentrating on 856) would also allow us to pick up newly-available ebooks, where a previously print-only version was bookmarked.

Was this ever considered? We need this.