InvenTree
InvenTree copied to clipboard
[FR] Move attachments and images to a generic files model
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.
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.
This is marked as horizon
, I will probably only get this done by December or later.
@wolflu05 that is part of the difficulty, there are some patterns around that behaviour that are core to how reports work (currently)
On board with this, needs to be handled very carefully but will be a great improvement in a number of areas
Started work on this, targeting 0.15.0
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 I do not plan to support that, that issue was intentionally left out of this.
Ok, no problem. I'm not making the decisions, just pointed at the low hanging fruit.
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.
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: @.***>
A few points here are still open
looking into this again @SchrodingersGat @wolflu05 what is your opinion on renaming attachments
to files
?
Good idea, but then we need to first separate the concept of a link attachment and a file.
How so? Linked files seem very helpful in general
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.
@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.