Object store
Currently, images in a manuscript are imported and stored as inlined base-64 elements within the manuscript itself. We would prefer these to be stored separately in an image store. Attachments to a manuscript should be controlled by the same mechanism.
- The object should be held in s3/minio.
- A reference to each object should be held in the manuscript's record in the DB.
- Deletion of all references from DB should cause deletion of object from s3/minio.
- We should distinguish between objects that appear in a manuscript (images) and objects that are attached (supporting files). This is so users can be presented with a list of attachments that doesn't include every image in the manuscript.
- We should support multiple downscaled versions of images.
- The same image store may be used by both Kotahi and a Flax-generated static published site, so initially, we shouldn't need to implement API access or export functionality.
We need to discuss whether the same objects (images and attachments) should be reused across multiple versions of a manuscript, or whether we should duplicate the objects for each version. The latter approach is simpler, as it allows a one-to-many mapping between manuscript and object, rather than a many-to-many mapping.
Storage of downscaled images will become valuable only once Wax allows image scaling.
See comments in #575 (closed).
Reference flow; Miro board
What is needed;
- storage of images
- web image for display
- high res image for overlay