DRAFT of "file attachments"

[crossan007]

What's this PR do?

creates a new database table for "files" and one for "file associations"
Files can be created / deleted / retrieved from both the person and family(v2) views.
Files associated with a person are displayed on the person page.
Files associated with a family are displayed on the V2 family page.

A rudimentary WebDAV implementation is provided as well to provide file access via external client.

The underlying file storage mechanism is as follows:

File storage implementation

1. At file create time, the SHA256 is calculated
2. A UserData directory is created in the src folder (if it doesn't already exist)
3. Within UserData, a top-level subdirectory is created with the first character of the SHA256 hash of the file; A second-level subdirectory is then created with the second character of the hash in like-manner. (This avoids a large-gathering of files in one folder, and prevents users from creating files with "stupid characters" that make things messy server-side)
4. The filename, hash, size, and created/modified dates are persisted to the SQL database.

file retrieval implementation

1. The file is requested by id.
2. The given file id's hash is fetched from SQL
3. The file is identified on disk by hash (according to the folder structure above)
4. The hash is checked.
5. IF the hash matches, the file is served by the file model using the Slim Response object

Screenshots (if appropriate)

Related Issues:

#122
#350
#4658
#4800
#4786
#4498

[MrClever]

Checked out and tested the web-facing functionality on my dev system successfully. Also the directory creation needs to use the correct mode (0755) instead of 600.

I haven't looked into the WEBDAV functionality yet, but I can see the path (/CRM/wbdav) being buried in the code causing problems:

• users changing code will trigger a file integrity warning
• obscure config requirement; ideally users shouldn't need to go beyond Include/Config.php and the system settings in the web interface.