This appears to be a similar issue to #1894390: 'Edit own files' permission not granting access.

I'm using the latest dev versions of both File entity and Media. I have a multiple value File field using the Media file selector. When I click 'Add media', choose from the modal, and submit, the 'Add media' and 'Delete media' buttons output, but no 'Edit media'.

If I click 'Add another item', a new row is added and the 'Edit media' button missing on the previous row outputs.

If I comment out the #access property in media_element_process() the 'Edit media' button outputs correctly, so it seems like it's a combination of permissions and AJAX.

I've attached screenshots to illustrate the issue.

Files: 
CommentFileSizeAuthor
#13 media-editfile-1947388-13.patch2.43 KBalexkb
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]
#8 interdiff.txt1.55 KBbrantwynn
#8 media-editfile-1947388-7.patch2 KBbrantwynn
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]
#5 media-editfile-1947388.patch811 bytesalexkb
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]
no-edit.png232.57 KBbsuttis

Comments

Devin Carlson’s picture

Project:File entity (fieldable files)» Media

It sounds like this is a Media issue.

alexkb’s picture

Also experiencing this same issue with Media 7.x-2.0-unstable7+53-dev.

agnese.stelce’s picture

The same with Media 7.x-2.0-unstable7+62-dev.

tic2000’s picture

The only way I can make the "Edit" link appear after adding a file (a youtube or vimeo file) is to give "Bypass file access control" permission.

While debugging it seams that $file is FALSE because $element['#value']['fid'] is not set in media_element_process() and unless bypassing file access control file_entity_access will always return FALSE.

To check this I added the following code in file_entity_access and even with bypass file access control I get no edit button after adding a new file.

  if (!$file && $op == 'update') {
    return FALSE;
  }
alexkb’s picture

StatusFileSize
new811 bytes
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]

The "Edit own files" issue is happening because media_element_process() never actually has the $file that the user has uploaded (except for files previous uploaded in the form, or if a page refresh occurred). This could be fixed simply by changing the #access in media_element_process to only be checking for files it can check, otherwise return TRUE.

Doing this though, means that for sites that have "Edit own files" off, the "Edit" button will be briefly shown until "Add another item" is clicked. If the user did click it, they'd get permission denied (due to the menu access control check). Do sites actually let users "add new files" but not "Edit own files" ? Sounds like an edge case.

We could fix the edge case though. If you look at media.js, after the file is selected the trigger event is changed, and you can see the editButton.href getting dynamically updated with the $fid. So we could do an ajax call here to check permissions with the fid value, and toggle the edit button off or on.

Anyway, a patch is attached for the initial fix. Does the suggested fix for the edge case sound ok or a bit hacky?

alexkb’s picture

Status:Active» Needs review
brantwynn’s picture

Status:Needs review» Needs work

The "Edit own files" issue is happening because media_element_process() never actually has the $file that the user has uploaded (except for files previous uploaded in the form, or if a page refresh occurred). This could be fixed simply by changing the #access in media_element_process to only be checking for files it can check, otherwise return TRUE.

This now works beautifully thanks to the patch in #5 but there is still the edge case...

Doing this though, means that for sites that have "Edit own files" off, the "Edit" button will be briefly shown until "Add another item" is clicked. If the user did click it, they'd get permission denied (due to the menu access control check). Do sites actually let users "add new files" but not "Edit own files" ? Sounds like an edge case.

We could fix the edge case though. If you look at media.js, after the file is selected the trigger event is changed, and you can see the editButton.href getting dynamically updated with the $fid. So we could do an ajax call here to check permissions with the fid value, and toggle the edit button off or on.

Anyway, a patch is attached for the initial fix. Does the suggested fix for the edge case sound ok or a bit hacky?

I think we should do something to avoid this confusion. I'll take a crack at it.

brantwynn’s picture

Status:Needs work» Needs review
StatusFileSize
new2 KB
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]
new1.55 KB

Looks like we can do an ajax callback for file/[fid]/edit to check the file_entity_access for a given operation (edit, in this case) - so, if the page returns successfully, we can move forward with dynamically inserting the edit button.

willyk’s picture

I've applied the patch #1947388-8: 'Edit own files' permission does not output 'Edit media' button after adding file and it successfully inserts the edit button in order to resolve the issue as outlined.

brantwynn’s picture

Is that a RTBC? :)

Dave Reid’s picture

+++ b/js/media.jsundefined
@@ -71,14 +71,19 @@ Drupal.behaviors.mediaElement = {
+              $.ajax({
+                url: '/file/' + fidField.val() + '/edit',
+                success: function(data) {
+                  editButton.attr('href', editButton.attr('href').replace(/media\/\d+\/edit/, 'media/' + fidField.val() + '/edit'));

We should maybe add in type: 'HEAD' to the AJAX request since we don't actually need to care about the return HTML.

Also, we might need to test this with non-clean URLs. I have a feeling that url should be using Drupal.settings.basePath

aaron’s picture

Status:Needs review» Needs work

Changing status to needs work given #11's concerns.

alexkb’s picture

Status:Needs work» Needs review
StatusFileSize
new2.43 KB
PASSED: [[SimpleTest]]: [MySQL] 92 pass(es).
[ View ]

Re-rolled with Dave's suggestions, attached. Cheers.

samhassell’s picture

Status:Needs review» Reviewed & tested by the community

We've been using the patch in prod for a while now, it works fine.

Rob C’s picture

Yup looking good.

aaron’s picture

Status:Reviewed & tested by the community» Fixed
Devin Carlson’s picture

Status:Fixed» Closed (fixed)

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