Add support for photo as proof / file upload

[almet]

From Michiel Leenaars, by email.

Anybody that needs to account for spending, would need at least a photo of the bill as proof. Not everyone lives in a high trust setting, and obviously different use cases involve different features not of use to others. Keeping it simple works for simple use cases only, offering more functionality but keeping the UX easy is where the challenge lies.

We currently have an option to attach links in the form of URLs, but it doesn't support file uploads on its own.

---

We would do this this way (summary of the discussions):

• Either store this as blobs in the database (see discussion above) or an external object storage integration (S3 protocol)
• the server administrator should be able to disable this feature through configuration (and I would argue it should be disabled by default)
• the server administrator should be able to set a limit on the size of the uploaded files through configuration, to try to control storage space

We don't want to shrink the images before upload.

[shrn01]

We can't store the image as it is in postgres or sqllite right? Currently I had the same requirement and i am storing it as a blob in the DB, and it is highly NOT recommended for performance reasons

[almet]

I think we would need to store the pictures on the host, as files.

[shrn01]

This sounds good, but some hosts, like heroku delete the extra files created periodically. If this won't be an issue, then that would be good👍

[Glandos]

In my work we are storing video surveillance images in small SQLite database, one for each camera and each minute. It can be up to 6 fps, so 360 JPEG images are stored in SQLite. This is not a big database, but we explicitly chose that option instead of many files, because of the I/O caused by metadata. I/O load dropped by 70% using SQLite database instead of individuals files.

I think we are here in a completely different goal, but as far as I experienced, storing blob into database is not that bad. They should be stored in their own table, at least. I added that because, if the need for a writable directory is difficult, database can be an option.

[almet]

Neat, that seem to be the easy path forward.

[shrn01]

I have one project which stores blobs into DB. You can check it out here

https://github.com/shrn01/code-red

I'm using SQLAlchemy as an ORM, so it's straight forward to store the blob

[zorun]

I'm not convinced about this use-case. As the original reporter said, and as our documentation highlights, Ihatemoney is designed for "high-trust" environments.

[azmeuk]

Maybe I can share my usecase. I use ihatemoney at home with 5 other people. Until last year we were on another similar project, for 10 years.
We used to upload bill scans, and this is indeed something we miss with IHM. There is no trust issue between us, but we want to be able to check for human errors on distribution. For example, if you get assigned to a bill for a meal where you were actually absent, the bill helps remember when was the meal and what was eaten.

This becomes even more useful when features like #471 is implemented. Someone bought common food, including some meat and put you on the bill, however you were absent for the very meal where the meat was eaten. Here you can check how must cost the meat and adjust the distribution so you don't pay for the meat.

[almet]

I was opposed to it, and then had the use case myself a few years back. Rather than keeping the tickets somewhere around at my place, it seems to make sense to have them uploaded in IHM. So, for me it's a +1 for this feature.

[zorun]

Ok, that can indeed make sense.

If we add that feature, it should not become a big burden for IHM server administrators. In my opinion, that means:

• definitely not store this data as local files. It should either be blobs in the database (see discussion above) or an external object storage integration (S3 protocol)
• the server administrator should be able to disable this feature through configuration (and I would argue it should be disabled by default)
• the server administrator should be able to set a limit on the size of the uploaded files through configuration, to try to control storage space

UX-wise, it's very similar to the existing "external link" feature, so it can be handled the same way (hidden under the same "More options" button)

Does that sound reasonable?

[zorun]

There is one point that needs UX design, though: how to display back this data in the list of bills?

If it's an image, it could be display on hover or in a modal.

If it's a PDF, then maybe a download button would be better.