In the past, several users have been asking whether there was a chance to hide some item’s files to public viewers (for copyright or other reasons); the general answer seemed to be that they might want to do at code level for public pages, but that the feature itself was not available in Omeka.
Having to solve a similar problem myself, I thought I would give it a go.
My idea would be to create a plugin (Hide Files) that introduces a “public” field (exactly like the one present in Items table in the Omeka’s database), defaulting to true; then, adds to the admin
file/edit pages an Is Public field (exactly as for Items and Collections), and then use that value in file_markup filter to hide the file (maybe replacing it with a “file not shown because…” warning) when the public field was false.
I’d like to pick your brains about some things:
- would it be better to add a “public” column to the “files” core table in the database, or to create a “hideFiles” table instead; I’m not particularly keen on messing up with core tables, as they might be changed in the future, but it would seem to me as a cleaner option (a column for a table);
- there seems to be no filter applied to
item_image_gallery (see Any filter that applies to item_image_gallery?); how to use the new field also in that function?
- would it be better to allow for files hiding also on Admin side, according to user level/rights?
Any advice will be well received, thanks.
Wouldn’t it help to base your public/private flag on the original media record ‘private’ attribute?
Not sure I follow you there. What flag are you referring to? If it’s the Item’s one, the answer would be no, as you might have several files attached to an Item and only one/few of them that have to be hidden (while the others can be shown - e.g.: a book and its abstract, the book might be covered by copyright while the abstract not; a picture at low and high resolution, with the low one visible and the other one not).
Oops sorry I misread this as a Omeka S topic. Missed too many coffees today.
Some improvements to report: I’ve created a stub of the plugin, you can find it at https://github.com/DBinaghi/plugin-HideFiles
The plugin adds a Public checkbox to
files/edit page and matching panel to the
files/show page (all files are public by default). Once one file is marked as “not public”, it won’t be shown on Public and Admin side according to config options (taking into consideration whether a visitor is logged in and the users’ level), with an alternative plugin icon shown instead; besides, links to original filename will be hidden, in order to make it impossible (or at least very hard?) to retrieve the original file.
The plugin is far from perfect, though: I’m still looking around to intercept all links to the original filename; besides, there’s quite a ToDo list:
- remove File Edit links for hidden files from
items/edit page, when needed (admin side);
- block/limit access to
files/edit page (admin side); at least, make it impossible to change the public/private flag to those who are not supposed to do it;
- look for more efficient
hookAdminHead coding (I’m using DOM there, jquery would have been more efficient but if I try to load it it gets commented out in the page’s head);
- amend/improve column check in
_columnExists function (name space clause is missing, as I could not find a way to get the db’s name);
- add hidden files list to admin interface (when required in config)
Besides, while developing it, I’ve found out the files/edit page was not firing the two hooks
admin_files_panel_fields, so one has to edit the core file (
admin/themes/default/files/edit.php) as follows
<section class="three columns omega">
<div id="save" class="panel">
<input type="submit" name="submit" class="submit big green button" value="<?php echo __('Save Changes'); ?>" id="file_edit" />
<?php if (is_allowed('Files', 'delete')): ?>
<?php echo link_to($file, 'delete-confirm', __('Delete'), array('class' => 'big red button delete-confirm')); ?>
<?php endif; ?>
<?php fire_plugin_hook("admin_files_panel_buttons", array('view'=>$this, 'record'=>$file)); ?>
<?php fire_plugin_hook("admin_files_panel_fields", array('view'=>$this, 'record'=>$file)); ?>
Anybody willing to test it or advise me on any of the issues? I’d really appreciate it. Thanks.
p.s.: of course, if the feature could be implemented in the next Omeka’s release, that would be great: adding it at core level would make things so much easier and faster…
This topic was automatically closed after 250 days. New replies are no longer allowed.