Saving PDF files as part of QGIS Project

Is there a way in which the actual report can be uploaded to the QGIS project file

To your specific question I believe the answer is no.

However lets backtrack a bit. No actual data itself is 'uploaded' to a QGIS project file, data is only referenced by the QGIS Project file. The project file itself will contain items such as database connections, layer references, style settings for those layers, bookmarks, coordinate systems, geoprocessing tools, scripts etc etc. But no actual data or content items. These are all referenced via their location on a server or a database.

Which is a nice segway to perhaps a more appropriate solution. Sometimes non-spatial content is best stored in the GIS itself (photo's, work instructions/documents etc). The best place to store this, is in a database.

Depending upon how your company is setup, uploading the PDF's to a database, will mean that these PDF's will always be there, and as such - your 'path' to their location from within QGIS will remain static. Better still you should be able to join your remediation report to your asset information via a join in your database.

Hope the above helps.

That's indeed an interesting idea! At first glance I thought it's pretty easy to store additional files in a *.qgz file, but unfortunately the files will be removed during a project save. But we could use the Geopackage project storage mechanism and store the files as binary large objects (BLOBS) in a separate table - https://pynative.com/python-sqlite-blob-insert-and-retrieve-digital-data/.

The only thing missing yet, is a simple UI for the file handling (upload,download,delete).

This is a general challenge and not just about PDF, or even just Qgis. Other doc types necessary in a project, such as work notes about why such-n-such was done, and how to reproduce it. I'm not aware of generally accepted standard ways of storing that, but it sure would be great to have.

One approach is to have subfolders under the project file for the "side-car" data type, and take great care to not mess with the content structure and filenames once project has stabilized. Treating the whole folder structure as a single object. Example:

Inspections.qgz
   -- Docs
   -- attaches
          --pdfsite-078_20201124.pdf
           --photosite-078-001.jpg

As @nr_aus noted, you can represent this logical structure inside a DB and store the files in the DB also to mitigate the risk of renames, losing track of the side-car data, etc. However it can cause the size to balloon dramatically, and make it hard to access the contents with other programs. (How are you going to view the pdf?)

Both approaches are valid and which to choose depends on your circumstance and abilities. File-system is easy to start and play with until arriving at the happy structure, but means human operators are responsible for maintaining the referential integrity. All-in-DB will maintain integrity, offloading responsibility from operators, but demands concentrated up front thinking time, and in this case also custom script development.

...

To back up further though: why are the inspections being recorded as pdf and not as itemized table records? If you examine the contents they probably resemble a mini database unto themselves: Site name, location, date visited, inspector name, evaluation, etc. All this info is likely much more valuable as an intelligent object that can be queried and analyzed by characteristics rather than a frozen smooshed together blob. (PDF is where data go to to die.)