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.

Related issues

Comments

Dave Reid’s picture

Component: Code » File entity
Dave Reid’s picture

Project: D7 Media » File Entity (fieldable files)
Component: File entity » Code

This is probably more appropriate for file_entity now.

aaron’s picture

i get the following errors when viewing the thumbnail view of the media content admin screen:

Warning: array_pop() expects parameter 1 to be array, null given in file_admin_form_media_admin_alter() (line 70 of /var/www/d7-media/sites/all/modules/file_admin/file_admin.module).
Notice: Undefined index: #options in file_admin_form_media_admin_alter() (line 73 of /var/www/d7-media/sites/all/modules/file_admin/file_admin.module).

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.

aaron’s picture

additionally, 'Unublish' is a misspelling, 'promoting' a file incorrectly also publishes it, and i think the table should be sorted updated time desc by default.

aaron’s picture

also 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...

Dave Reid’s picture

I'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.

nedjo’s picture

@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.

nedjo’s picture

Fixed up the problems aaron noted except from #4:

  • 'promoting' a file incorrectly also publishes it. Yes, this is potentially counterintuitive, but it's consistent with what core does in node_node_operations().
  • the table should be sorted updated time desc by default. file_admin doesn't touch the ordering so it would need to be changed in Media.

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.

dboulet’s picture

I 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.

dboulet’s picture

Found one error in file_admin.views.inc:

<?php
/**
 * Implements hook_views_query_substitutions().
 */
function file_admin_views_query_substitutions() {
  return array(
    '***ADMINISTER_MEDIA***' => intval(user_access('administer media')),
    '***VIEW_OWN_UNPUBLISHED_NODES***' => intval(user_access('view own unpublished media')),
  );
}
?>

Should be '***VIEW_OWN_UNPUBLISHED_MEDIA***'.

nedjo’s picture

@dboulet: Thanks for finding that error, fixed in the sandbox project.

Dave Reid’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Dave Reid’s picture

Issue summary: View changes

Updated issue summary.

nedjo’s picture

Issue summary: View changes

Updated issue summary.

nedjo’s picture

I 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.

ParisLiakos’s picture

Status: Needs review » Closed (won't fix)

I 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

ParisLiakos’s picture

Issue summary: View changes

Update status.