FR: asset status

[thisisjamessmith]

My client would like to be able to disable assets without deleting them. Seems like a reasonable request. This would work exactly the same way as entry statuses do.

I don't think Craft necessarily needs to concern itself with the fact that a disabled asset is still accessible via its URL, but at least it should exclude disabled assets from being returned by calls to craft.assets. Though if there were a way that you could also disable direct access that would be a good bonus.

[iainhenderson]

I recently came to the same conclusion that an enabled / disabled status for assets could be a good idea. It may also solve some problems with the idea of trashed assets.

A disabled status would allow authors the ability to "remove an asset from publication" without deleting the actual file.

Users could be granted the "disable asset" permission, but not the "Delete asset" permission. Which could make asset manager safer by allowing users to upbublish assets without performing destructive actions.

The "Delete asset" function could be changed to offer users several options:

1. Disable the asset, but keep the file accessible (default behaviour)
2. Disable the asset and hide the file (Move to a ".disabled" sub-folder, or append a hash to obscure the file)
3. Permanently delete the file (Danger!)

Currently, the only option to "unpublish" an asset is trashing it. This workflow is similar to trashing an entry. UNLIKE trashing an entry, trashing an asset is not a soft delete - the file can't be recovered. Users who assume these two systems work the same way could easily wind up permanently deleting important files.

Adding the option to disable assets means you could remove the idea of asset trashing, and avoid this confusion.

[mmikkel]

My worry with "disabling" assets is that authors might expect that the actual file for a "disabled" asset will be inaccessible, which is not the case. This could create some really unfortunate situations.

[iainhenderson]

Hmm so maybe instead of enabled / disabled there are three statuses, similar to YouTube.

1. Public
2. Unlisted: File exists is uploaded location. Links to it aren't shown.
3. Private: File is in an inaccessible directory or has an obfuscated name. Links to it aren't shown.

[mmikkel]

I think 3. would be a very difficult problem to solve.

FWIW, an alternative solution to "disabled" assets, that is already possible, is to create a dedicated volume/filesystem (maybe called "Archived Files" or similar), that doesn't have URLs and with a file path above the webroot – and then train clients to move assets to that volume whenever they want to "unpublish" a file.

[thupsi]

Maybe this 'archive' volume could be an automatically created dedicated volume, configurable via a setting, and used for storing soft deleted assets?

[mmikkel]

@thupsi Yeah, that's basically what Brandon suggests here, for trashed/soft-deleted assets. I'm not sure if a similar solution would be feasible for "disabling" assets, but maybe.

[iainhenderson]

@mmikkel, You're right. a "Private" status triggers the same complexity of trashing and recovering assets - that you need to move files to and from an inaccessible archive location.

Maybe the "Unlisted" status is just a useful stop gap until we have something like an archive folder.