Image import does not respect node domain settings

This is an image import issue, similar to other issues filed against other import modules.

Well, let me take that back a bit. This problem comes up with any module that does import via node_submit() / node_save() in tandem. There may be a piece of logic missing in domain_node_access_records().

This is from the D6 version:

  // If set, grant access to the core site, otherwise
  // The grant must be explicitly given to a domain.
  if ($node->domain_site) {
    $grants[] = array(
      'realm' => 'domain_site',
      'gid' => 0,
      'grant_view' => TRUE,
      'grant_update' => FALSE,
      'grant_delete' => FALSE,
      'priority' => 0,         // If this value is > 0, then other grants will not be recorded
    );
  }

Perhaps we need to check to see if isset($node->domain_site) and use the default value from the settings if it is not.

@agentrickard:
should http://drupal.org/node/227401 be redirected here?

Possibly. I have not had time to investigate either issue.

One possiblity in DRUPAL 5.x (worked for me anyway) is to use the domain to which the user creating the node is affected.
For example, if a user is affected to domain sub.example.com:
In image.module, line 1004, add the following

//add domain access parameters, by using the user's domain.
  global $user;
  $user_temp = $user;
  rsort($user_temp->domain_user);
  $node->domains = array($user_temp->domain_user[0] => $user_temp->domain_user[0]);
  $node->domain_source = $user_temp->domain_user[0];

This way, the node's affiliation and source will be associated to the user's subdomain.
Offcourse this is a brutal force method (hacking the very module) and should only be used in desperate cases..
Any critic or comment is welcome!

I appreciate the work that's been put into the Domain Access modules; they've come in quite handy for me.

The problems with bulk import operations have been quite challenging for me and my colleagues, however. It's unclear to me whether the issue is with each import module (I'm using Audio Import and Imagefield Import), or with Domain Access. This thread seems to be inconclusive on the matter. Since at least 4 import modules are affected (Audio Import, Image Import, Imagefield Import, and Acidfree Albums Import), I'm hoping there might be a generic solution that could be applied in Domain Access.

I tried creating a quick and dirty hack in the Imagefield import module to get content assigned to the correct domain. The problem I was experiencing with Imagefield Import was that content was being assigned to the base domain regardless of the subdomain in which I was at the time I initiated the import. From what I can tell, nodes are associated with domains by associating nid with gid in the domain_access table. The hack I wrote in the Imagefield Import module works as follows:

1. First, I get the current domain's gid in the following manner:

     $current_domain_arr = domain_lookup($domain_id = NULL, $_SERVER['SERVER_NAME']);
     $current_domain_id = (int)$current_domain_arr['domain_id']; 

2. Then, in an ugly hack, I insert the nid and gid into the domain_access table for each node being added:
   

     $grants = array(array("gid" => $current_domain_id, "realm" => "domain_editor"), array("gid" => $current_domain_id, "realm" => "domain_id"));
     _domain_write_records($node->nid, $grants); 

After implementing the above hack, when I import images, the new nodes created for them continue to appear in the Affiliated Content list for the base domain rather than the current domain, but in the Affiliates column of that table the correct domain is listed, not the base domain.

I'm guessing that there are multiple places in the database where information about a node's domain affiliation is stored. Does anyone have recommendations about how to make bulk import work correctly? My programming skills are still a bit novice-level, so perhaps I'm just missing something obvious here.

Thanks in advance for your help!

Records are stored in both {domain_access} and {node_access}. The {node_access} table is what determines visibility; the {domain_access} table is used to store data in case we have to rebuild the {node_access} table.

Does ImageField Import work by firing node_submit() or drupal_execute() -- I suspect that the difference lies there.

Thanks for the quick reply, agentrickard! ImageField Import fires node_submit() followed by node_save(), just like the Image Import module does. I'll try hacking the ImageField Import module to update the node_access table as well.

Is the solution to this problem simply to change each of the import modules, or do you foresee future updates to Domain Access that will circumvent these issues?

Thanks much!

No, don't hack ImageImport. There may be a flaw in how DA is handling that data.

Try to patch DA instead. The issue is that DA is expecting to get the data from the node editing form, which is not happening. I think some of the logic from domain_form_alter() needs to be transposed into domain_node_access_records() if we can determine that a node is being created programatically.

Something like:

function domain_node_access_records($node) {
  global $_domain;
  // Define the $grants array.
  $grants = array();
  // Check to see if the node domains were set properly.
  // If not, we are dealing with an automated node process, which
  // means we have to add the logic from hook_form_alter() here.
  if (!isset($node->domain_site))) {
    // We came from a separate source, so let's set the proper defaults.
    $node->domain_site = variable_get('domain_node_'. $node->type, variable_get('domain_behavior', DOMAIN_INSTALL_RULE));
    // And the currently active domain.
    $node->domains = array($_domain['domain_id'] => $_domain['domain_id']);
  }

Attached is a patch for D6, but the same code applies in D5.

I finally had some time to try this patch today, and it works beautifully on the 5.x version of this module! The only problem was a small syntax error on the line

   if (!isset($node->domain_site))) {

where there is an extra closing parenthesis, but after I deleted that character the module patch worked really well!

I've tested import with both the Audio Import module (included as a submodule of Audio) and the Imagefield Import module.

FYI to anyone trying to apply this patch to a 5.x version of this module, I manually pasted the code into the domain_node_access_records() function, rather than use the patch tool on the command line. I'm not sure if that would work or not on the 5.x version of this module.

Thanks agentrickard, you have saved me from a huge challenge that has been looming over me!

I'm just glad we finally found a solution. I will post and commit patches as soon as I can.

Fixes the typo.

Thanks again for your speedy work!

I'm not sure if this patch also fixes the issue in http://drupal.org/node/227401 or not. I assume that if someone is using AcidFree Albums and cares enough to test this patch, s/he can post a reply in that queue.

Sorry, didn't mean to change the issue status.

Should I expect that this patch solves also issue http://drupal.org/node/233281 ? I migrated to D6, applied the patch, and tried to generate feed items from feed. As far as I can see the feed domain assignment is not transferred to the items: all feed items still get assigned to the main domain (irrespective of which domain I run the feed refresh from).

This will fix #227401: AcidFree does not respect all hook_form_alter() implementations.

It will partly fix #233281: Make feed item Inherit Domain Access info from feed.

The issue in #233281 is that you want to _inherit_ settings from the parent feed, which cannot be supported by this patch. What this patch does is check that the node creation process includes _some_ directives for Domain Access.

I spoke too soon regarding this fix. I noticed today that when Domain Source is in use, the source domain still isn't being set correctly when I use either import module (Audio Import or Imagefield Import). Sorry I missed this detail a few days ago. Is it difficult to write a patch to address this behavior?

Thanks!

@danobrienmuzyka - You want to pick up the source domain of the parent node? Or set the source domain of the created node?

Take a look at domain_source_nodeapi() for where the logic would need to be. The problem is that you are not required to specify a source domain. So automatically assuming that the created node should have a source domain assigned to it may not be the correct approach.

What type of behavior do you want, and how much control over that behavior do you need?

@agentrickard - I was assuming that the source domain of the created node would reflect the domain from which the bulk import operation was initiated. Instead, the source domain is being set to the base domain.

I didn't notice the problem during my initial tests because I was logged in as superadmin (uid = 1). When other users attempted to initiate a bulk upload using the Imagefield Import module, they got an Access Denied message. Then, if the user navigated to another page, a confirmation message appeared indicating that nodes had been successfully imported. When users other than user 1 tried to edit these new nodes, however, they also got an Access Denied message. Users other than user 1 do not have node editing access for the base domain, so I conjectured that this was the cause of the Access Denied message.

Also noteworthy is that, after completing the import operation, the Imagefield Import module displays a list of the new nodes created, along with an [edit] link for each node. The [edit] links pointed to the base domain (set by the Domain Source module). Since users do not have node editing permission on the base domain, I suspect this list of links may be related to the Access Denied message.

I've just completed a cursory test on bulk import when I turn off Domain Source on my staging site. Based on this test, once the new nodes exist, the domain-level admins can edit them, but those domain level admins still receive the Access Denied message and must navigate to another page for the import operation to complete.

Perhaps I should turn off the Domain Source module. My reason for using it was to improve SEO, but there is no situation where a given node appears on more than one domain, anyway, so perhaps it would simplify things to just stop using that submodule. That being said, I am not sure if the Access Denied message that occurs after clicking the Import button is a problem with Domain Access or one of its submodules, or with Imagefield Import.

Thanks again for all of your help and advice! It would take me ages to get this working properly without your assistance.

Well, I know why the source domain is set to the default (that is the standard behavior for nodes assigned to 'all affiliates'). I just don't know how we might alter this behavior -- though there is probably a way to do so, especially if the node is not assigned to all affiliates.

Unsure about the access denied, though if you are using domain-based editors, it is possibly becuase they are not editors for the primary domain.

Update: I finally had time to troubleshoot these issues some more, and discovered that the Access Denied message was a bug in the Imagefield Import module. So, no worries on that front.

With respect to the domain source issue, I never want to assign content to all affiliates, just to the site from which I am creating the node or performing the bulk import operation. In my own situation, I decided to just disable Domain Source and that seems to be an adequate approach for me. I'm assuming that if others have this problem with bulk import operations assigning content to the base domain and they really need to use Domain Source, they will want the issue addressed. For my purposes, the patch does what I need.

Thanks @agentrickard for all your help!

The following patch has been committed for testing purposes. It includes some misc. documentation changes, but otherwise affects drupal_execute() and other situations where hook_form_alter() does not run.

For domain source, we force the node to the current domain, which might not be proper in all cases.

Thank you for this, works (so far) on D6

This has been committed.

Still would like some review.

I can confirm that this solves the issue with content profiles being created at registration time, through node_submit followed by node_save.

OK, I am going to mark this as fixed.

Thanks!