10min
| Development progress update | @Owen Stephens | Mainly working on issues arising from Bugfest testing Fixed as many as possible, those fixes will be part of Ramsons All Agreements and Licenses test cases are done Major issue in Licenses module: uploading documents does not work; issue is existing since Poppy; will be fixed for Poppy and Quesnelia as CSPs Currently developing external Push KB service; will be tested in GBV first, but is available for everyone
|
15min | eUsage App - future development plans | @Stefan Dombek | Stefan Dombek is Product Owner for eUsage app for 5 months now App is now in phase where there is more management needed than new development done Stefan can always be contacted directly via Slack Some additional requirements are already identified for further discussion Stefan presents plans for 2025 COUNTER 5.1 Support Improving the integration of aggregators Improvement of error handling Obtain feedback from the community and check and, if necessary, implement further requirements
eUsage is already in use by some institutions internationallly; others are testing it Question: Are you also going to work on the eUsage plugin that connects Agreements and eUsage? > this will be discussed next year
|
35min | URLs in Agreements and LIcenses documents | @Owen Stephens | With the Q release, the validation of URL fields in Agreements and Licenses has changed. The URLs to wikis and Jiras, which only resolve internally, are no longer validated. Same happens to file paths. As a result, libraries can no longer save the records where they have entered respective information in the URL field. Wish: add another field for URLs that don’t fit the validation criteria. Alternative: allow flexibility in validation 2048 characters is the field limit (which is the longest URL browsers accept) Felix in chat: If you have a really long URL and the webserver would accept it, but FOLIO's URL field would reject it because of the length, one could always use a link shortener and use this short link in FOLIO. That is no ideal situation, though, because such shorteners often track how often a link has been clicked and other metrics. At ZBW we host our own service. Validation is checking on the form of the URL Possible: we could allow file URIs and “file” as a protocol Margaret Youngberg in chat: Network file path would be very, very helpful -- I'm currently using physical location for these URIs Felix in chat: The issue with the file path is that it is not possible to create it without third party tools in Windows. You can only copy a path that looks like: "M:\hmm\foo\2024-12-09_ol_ebc_lzm.txt" Possible: we could add a separate field Sara in chat: Maybe we could rename the Physical Location to just Location for things like the c-drive example Felix in chat: Also, it has to be as simple as possible for the end users. That is a lesson we've learned in the last few years with Folio ERM. Stefan in chat: File paths can be stored as a link in the UI. This would require the security settings to be adjusted. Links to file paths are blocked by the browser by default. Question: are libraries using the field “Physical location” currently? Question: would libraries pobject to renaming the field “Physical location” to e.g. “Other location”? Agreement: “Physical location” will be renamed Maybe addtional work as discussed above will be done
|