Attachments (~binary files) can be attached to an entity, which implements AttachableEntity
interface. This entity is called attachment owner. Any owner can have more attachments. When owner is deleted, then all his attachments should be deleted too - override owner service delete method properly.
Attachments metadata are stored in database:
ownerType
- AttachableEntity
class - canonical name (e.g. eu.bcvsolutions.idm.rpt.entity.RptReport)ownerId
- AttachableEntity
identifier (uuid)contentId
- binary file identifier (used as file name for DefaultAttachmentManager
or "external" id into third party DMS)contentPath
- path to content (e.g. path on filesystem or url)name
- attachment name (e.g. notes.txt)description
- [optional] attachment description (e.g. My notes)mimetype
- content type (e.g. text/plain)encoding
- content encoding, its used mainly for text/plain contents (e.g. UTF-8).filesize
- content size in bytesversionNumber
- version number - int (e.g. 1, 2, 3, 4)versionLabel
- version label - string (e.g. 1.0, 2.0 , 2.1 , 3.0)parent
- [optional] the first attachment version identifier or null ⇒ is the first versionnextVersion
- [optional] the next attachment version identifier or null ⇒ is the last versionattachmentType
- [optional] - attachment type - can be used in search (e.g. draft, invoice)ownerState
- [optional] - sometimes is useful to attach file in some owner state, e.g. when owner has to be approved by workflow - can be used in search (e.g. approved, realized, rejected)
AttachmentManager
features:
saveAttachmentVersion
method). When attachments are found, then last attachment version is returned only. Attachment versions can be found by attachment identifier separately.
Attachment binary data are stored on filesystem by default implementation (DefaultAttachmentManager
). Different AttachmentManager
can be added to store binary data in other document management system (DMS).
DefaultAttachmentManager
stores binary files on file system. Path to storage on file system has to be configured. Default storage path is under user home directory (System.getProperty("user.home")/idm_data
).
System.getProperty("user.home")/idm_data
) - it's not recommended to use this location in production. Warning about default storage location usage is written into logs, when attachment is saved.
When binary file is saved, then uuid content identifier (contentId
) is generated and used as file name on filesystem with .bin
extension. Content path in storage is prepared from actual date with pattern yyyy/MM/dd/uuid.bin
. So content will be saved on path e.g. <storagePath>/2017/12/01/e963dd20-0a10-4052-8355-1425d021299a.bin
.
Attachment manager is responsible for maintaining temporary files and temporary attachments. Temporary files are used e.g. by report renderers, when output data are created and downloaded. Temporary attachments are used for uploading new files into CzechIdM - e.g. for extended attributes with persistent type ATTACHMENT
. Attachment is uploaded as temporary and when original form is submitted (owner's form), then the temporary attachment is moved under currently persisted owner (~renamed). When owner is deleted, all attachments are deleted too, but when owner's form is not submitted, then attachments remains marked as temporary.
Old temporary files and temporary attachments created by this manager are purged automatically (see temporary file time to live configuration).
Path to temporary files on file system has to be configured too (same as above). Default temp path is under storage path configured above (getStoragePath()/temp
). When storage path above is configured, then this configuration can be leaved empty - folder /temp
will be created automatically in storage path.
All configuration properties are described in backend congifuration.