* [Platform/Custom Fields] Implemented configurable parameters for custom fields.  The various custom fields types can now provide additional options to modify how they work.  Picklist and multi-checkbox fields had a hardcoded parameter for their option list which has been converted to the new format.
* [CHD-3582] [Custom Fields/Owners] Added a 'Send worker notifications' option to worker-based custom fields.  This makes it easy to add an 'owner' field to any kind of record.  More advanced workflows are also possible; for example, having two owner fields for a 'salesperson' and 'sales support'.  Owners receive watcher notifications about record activity for the duration of their assignment.  They don't need to explicitly watch or unwatch records.
* [Custom Fields/Links] Implemented a new 'Record Link' custom field type.  This is similar to how the Links tab works, except the custom field is formalized and the fields of the linked record will be shown in Virtual Attendant behaviors, snippets, etc.  For instance, a time tracking entry could have a custom fieldset with fields for an organization and a domain.  Time tracking records could then be filtered based on those links, and the related record information could be used in Virtual Attendants, worklists, and the API.
6.6-dev checkpoint
Merged branch '6.5.3' into '6.6'
Merge branch '6.5.3' into 6.6
* [Setup/Storage/Attachments] Fixed an issue where an attachment worklist with multiple links pointing to the same file resulted in missing rows.
[Code Cleanup] 6.6 version tag on plugins
* [Setup/Attachments/Worklists] Attachment worklists now display the storage profile column as a name rather than an ID.
* [CHD-3377] [Setup/Attachments/Worklists] Attachment worklists once again provide links to the records containing the files (i.e. the 'Context' column).  Previously, a link was provided to the ticket but workers had to dig for the message containing the file.  Now, when clicking on the permalink for an email message attachment that specific message will be expanded and focused.
* [CHD-2971] [Mail/Reply/Usability/Keyboard] When using the keyboard to navigate the ticket reply form, using the attachments upload popup previously broke the TAB flow through the form.  Now the focus is returned to the attachments (+) button after files have been uploaded.
* [Storage/Platform/Optimization/Performance] Cerb now automatically detects when a new storage object duplicates an existing one, and an additional link will be created to the same underlying file.  A file is only removed when there are zero links pointing at it (e.g. message or comment attachments).  Duplicate attachment detection is implemented for incoming mail, worker replies through the UI, the worker proxy, messages imported from an ImpEx export, and files uploaded through the API.  This should save a considerable amount of storage space in environments where the same attachments (e.g. PDFs, forms, ebooks) are sent by workers on a regular basis.  Similarly, when the same senders include logos and other content in their signature these can be condensed into a single storage object.  Currently, existing storage objects are not hashed since would be very intensive on busy systems.  New duplicates will be prevented from version 6.6 onward.  However, we'll be providing instructions on how to retroactively hash existing storage objects and remove redundancy (technical note: this involves providing SHA1 hashes in the attachment.storage_sha1hash database column, and redirecting attachment_link records based on that).
6.6-dev checkpoint
* [Mail/Parser/Performance] The 'original_message.html' attachment is now created more efficiently for new incoming messages.  Previously its contents were written to a temporary file that was then read into long-term storage.  Now it is saved directly from memory into storage.  This improvement also made it easier to modify the contents of the HTML message to improve usability (e.g. rewriting links for inline attachments to Cerb URLs).
* [Mail/Parser/Usability] When viewing an original_message.html attachment in the browser, inline images will now be properly displayed in the content.  For instance, this is useful when customers send screenshots by embedding them in the middle of their reply.  Previously, such images were included as attachments on the ticket but they weren't displayed in the HTML contents (technical note: The IMG tags still referenced the MIME content-id header).  These IMG links are now rewritten to use Cerb file paths.  This process works for all new messages that are received in version 6.6 or later, but it will not fix existing original_message.html attachments.
* [Devblocks/Platform/Markdown] Added the Parsedown library <http://parsedown.org/> to Devblocks.  This is a faster, leaner, and more modern replacement for the existing PHP Markdown Extra library we've been using up to this point.
[Storage/Code Cleanup] Improved the style of the Setup->Storage->Profile page.
* [Setup/Storage/S3/Usability] When testing a new S3 storage engine profile, a temporary object will be saved, read, and deleted to verify that the credentials work for all actions.  Previously the contents of the bucket were listed, but this didn't verify that content could actually be stored and retrieved.

* [Setup/Storage/S3/Usability] The S3 storage engine now supports a 'Path prefix' configuration option.  Previously all content was saved starting at the top-level of a bucket.  Now a single bucket can be shared between multiple instances of Cerb.

* [Setup/Storage/S3/Security] When configuring the S3 storage engine, the secret key parameter is no longer displayed in the profile popup form.  If left blank it will remain unchanged.  This is far more secure than transmitting it.
[Devblocks/Platform/S3] Updated amazon-s3-php-class from 0.4.0 to 0.5.1-dev
* [Storage/Performance] The storage service now has the ability to queue multiple delete operations to perform them in a single transaction.  This is useful for storage engines where incremental deletes would be very expensive.  For instance, S3 would generate an HTTP request per file being deleted, which could potentially be hundreds or thousands.  Waiting for that many HTTP requests during cron.maint is undesirable.  It is now possible for hundreds of objects to be deleted in a single request.

* [Setup/Storage/S3/Usability] Implemented batch delete functionality in the S3 storage engine.  Up to 500 objects can be deleted from S3 in a single HTTP request.