I use this module on a site that is using commerce license (https://www.drupal.org/project/commerce_license) and its dependency module advanced queue (https://www.drupal.org/project/advancedqueue)
The story is: When a license entity passes its expiration date, a queue job is created that will set the license status as expired. On the next cron run the license has to be updated. On commerce_license.module
the function commerce_license_expiration_queue_process
is loading a license:
$license = entity_load_single('commerce_license', $data['license_id']);
if ($license) {
$license->expire();
}
Unfortunately, entity_load_single returns FALSE.
The problem lies on domain_entity.module
@ line 131: function domain_entity_query_alter(&$query)
This is used to alter the query and add additional access rules, based on the domain.
The function domain_entity_get_user_available_domains
is used to "Return a list of domain id's, accessible by the current user"
But cron runs as anonymous user, and probably on the default domain, which means that the access is restricted.
I am not sure if this could be considered as a bug, or that it works as designed. And also, I am wondering if domain_entity module should be blamed for this. It is clear that the questionable bug is caused by this function. But is it supposed to be that way?
Would it be against the module's logic, to add an additional check on the beginning of function domain_entity_query_alter
, so that if the function is called during a cron run, no extra domain-related checks will be triggered and no domain-restrictions will be applied.
Please note that I tried to run cron manually, through drush, by appending the --uri
argument, but it still did not work expire the license.
Comment | File | Size | Author |
---|---|---|---|
#11 | cron_is_unable_to_load-2664892-11.patch | 502 bytes | mvdve |
#7 | cron_is_unable_to_load-2664892-7.patch | 3 KB | efpapado |
#2 | problem_with_commerce-2664892-2.patch | 954 bytes | efpapado |
Comments
Comment #2
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedI propose a patch.
This is the best workaround I could think of: bypassing the query alteration during cron-runs.
Comment #3
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedComment #4
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedComment #5
delta CreditAttribution: delta as a volunteer commentedmmmmh think of it, taking a large breath ... expire..
Maybe we should do it, and add a general settings for this, to not break the existing sites workflow.
- Add a variable domain_entity_cron_bypass (default to false)
- expose it in the UI (or not)
- Add a check, before bypassing for cli
Comment #6
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedAttached :)
Comment #7
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedAgain, fix typo
Comment #8
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedComment #9
mvwensen CreditAttribution: mvwensen commentedGreat patch!
This patch works perfect for my use case:
A scheduled node with a file field using the Scheduler module (on cron) on an Domain Access site. When a node was scheduled the file reference would disappear after the cron publish action.
The code looks also good to me. (patch #7)
Comment #10
super_romeo CreditAttribution: super_romeo commentedDear efpapado, thank you for patch!
But I suggest replace
with
because:
Comment #11
mvdve CreditAttribution: mvdve commentedThe domain module already has a special request setting for cron.php. The only issue is that this status is ignored by the domain_entity module. Attached a patch with a fix. The issue that the cli has no access will still be there. This needs to be fixed within the domain_grant_all() function or you could implement hook_domain_grand_all_alter() and do something like this: