Document archive, what do you think?

[heldercervantes]

Hey guys, gals and everyone else.

So, I'm sketching out a solution for a client, a platform where they deliver weekly reports to their clients, with a UI where clients log in to view their reports history.

• Each report is a PDF file
• Around 120 clients, meaning about the same number of PDFs submitted weekly
• Each client sees only their own reports, oc.

What I'm unsure about is how to store all this. I'm thinking of making an interface where a zip file is uploaded, each PDF inside follows a rule like starting with the client's id or reference so it can be properly assigned to the client.

What do you think is better? Store all this in a files field? Store each report as a page? Sounds weird to me to have hundreds of files in a field, but then again it also sounds much to have 120 new pages added every week. And of course this has to be organised, searchable by dates and whatnot.

[rick]

Probably the easiest method would be having their clients each with their own page, and each report is it's own child page. One template for the client pages and one template for the pdf pages. You can add the necessary fields to the pdf template to facilitate searching.

Personally, I shy away from building intelligence into a naming conventions. You might have your client person(s) doing the uploading select the client then select the pdf file, and enter any other necessary data associated with that report. If your client already has a data system from which the reports are generated at a specific interval, then you might tap into that workflow.

You might also consider using the created user ids for access control. Your client has clients (customers). Each customer would be a user in the system. That customer user id is used for their page and subsequent report page. Now you can use the logged in user to determine which pages are accessible.

Just some thoughts out loud.

[BillH]

Recently I was planning a project for an archive of PDFs, and I decided that a page per PDF was going to be significantly easier to work with and more flexible than grouping them in file fields.

The number of pages shouldn't be a problem. You'd get around 6k pages a year, so 60k a decade, 120k after two decades... Comfortably within PW's capabilities.

On the other hand, a client page with a file field holding 500 PDFs after a decade doesn't sound great!

If you haven't seen it, you might find something interesting in this recent blog post about new scalability options: https://processwire.com/blog/posts/pw-3.0.175/

[heldercervantes]

Thanks for the input guys. Sounds like a page per report is the most reasonable option.

It all depends on the budget of course. There are a couple of issues that may carry a lot of complexity.

First is how the clients (companies) are handled. I can either have a company be a user and then relate a report to that user for simplicity, or I can have the company as a page, a master user that's able to create sub-users for their staff. I'll need to build a UI to handle all that, which sounds lovely.

Then there's the UI for uploading. Doing it one by one is not reasonable. Even uploading 50 reports and then being presented with a list where you select a company for each report sounds like something that's bound to cause errors (not sure if basing it on file naming convention would be much better though). I'll see that when I get there. Can't be sure of the best solution without seeing how those are produced.

[BillH]

Regarding users, what you describe is a common situation with membership systems, where there are often things such as corporate members with associated members, so it might be worth searching the forums to see if there's anything about what others have done. And perhaps take a look at the Login Register Pro module.

For file uploads, in one project that requires regular uploads by a client, I made a simple admin page containing only a file field (giving me an instant UI) and a Save button. I hooked after the page has saved to process the files.

I don't know of a better idea for matching files to clients than using filenames  – though that doesn't mean there isn't one! I have one suggestion: it might help to reduce errors if the filename included a checksum for the string that identifies the client.

 

[OLSA]

If it’s not too complicated (and if there’s a budget) maybe you could consider dynamic reports (generate any type of report dinamicaly with option to download PDF, CSV...).
With this you can get advanced flexibility and various report options (include/exclude..., from to ...), also think about API possibilities and connection with external systems (e.g. client has some ERP), automation, etc ...
Regards.