InvenTree icon indicating copy to clipboard operation
InvenTree copied to clipboard

[FR] Move attachments and images to a generic files model

Open matmair opened this issue 1 year ago • 16 comments

Please verify that this feature request has NOT been suggested before.

  • [X] I checked and didn't find a similar feature request

Problem statement

Currently, files are handled by different attachment models and as "dumb" image attachments. This makes reusing and working with these files from code (core, plugins) difficult.

Suggested solution

Create a first-class citizen model for files with metadata and tags support. Migrate all attachments and images over.

### Files/Attachment related issues
- [ ] #5691
- [ ] #5429
- [ ] #5531
- [ ] #5048
- [ ] #5047
- [ ] https://github.com/inventree/InvenTree/issues/2585
- [ ] Add CI tests for common vulnerabilities
### Out of scope
- [ ] #5532

Might also be interesting for #3101

Describe alternatives you've considered

Create an api-layer that simulates the same thing.

Examples of other systems

No response

Do you want to develop this?

  • [X] I want to develop this.

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar

matmair avatar Oct 16 '23 06:10 matmair

I fully support this idea. This also enables us to use the Django files api with different backends rather than fiddling directly with the fs.

wolflu05 avatar Oct 16 '23 06:10 wolflu05

This is marked as horizon, I will probably only get this done by December or later.

matmair avatar Oct 16 '23 06:10 matmair

@wolflu05 that is part of the difficulty, there are some patterns around that behaviour that are core to how reports work (currently)

matmair avatar Oct 16 '23 06:10 matmair

On board with this, needs to be handled very carefully but will be a great improvement in a number of areas

SchrodingersGat avatar Oct 16 '23 07:10 SchrodingersGat

Started work on this, targeting 0.15.0

matmair avatar Feb 09 '24 16:02 matmair

I would point out that one file might be uploaded multiple times (eg. same picture or safety manual for 2000 pipes with different dimensions and colors maybe) so "id by content hash" and multiple references to the hash could solve deduplication from day one. Maybe secondary uploads could have different metadata, but include a pointer, that "this is the same file as id=12312345".

Petrox avatar Feb 09 '24 17:02 Petrox

@Petrox I do not plan to support that, that issue was intentionally left out of this.

matmair avatar Feb 09 '24 18:02 matmair

Ok, no problem. I'm not making the decisions, just pointed at the low hanging fruit.

Petrox avatar Feb 09 '24 19:02 Petrox

I think you underestimate the amount of edge cases and (hopefully) atomic database transactions that need to be handled correctly to implement this safe, reliable and performant. Anyone is free and encouraged to submit a PR implementing it. I am not against the idea but do not see it being valuable enough for the broader user base to spend a bunch of time on it.

matmair avatar Feb 10 '24 01:02 matmair

I don't think it would be so much more complex compared to the basic option of "don't look just store", but I do accept that development is incremental and smaller steps are better than huge ones.

Also file deduplication could be handled at filesystem level if it's important.

Or maybe it could be a feature 3 years from now. Definitely not critical.

On Sat, Feb 10, 2024, 02:16 Matthias Mair @.***> wrote:

I think you underestimate the amount of edge cases and (hopefully) atomic database transactions that need to be handled correctly to implement this safe, reliable and performant. Anyone is free and encouraged to submit a PR implementing it. I am not against the idea but do not see it being valuable enough for the broader user base to spend a bunch of time on it.

— Reply to this email directly, view it on GitHub https://github.com/inventree/InvenTree/issues/5703#issuecomment-1936790900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXFKXLBUWV44OKPU2AWK4LYS3C53AVCNFSM6AAAAAA6BU6W3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWG44TAOJQGA . You are receiving this because you were mentioned.Message ID: @.***>

Petrox avatar Feb 10 '24 12:02 Petrox

A few points here are still open

matmair avatar Jun 19 '24 06:06 matmair

looking into this again @SchrodingersGat @wolflu05 what is your opinion on renaming attachments to files?

matmair avatar Aug 18 '24 20:08 matmair

Good idea, but then we need to first separate the concept of a link attachment and a file.

wolflu05 avatar Aug 18 '24 20:08 wolflu05

How so? Linked files seem very helpful in general

matmair avatar Aug 18 '24 20:08 matmair

Are these links always used for links to files? I actually never have used them for this case, as I always have downloaded the datasheet and uploaded it to inventree in case it gets removed from the internet, but this makes sense when thinking like this.

But if we rename it again, plugins that use attachments will break again. I think we should start treating such thinks like model names, function names, ... as stable things instead of renaming and moving them over and over.

wolflu05 avatar Aug 18 '24 21:08 wolflu05

@matmair can you help me understand where a more "generic" files model would be implemented? I had thought that the changes made already (bringing all attachments into a single table) was sufficient.

SchrodingersGat avatar Aug 18 '24 23:08 SchrodingersGat