Problem/Motivation
With files being posted as content with their own fields, there's often a need for fuller control based on entity data that doesn't yet exist. Examples:
- Ability to publish etc. media files to fit e.g. an anonymous submission and admin approval workflow.
- Promote videos for home page display.
Proposed resolution
Posted first as a sandbox and eventually promoted as a separate module, File admin, pulling code mostly from core's node handling.
Remaining tasks
Is this potentially something to be merged into File entity?
Maybe this would be better as entity_admin, with a file implementation?
Changes would be needed to file_entity to support a published status, see in #1227706: Add a file entity access API. This would allow file_admin to implement the new hook_file_access(), e.g. selectively denying access to unpublished files.
Likely file_admin.module could be further divided into include files where feasible.
User interface changes
Adds vertical-tabs style admin fieldsets to the file type edit form, allowing selection of defaults and also entering of submission guidelines.
Adds vertical-tabs style admin fieldsets to the media file form, allowing editing of author, created, published, promoted, and sticky fields.
Adds submission guidelines to the media file form.
Alters the media file admin overview form, adding a sortable column for published status. Also adds mass update options for e.g. publishing media items.
Adds new fields and filter etc. options to file views.
API changes
Adds four new fields to the file_managed table: created, published (not called 'status', the name of the equivalent field in the node table, because file_managed.status is already used for a different purpose), promote, sticky.
Adds Views exposure for these new fields.
Comments
Comment #1
Dave ReidComment #2
Dave ReidThis is probably more appropriate for file_entity now.
Comment #3
aaron CreditAttribution: aaron commentedi get the following errors when viewing the thumbnail view of the media content admin screen:
i agree this likely would be beneficial bundled with the file entity module. although i wonder if there might be confusion re. the whole 'published' bit, since it currently (i believe) has no effect other than allowing a new filter for views. granted that functionality is helpful, but i wonder if that might be confused with private files, and if that functionality would be better handled by flag.
Comment #4
aaron CreditAttribution: aaron commentedadditionally, 'Unublish' is a misspelling, 'promoting' a file incorrectly also publishes it, and i think the table should be sorted updated time desc by default.
Comment #5
aaron CreditAttribution: aaron commentedalso
Fatal error: Call to undefined function file_admin_form_media_add_upload_submit() in /var/www/d7-media/includes/form.inc on line 1409
when uploading new media from that page...Comment #6
Dave ReidI'm not sure these fields make sense since files aren't typically content. You could add boolean/checkbox field to your file entities to manage these properties.
Comment #7
nedjo@aaron: thanks for noting the issues, I'll work on fixing them up. Some are probably from recent changes in Media/File entity. Yes, further work would be needed to ensure that access is blocked to unpublished files.
@Dave Reid: files are not always content, but often they are. Take e.g. a site focused on videos, where users can upload videos, filling out title, description, etc., for admin review and approval and where approved videos are presented in views (carousels, etc.). With no ability to publish individual videos, all are by default accessible/visible. Yes, this could be handled in particular views through custom fields, but such content would still be accessible at its media/x path. As files become content in their own right, rather than appendages to nodes - which is what I understand as essentially the whole thrust of Media - they seem to need their own handling on more than a custom, one-off basis.
Comment #8
nedjoFixed up the problems aaron noted except from #4:
Re the access questions in #3, a lot of what would be needed is sketched out in #1227706: Add a file entity access API. This would allow file_admin() to implement the new hook_file_access(), e.g. selectively denying access to unpublished files.
Comment #9
dboulet CreditAttribution: dboulet commentedI think that this is a good idea, although I agree that the "Published" status of the file could easily be confused with a file access setting.
Comment #10
dboulet CreditAttribution: dboulet commentedFound one error in file_admin.views.inc:
Should be
'***VIEW_OWN_UNPUBLISHED_MEDIA***'
.Comment #11
nedjo@dboulet: Thanks for finding that error, fixed in the sandbox project.
Comment #12
Dave ReidComment #12.0
Dave ReidUpdated issue summary.
Comment #12.1
nedjoUpdated issue summary.
Comment #13
nedjoI eventually posted file_admin as a separate project, http://drupal.org/project/file_admin. Still, it might make sense to consider rolling it into file_entity, particularly after #1227706: Add a file entity access API is committed. A yeah or nay on this would be welcome.
Comment #14
ParisLiakos CreditAttribution: ParisLiakos commentedI think this is not the scope of file entity..
and since you already released the module which does all that, i think its best to leave it as a separate project.
Feel free to reopen this issue..you or anyone else, but i think, most sites dont need those features
Comment #14.0
ParisLiakos CreditAttribution: ParisLiakos commentedUpdate status.