Bug 20208

Summary: Custom file upload paths
Product: Koha Reporter: Kyle M Hall <kyle>
Component: Architecture, internals, and plumbingAssignee: Devinim <kohadevinim>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: jonathan.druart, katrin.fischer, kohadevinim, m.de.rooy, mshellenbarger, nick, wizzyrea
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19318
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22508
Change sponsored?: Sponsored Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Bug 20208: Unit tests for checksum and dir
Bug 20208: Development - Peddie School - Custom file upload paths
Bug 20208: Custom file upload paths

Description Kyle M Hall 2018-02-15 13:44:19 UTC
Work to be done:
1) Add option on file upload page to not add file checksum to the uploaded filename, modify Koha::Upload
2) Modify Koha::Upload to support this option
3) Create new Authorised Value UPLOAD_PATH to define a set of upload paths
4) Add new 'upload path' option to file upload form as a pulldown of defined upload paths
5) Add new column 'file_path' to uploaded_files table
6) Modify Koha::Upload to support the automatic creation and use of custom file upload paths
7) Write unit tests for new functionality
Comment 1 Katrin Fischer 2018-02-15 15:52:41 UTC
Hi Kyle, can you explain a bit about the use case?
Comment 2 Kyle M Hall 2019-01-15 13:10:26 UTC
This is a quote directly from the sponsor (Peddie School):

The goal of this development would be to create a file folder structure that could be uploaded to from Tools>Upload and then have a way to easily view the folder structure so that you can see what files have been uploaded and which folder they belong to.
Comment 3 Devinim 2019-01-30 13:47:02 UTC
Created attachment 84524 [details] [review]
Bug 20208: Unit tests for checksum and dir

Test plan:
    kshell
    prove t/db_dependent/Upload.t

must return green
Comment 4 Devinim 2019-01-30 14:34:45 UTC
Created attachment 84525 [details] [review]
Bug 20208: Development - Peddie School - Custom file upload paths

Test plan:
1) Upload two files with and without checksum
2) UPLOAD add new options to authorized values
3) Upload two files with and without checksum by selecting from the pulldown category options 
4) UPLOAD_PATH add new options to authorized values
5) Try uploads by selecting from the pulldown upload path options and other options
6) Check the files in the /var/lib/koha/kohadev/uploads
Comment 5 Katrin Fischer 2019-01-30 17:31:32 UTC
Hi Kyle/Devinim, can you please make the bug title more general? (Think release notes :) )
Comment 6 Kyle M Hall 2019-03-01 15:04:50 UTC
*** Bug 19318 has been marked as a duplicate of this bug. ***
Comment 7 Liz Rea 2019-03-08 15:06:32 UTC
I was unable to get this to work, I think I need some additional information regarding setup parameters.

Namely:

Where do the paths to be input into the authorised velue start from, / or /var/lib/koha/<instance>/uploads or somewhere else? This needs documentation at least.

I was expecting to be able to get to the hashless files by going to them at http://host/uploads/custom/path/file.jpg type of URL, but this didn't work that I could see. It could be related to the above question. The files did seem to get uploaded to the directory, but I was unable to retrieve them with a reasonable URL. I believe that's what the requester is probably looking for.

The interface for finding uploaded files needs a LOT of work, though technically that is independent of this development (but actually, it's kinda not!). Users will have to be very disciplined with file names and potentially have external documentation to have a hope of finding files using a search only. I think this interface needs rework urgently to have either a gallery style or directory hierarchy style display. Even a link to "list all files" with their web URL and/or file system path (as security allows) would be a huge improvement.

Cheers,
Liz
Comment 8 Devinim 2019-05-22 09:44:40 UTC
Created attachment 89954 [details] [review]
Bug 20208: Custom file upload paths

Test plan:
1) Apply the patch, run updatedatabase and update_dbix_class_files
2) Run prove t/db_dependent/Upload.t
3) Go to tools/update any file menu.
4) Upload two files with and without checksum using tools/upload
5) Add a new option to UPLOAD authorized value area.
6) Upload two files with and without checksum by selecting the option you created in step 5.
7) Add a new option to UPLOAD_PATH authorized value area.
8) Try to upload new files by selecting pulldown menus or other options in the upload page.
9) Test new feature nameley file tree whether files were uploaded.
10) Check the files in the /var/lib/koha/kohadev/uploads
11) By adding or changing a biblio, use 856u field and test also selecting file from new file tree option. (upload should be choosen for 856u field. )
Comment 9 Liz Rea 2019-05-24 15:49:27 UTC
Failed QA for now, as some discussion of the spec needs to take place. 

The problem we are trying to solve for the librarians here is the one of having a user moderated web space that is manageable from within Koha, with friendly URL's such as http://model.akohasite.org/uploads/a/b/c/file.pdf. This dev gets about halfway to this goal, as it includes a nice interface for the staff client and staff can upload files into a specific upload path. The problem comes when we go to try and access those files from the OPAC - it can't currently be done, and even if it worked we still don't display the URL the library would use to access the file anywhere. These features are a core part of this development. There are a few ways we might go about getting this to work, happy to chat about those at anytime (Tomas and Kyle both have ideas about how this could go - please feel free to ask them).

Please do ask if you have any questions at all.

Cheers,
Liz
Comment 10 Nick Clemens 2022-02-22 14:35:53 UTC

*** This bug has been marked as a duplicate of bug 19318 ***