Mandatory metadata on file upload

[chillu]

Overview

Organisations have different metadata requirements for asset management that should be consistently enforced at upload time. After upload, a file can be used both programmatically and through the CMS UI, and the system might not get a chance to ask for this metadata.

These capabilities would get us a lot closer to functioning as a Digital Asset Management (DAM) system.

Acceptance Criteria

• The dialog can be triggered on AssetAdmin
• The dialog can be triggered on UploadField
• The dialog can be triggered on "Insert Image" and "Insert File" in rich text editor
• The file is only uploaded after the metadata is added
• The dialog validates the input and shows validation errors on submission
• The dialog uploads the file when submitted with all required metadata
• The file is not uploaded if the dialog is cancelled
• The dialog input can be composed from different modules
• The solution does not require replacement of the UploadField implementation, it can work on top of it

Sample Uses

• Set title (for accessibility reasons, separate from file name)
• Set image cropping metadata (e.g. "crop on face")
• Preview crop variations
• Set focal point on single image
• Set focal point on different crop variations of image
• Set content review periods
• Set content owner
• Set content license, copyright and credit

Notes

• The "only uploaded after metadata is added" requirement might complicate the implementation. For example, any cropping and resizing previews would need to happen client-side (and work with potentially large bitmap images)
• The dialog needs to be composable, e.g. a "Cloudinary module might add crop previews, and a "contentreview module" might add content owner dropdowns.
• Some metadata could be prepopulated from EXIF or Office document data, but that's out of scope for this ticket

Related

• mademedia/silverstripe-cloudinary module

/cc @frankmullenger @clarkepaul

[chillu]

@clarkepaul Frank and his team might need this early next year, do you want to get this on your design backlog to sketch out?

[clarkepaul]

Added to backlog cheers.

[frankmullenger]

Preventing upload of an asset before validation of File object isn't a hard requirement for us. However, we would somehow want to either control if the File can be used anywhere by content authors if it doesn't have the necessary metadata or report to content authors where they are using invalid Files.

Might be worth considering that some metadata might be retrieved via Oembed from a third party in some cases as well. This is mostly for videos that are hosted on youtube etc. but we are likely using a subclass of File for those for various reasons.

[chillu]

Yeah I'm not sold on preventing upload either, it might complicate the implementation. A report on invalid files might fulfil the same purpose.

[clarkepaul]

Had a quick chat to @frankmullenger and seems they went with a lighter approach where they just notify users as a warning that some fields are missing potentially important information, rather than a forced requirement.

I don't think all those sample fields should be set as "required" fields globally as some files wouldn't have a license, content review period, or crop variation.

@ingo is it possible to show notifications based on the placement a file is intended to be used, like on the uploadfield itself ( eg. "this file is missing details XYZ to be used for this placement")?

[chillu]

Hmm, context specific validation seems like it would frustrate authors quickly. We do have some of that in "insert image" into rich text areas, where you're force to set an alt text for an image in CWP environments. We want to keep the UIs as consistent as possible across their implementations though, so these special cases make our mainentenance harder

[clarkepaul]

context specific validation seems like it would frustrate authors quickly

Likewise having a required license field for every file when it only needed in a few instances would be annoying. Agree that there needs to be the flexibility to have additional fields but I'm just trying to get my head around whether having an additional dialog interface is any better than just adding additional fields/tabs to edit panel of the file and running validation on those fields, and showing alerts if not satisfactory? I think a chat might clear things up a bit, keen to have a chat @chillu

[clarkepaul]

@frankmullenger is this still something which is on the cards or have you taken any steps to provide this functionality?

[frankmullenger]

@clarkepaul we have provided some functionality that meets requirements for the project, so we are not relying on this piece of work at all thanks.

[clarkepaul]

@frankmullenger cheers, I'm removing this from the UX priority list for now. It'll still remain in the backlog though as it will probably surface again in some form. Leave it up to @chillu whether we keep it.

[chillu]

Moving this back to Icebox, not a priority right now

[chillu]

I'm closing this, the key project has solved this differently, and I don't see us doing this anytime soon.