I know deploy module is probably not the root cause of the issue but it is where I will most likely receive feedback.

Multiple tickets refer to "UUID Services for file should not use the update method." which is quite confusing as last statement looks like "We should not fix this issue directly but should investigate and fix these two issues". This was the statement 2y ago and in the meantime the related issues are fixed but I am still not able to properly deploy files.

This is the state of my investigation:

  • Follow the Basic usage of deploy and deployed basic nodes
  • Add a file/image field to the node and try to deploy:
    Trying to save a File entity with empty or invalid UUID.
  • Apply this very simple patch.
  • Deploy the node and get:
    DeployServiceException: Service error: 403 : Access denied for user ...
  • After digging the code, the issue seems to be in entity_metadata_file_access() which is alway returning FALSE if the operation is not "view" (which is never the case when deploying a node. Simply forcing the function to return TRUE makes it working.

As altering the entity_metadata_file_access() function is definitely not a valid solution (at least with a basic return TRUE), I am wondering what is the proper fix and if anyone managed to deploy file/image. If yes, is there any patch/addition module I should be aware of ?

Thanks,

CommentFileSizeAuthor
#9 file_deployment.jpg87.74 KBjoseph.olstad

Comments

vbouchet created an issue. See original summary.

vbouchet’s picture

Issue summary: View changes
vbouchet’s picture

Issue summary: View changes
caspervoogt’s picture

I am also experiencing this, except that forcing entity_metadata_file_access() to TRUE does not help the situation. Even if it did, it does not seem like the right solution.
I would love to hear from others how they are using Deploy with file and image fields, because although I can deploy nodes without files/images just fine, nodes with files/images give these 'DeployServiceException: Service error: 403 : Access denied for user' errors.

caspervoogt’s picture

vbouchet, you might try authenticating as user 1 (the user 1 from your endpoint / production site), or better yet, make sure the administrator role on your destination site has File Entity's 'Bypass file access control' permission.

On a hunch (because it's not mentioned in the docs as far as I could see) I tried that just now, and it worked beautifully. So then it's a permissions thing.. specifically I think File Entity's 'Bypass file access control' permission, I think. I tested this using an admin account (on the destination site) that was not user 1, and it also worked. I did also give the administrator role some all File Entity permissions, so maybe one of the other ones is the real culprit - I don't know.

vbouchet’s picture

caspervoogy, I have not posted here but I did something which may not be the best solution but at least it works without forking a module.

I create a custom module with:

  • hook_entity_info_alter() implementation to override the default entity file access callback:
function ft_deploy_services_entity_info_alter(&$entity_info) {
  $entity_info['file']['access callback'] = 'ft_deploy_services_entity_metadata_file_access';
}
  • The custom access callback check a permission or return the default file entity access callback:
function ft_deploy_services_entity_metadata_file_access($op, $file = NULL, $account = NULL, $entity_type) {
  return user_access('save file information') || entity_metadata_file_access($op, $file, $account, $entity_type);
}

Please note that I had to implement hook_module_implements_alter() to be sure my custom entity_info_alter is called after the entity_entity_info_alter().

function ft_deploy_services_module_implements_alter(&$implementations, $hook) {
  // We must have ft_deploy_entity_info_alter()'s implementation being called
  // after the entity's implementation to override the file access callback.
  if ($hook == 'entity_info_alter') {
    $group = $implementations['ft_deploy_services'];
    unset($implementations['ft_deploy_services']);
    $implementations['ft_deploy_services'] = $group;
  }
}

I think this solution is only a workaround.

caspervoogt’s picture

Ah, yes, I had seen some comments mentioning that approach. I would be curious if you were experiencing this issue because of not using user 1, and the admin role not having the permissions I described. I am trying to update the installation document to mention checking permissions settings or otherwise use hook_entity_info_alter() when dealing with file deployment problems.

vbouchet’s picture

Related issues: +#2794521: Deploy UUID Error
joseph.olstad’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev
Status: Active » Fixed
StatusFileSize
new87.74 KB
  1. The easiest way to make file deployment work using admin_views and bulk operations is this:
  2. Upgrade to the deploy 7.x-3.x-alpha1 (latest version as of I write this)
  3. Install the "deploy_plus" module
  4. Then go to the admin/structure/views/view/admin_views_file
  5. click on "bulk operations"

    see illustration:
  6. illustrate selection of views bulk operations for adding file entity to managed deploy plan
  7. then from the list: put a checkmark here:
    " Manage entity in deployment plan "
  8. Now you can deploy files in batch with bulk-operations at admin/content/file

It is easiest to do it with the built in capabilities of deploy_plus as I described above.

IMHO, deploy_plus works so well, it should be included as a sub-module to deploy.. However for now its a separate module that depends on deploy.

Alternatively, if you want to do it the harder way with rules (possibly without deploy_plus) , that works too, you can make a custom rule and then select it in views bulk operations, however why do this when you can just enable deploy_plus? More info about rules in the video below:
https://drupalize.me/videos/using-rules-components-vbo?p=1157

joseph.olstad’s picture

Status: Fixed » Needs review

Actually, I'd have to run more tests to be sure of all the prerequisites, for us, it works, to do what we've done I'd have to enumerate our contrib module versions and patch levels.

Perhaps the prerequisites has already been documented by someone else in great detail?