Attached is a export of a views bulk operations based admin screen for files. It is modelled after what is provided by the Media module now. I'd like to get feedback on the suitability of such a view within File Entity. IMO providing a VBO based default would be helpful for end users and also site builders, who can review the implementation and modify as they see fit. VBO for D7 is a massive step forward and I'd personally be happy to see projects relying on it rather than creating their own table based UIs.

As far as functionality goes I didn't see any of File Entity based tokens to provide the edit operation. I see token code is in File Entity but the replacement options are not listed from within Views (at least as far as I can see). There also isn't yet an appropriate permission from File Entity to use so the permission is "administer site configuration".

Curious to hear feedback as to whether this belongs in File Entity, Media or in neither project. The export can be turned into a proper patch if feedback is positive in one direction or the other.

Comments

rickvug’s picture

Screenshots attached

bojanz’s picture

I'm just preparing a "create an archive of selected files" action for VBO core. Should be useful for the view above.

Of course, I like the idea. This is an approach I would like to evaluate for Commerce as well.
The main problem is a matter of dependencies, you need to depend on VBO, which in turn depends on Views and Entity API, which might be too much for what is essentially an API module.
On the plus side, VBO is pretty widely used (41.6k installs, 4.5k on D7, and rising fast).

rickvug’s picture

@bojanz I agree that the dependencies aren't ideal. One option would be to avoid hard dependencies using module_exists(). Either that or splitting the functionality into a stand alone module that ships with File Entity or Media. Personally I'd rather re-use than re-invent. Anyone running File Entity is most likely to already be running CTools, Views and Entity API and perhaps even VBO.

dave reid’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev

File entity has switched to a 7.x-2.x branch and the 7.x-1.x branch is no longer used. Please make sure to update your Git clones.

dave reid’s picture

Yeah, having a dependency on VBO or Entity API is not an option for this module. With the default view code in the original comment, does the view show up fine if VBO is not installed or do we get a 'Missing handler' error? Is it possible to wrap the VBO-specific exported code in a module_exists()?

gmclelland’s picture

It's worth noting that http://drupal.org/project/og 7.x-2.x uses VBO for it's bulk operations.

devin carlson’s picture

Title: Provide a default files admin screen via Views + VBO » Provide a default files admin screen via Administration Views
Assigned: Unassigned » devin carlson
StatusFileSize
new14.25 KB

As Dave Reid mentioned in #5, adding a dependency on VBO and Entity API is not possible but we could provide integration with the popular Administration Views module which would enable us to optionally leverage Views + Entity API + VBO.

The attached patch adds an administration view for files.

devin carlson’s picture

Status: Needs review » Fixed

Committed #7 to 7.x-2.x.

gmclelland’s picture

Hmm... For some reason when I try to use the VBO at admin/content/file it doesn't seem delete the files or update them? It goes through the motions, but nothing ever happens.

I'm using all the latest dev versions of the modules including the admin_views module. It could be related to #1892582: Permission error using VBO to manipulate Files (bulk modifying fields), but I'm not see the permission errors that everyone else is.

Anyone else having trouble using this?

gmclelland’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kenorb’s picture

Assigned: devin carlson » Unassigned
Issue summary: View changes
mrpauldriver’s picture

Unless I've missed something Admin Views support does extend to the thumbnail view. This would be very useful for applying filter criteria etc

Would this be a separate feature request or does it belong to this issue?