Bug 33308 - Add ability to to use SFTP with runreport.pl
Summary: Add ability to to use SFTP with runreport.pl
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Command-line Utilities (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Jake Deery
QA Contact: Testopia
URL:
Keywords:
Depends on: 35761
Blocks:
  Show dependency treegraph
 
Reported: 2023-03-22 16:01 UTC by Liz Rea
Modified: 2024-10-08 09:55 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2023-03-22 16:01:32 UTC
It would be very awesome to be able to specify a sftp/ftps target with the cronjob runreport.pl job, to complement the ability currently available to email the report somewhere. 

Some kind of secure solve for "allowing the koha user to automatically accept the hostkey" on the first connection would also be nice, but not a requirement.
Comment 1 Katrin Fischer 2023-03-23 22:34:35 UTC
I like the idea, but maybe a workaround: would be using the 'access files' tools and a directory on the Koha server work? It would limit access to Koha staff users with the right permission set.
Comment 2 Liz Rea 2023-03-27 22:39:26 UTC
We do this in some places, but by and large our partners do not like this approach for a few reasons:

They often have to send things other places without human intervention, on a schedule.
The UX of the access_files is very poor (no directory structures allowed, cannot remove files themselves, among other things.)
They have workflows that involve 3rd party vendors who require sftp/ftp deliveries of files.

Right now, we generate the files and use other tools to deliver the files, which works but is very labor intensive when you have many of them to administer.
Comment 3 Katrin Fischer 2023-04-04 09:31:24 UTC
Thx for the reply, Liz, that makes sense.