Attachment manager

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 bytes
• versionNumber - 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 version
• nextVersion - [optional] the next attachment version identifier or null ⇒ is the last version
• attachmentType - [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:

• save attachment - when attachment is saved, then metadata are saved in database and binary file is stored in filesystem (by default).
• save attachment version - attachments are versioned. Only major versions are supported now (e.g. 1.0, 2.0, 3.0). Attachment can be versioned automatically by attachment name (see saveAttachmentVersion method). When attachments are found, then last attachment version is returned only. Attachment versions can be found by attachment identifier separately.
• update attachment metadata - e.g. binary data is unchanged, but new attachment description was added ⇒ creating new attachment version is not needed.
• find attachments by owner, by identifier, by filter (comming soon)
• find attachment versions by attachment identifier
• delete attachments by owner, by identifier
• create and purge temporary files - attachment manager is responsible for maintaining temporary files too. Old temporary files created by this managers are purged automatically (see temporary file time to live configuration).

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

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 too. Temporary files are used e.g. by report renderers, when output data are created and downloaded.

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.

Old temporary files created by this manager are purged automatically (see temporary file time to live configuration).

• Add filter - find attachment by name, description, type … etc.
• Attachment frontend agenda
• Support authorization policies
• Store binary data in DMS (e.g. Alfresco ECM or other DMS using CMIS), for fulltext search in binary data, replications, better cluster support, etc.
• Save attachment templates e.g. by owner type only (ownerId is required now)