Menu

#142 Feature Request: Provide different ways to upload and store attachments, and drag attachment to card to upload it

Attachments
closed
nobody
2025-10-19
2015-02-24
Anonymous
No

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?).

Discussion

1 2 > >> (Page 1 of 2)
  • Anonymous

    Anonymous - 2015-02-25

    Originally posted by: shekar73

    i agree 👍

     
  • Anonymous

    Anonymous - 2015-02-25

    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.

     
  • Anonymous

    Anonymous - 2015-06-10

    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?

     
  • Anonymous

    Anonymous - 2018-03-09

    Originally posted by: xet7

    I will add S3, Google Drive support etc. I'll add this to my todo list.

     
  • Anonymous

    Anonymous - 2018-04-23

    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 !

     
  • Anonymous

    Anonymous - 2018-08-23

    Originally posted by: xet7

    Planning to use this package https://atmospherejs.com/malibun23/files

     
  • Anonymous

    Anonymous - 2018-10-09

    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

     
  • Anonymous

    Anonymous - 2019-03-20

    Originally posted by: xet7

    Moved to here from [#2274]

    From @rossmansfield

    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?

     
  • Anonymous

    Anonymous - 2019-06-06

    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.

     
  • Anonymous

    Anonymous - 2019-06-06

    Originally posted by: xet7

    @justinr1234

    How it's different from https://atmospherejs.com/malibun23/files ?

     
  • Anonymous

    Anonymous - 2019-06-06

    Originally posted by: justinr1234

    Seems similar

     
  • Anonymous

    Anonymous - 2019-06-06

    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.

     
  • Anonymous

    Anonymous - 2019-06-06

    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

     
  • Anonymous

    Anonymous - 2019-06-06

    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.

     
  • Anonymous

    Anonymous - 2019-11-15

    Originally posted by: azban

    I will add S3, Google Drive support etc. I'll add this to my todo list.

    @xet7 this hasn't been completed yet, has it? is there any reason, other than a lack of time/priority?

     
  • Anonymous

    Anonymous - 2019-12-08

    Originally posted by: xet7

    My 1Q 2020 is full.

    Does some other Wekan contributor have time to do this at 1Q ?

     
  • Anonymous

    Anonymous - 2020-10-21

    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)

     
  • Anonymous

    Anonymous - 2020-10-21

    Originally posted by: razum2um

    @xet7 @blaggacao did you have time to get back on this btw? could you maybe add hacktoberfest topic to the repo?

    p.s oh, it seems like tech discussion continues here https://github.com/wekan/wekan/issues/3272

     
  • Anonymous

    Anonymous - 2020-10-21

    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?

     
  • Anonymous

    Anonymous - 2020-10-21

    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.

     
  • Anonymous

    Anonymous - 2020-10-21

    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?

     
  • Anonymous

    Anonymous - 2020-10-21

    Originally posted by: blaggacao

    Yes the download location of ostrio:files is configurable. Upload goes through meteor, though. With upload comes the proper initialization of the image reference in the mongo database. So

    given there's already a self-hosted minio and some images inside

    would be rather awkward to support. Though nothing speaks against using a self hosted minion and populate it through wekan uploads.

     
  • Anonymous

    Anonymous - 2020-10-21

    Originally posted by: razum2um

    already a self-hosted minio and some images inside

    would be rather awkward to support

    oh, sorry, didn't realised input can contain just html https://github.com/wekan/wekan/issues/2635#issuecomment-694781543

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.