File storage

File storing and protection is part of the AyMINE Business Framework – system application module

Terminology

Master object: Object to which the file relates. Object is any other object in the system that allows storing files with. (Example: information item (task module) allow storing files. It is master object of all files linked with it. )

• Each file is a part of some object. System does not allow files not included in some object.
• File lifetime is limited by the master object lifetime. When something deletes object, it also deletes all files stored with the object. (Remember: there is no undo operation for that; files are also immediately and physically deleted. The undo should be developed with object and supports soft delete to the trash.)
• Each file is liked with one and exactly one object. System does not allow linking file to more objects
  Note: File is not document. See (currently (1/2021) planned) document object for linking documents and included files with more objects.

Business logic

Mark

Mark allows create unique file identification. The unique name is not defined by system module and could be defined by business modules. (Note: it is intended to have the same functionality as task or information item in the tsk module.) Module disallow mark modifications after the creation.

Locks

Attribute lock protect file modifications or access. sysFile provides functionality to lock or unlock file, but does not define, when and who can unlock file. It should manage master object

Example: tskInfItem has linked files and can allow unlock locked filed only to someone. sysFile does not allow any file modifications until responsible person unlock the content.

clientName: name visible in the list of documents as well as name how the file is stored. System internally modifies the name to be compatible with various file systems (no spaces and special characters).

accessLock: protect access. Nobody can access the file until it is unlocked

modifLock: protects modifications: Nobody can remove or update file until it is unlocked.

hiddenLock: hidden files are not visible in default view, but they can be visible according to the rights to someone and someone no. Hidden lock visibility is managed by views. It does not influence system functionality.
Note: There are no functions, how to access / change document until it is unlocked.

deleteLock: disallow file delete. File cannot be deleted by any user.

WARNING: When somebody or system deletes object to which the file is linked, files is also deleted!!! The lock control uncontroled delete of the file, not delete of the major object with ALL files including locked.
(Note: files are part of the object and they have no their own existence. They cannot stay in the system without the master object)

systemType: type that backend processes can assign to a file – not editable by user and user cannot set; thus only system-generated documents can have it and user can never fake system document. Used internally to manage the documents – e.g. exclude defence file from full-string search (elastic database)

Implementation notes

Table

Most of the fields has null allowed value, because user file settings runs in 2 steps:

1. It saves the sysFile record
2. It saves file to the record
   Thus, sysFile record should exists even without file. Business logic should control not to leave it as an empty shallow.

internalName field

internalName should be unique in combination with the objectName and objectID. It preserves to have more documents that has direct link within the object, but makes no sense for objects linked via file list (files without defined internal name).
However, constraint is functional only in case that all fields are not null and so it allows more files with objectName/objectID/null values. So that files stored in the free list has internalName null.

Warning: Files stores via free link can be open only through the clientFilename (if distinguish) or via sysFileID.

sysFile detail support

sysFile detail has direct support in the sysFile.php and even objRecord (in the getObject method). Although relation of the sysFile with the file is different from the relation of other objects, client application does not make difference

File protection

The basic principal of the protection is that files are never stored in the location accessible from internet. Storage is accessible only for system management module processes, that holds information about files locally.

File protection preserves their access even before the download. User never has got direct link to the file but only information that file is available. System should request for file using the AyMINE functional requirement.

The bottom side of the protection is complicated right management for the application in the corporate environment. If organisation has very strict access control. The AyMINE download method requires to have right to download php files. Although php file is never downloaded request for download are by some firewall systems evaluated in this way.