Feature Request: Provide different ways to upload and store attachments,...
Brought to you by:
wekan
Originally created by: fnkr
Large databases are not easy to handle and to backup.
It would be useful to store attachments as file in the local filesystem (or maybe on a Cloud Storage provider like Google Cloud Storage or Amazon S3?).
Originally posted by: shekar73
i agree 👍
Originally posted by: ocdtrekkie
Local filesystem would definitely be nice. Not sure someone who wants a self-hosted board is going to really want to store data on Google or Amazon clouds though, as that largely defeats the point.
Originally posted by: dcworldwide
Users may or may not find value in self hosted attachments. I'd prefer if i could like to my google drive account. Any ideas of how we might achieve non-gridfs storage?
Originally posted by: xet7
I will add S3, Google Drive support etc. I'll add this to my todo list.
Originally posted by: ahashibon
supporting something like owncloud or next cloud would be great, also supporting access to davros on sandstorm would also be pretty cool! I doubt that using google, or AS would help much, this defeats the point point of own hosting !
Originally posted by: xet7
Planning to use this package https://atmospherejs.com/malibun23/files
Originally posted by: GavinLilly
Storing attachments in a different manner would certainly help organisations using Wekan self-hosted. The last thing they want is to have data stored in many places. In my mind AWS and GDrive would be the most applicable places to store and they're both supported by the "files" package
Originally posted by: xet7
Moved to here from [#2274]
From @rossmansfield
Link Card to Object Storage Bucket or SMB Directory
Hello all, first time posting here, so be gentle!
In lieu of attaching files into the actual WEKAN cards, it would be fantastic if we could somehow place a thumbnail image of an object in a network location or object-storage bucket. Even better would be if the Card could show the contents of a Bucket or file directory and allow the user to open said files from the Card. This is very similar to how Trello can embed Google Drive.
I've been experimenting with (SMB "Samba", OpenstackSwift, S3, etc. This would really help with team collaboration. A custom field could work to send users to the Bucket via an HTML link, but it doesn't allow for links to SMB type directories.
By having integration with a Swift or S3 type object storage system, redundancy can be handled at the infrastructure level vice the container level.
I have some experience with Openstack and Minio and could support on that end, I'm just not very strong with code development (yet).
Any thoughts on this?
Originally posted by: justinr1234
@xet7 it could be highly useful to use https://uppy.io
Very nice documentation, great features, and supports multiple backends. Can be integrated with Meteor server through the WebApp connect.
Originally posted by: xet7
@justinr1234
How it's different from https://atmospherejs.com/malibun23/files ?
Originally posted by: justinr1234
Seems similar
Originally posted by: xet7
@justinr1234
I don't find at uppy website any support for GridFS, where currently all Wekan attachments are saved. So it seems I can't use uppy. malibun23/files seems to have GridFS.
Originally posted by: justinr1234
@xet7 I thought the idea was to move away from GridFS? Either way, if the other works then no need to use Uppy
Originally posted by: xet7
@justinr1234
There needs to be ability to read existing Wekan attachments from GridFS to be able to move them to other storage. If I remember correctly, somewhere at malibun23/files docs is some storage migration guide.
Originally posted by: azban
@xet7 this hasn't been completed yet, has it? is there any reason, other than a lack of time/priority?
Originally posted by: rossmansfield
What would be a fair bounty to prioritize this for 1Q 2020?
Ross Mansfield, PE
O: (281) 888-0808
M: (713) 510-5000
E: Ross@KingwoodSmartHomes.com
KWSH
From: azban [mailto:notifications@github.com]
Sent: Thursday, November 14, 2019 7:41 PM
To: wekan/wekan
Cc: rossmansfield; Mention
Subject: Re: [wekan/wekan] Feature Request: Provide different ways to upload and store attachments, and drag attachment to card to upload it (#142)
I will add S3, Google Drive support etc. I'll add this to my todo list.
@xet7 https://github.com/xet7 this hasn't been completed yet, has it? is there any reason, other than a lack of time/priority?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/wekan/wekan/issues/142?email_source=notifications&email_token=AHMVLCNRVGHFWE6QHCTQKXDQTX43JA5CNFSM4A4UYZW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEED7QCI#issuecomment-554170377 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMVLCI5LSP5MMR6OHT6P23QTX43JANCNFSM4A4UYZWQ . https://github.com/notifications/beacon/AHMVLCNIE2L543JHJI6ZMOTQTX43JA5CNFSM4A4UYZW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEED7QCI.gif
Originally posted by: xet7
My 1Q 2020 is full.
Does some other Wekan contributor have time to do this at 1Q ?
Originally posted by: razum2um
@ocdtrekkie @ahashibon please, note, s3 does not "defeat the point" because it's a protocol and there's https://github.com/minio/minio self-hosted alternative with the same api (@rossmansfield mentioned it as well)
Originally posted by: razum2um
@xet7 @blaggacao did you have time to get back on this btw? could you maybe add
hacktoberfesttopic to the repo?p.s oh, it seems like tech discussion continues here https://github.com/wekan/wekan/issues/3272
Originally posted by: razum2um
@rossmansfield feel free to plegde anything https://www.bountysource.com/ or in crypto https://gitcoin.co/ do you still need this?
Originally posted by: blaggacao
The current implementation on [#3273] is just a special implementation of a storage backend towards GridFS MongoDB Buckets.
With the same strategy, those can be stored anywhere given a connector is provided. See for example here. I'd assume, storing to file system is as simple as not deleting the uploaded files and not storing them into a specific backend.
Originally posted by: razum2um
@blaggacao thanks for such a quick reply, btw, what do you think about another idea: given there's already a self-hosted minio and some images inside - can we just render direct
img src=to the direct location, i.e. not uploading twice, but specifying the link?Originally posted by: blaggacao
Yes the download location of
ostrio:filesis configurable. Upload goes through meteor, though. With upload comes the proper initialization of the image reference in the mongo database. Sowould be rather awkward to support. Though nothing speaks against using a self hosted minion and populate it through wekan uploads.
Originally posted by: razum2um
oh, sorry, didn't realised input can contain just html https://github.com/wekan/wekan/issues/2635#issuecomment-694781543
Originally posted by: blaggacao
Here is where a hook intercepts the upload and stores it into the back-end (and deletes the uploaded files):
https://github.com/wekan/wekan/pull/3273/files#diff-4a858d7364de26a72d82ca64882d740c4ecf2f5efe5eab5bd481a3a909d49518R26