Problem/Motivation

We are using View Unpublished to enable/disable access to content for anonymous users. This module adds some entries to table node_access for these nodes.

When setting up scheduled publish/unpublish for the nodes, nothing happens. While debugging why scheduler can't process these nodes, I noticed the queries in SchedulerManager::publish() and SchedulerManager::unpublish() got the tag "node_access". Therefore the query is expanded to select only nodes with a realm "all" which unfortunately does not exist for this nodes.

Proposed resolution

Scheduler performs its actions as an anonymous user so permissions shouldn't be restricted in any way for it.
Disabling access checks for the queries in SchedulerManager::publish() and SchedulerManager::unpublish() will do so.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

stBorchert created an issue. See original summary.

stBorchert’s picture

Status: Active » Needs review
FileSize
989 bytes
jonathan1055’s picture

Hi stBorchert,

This is useful. Thanks for the patch - I'll test it and make sure I underdstand any implications. Could you suggest how we might amend the automated testing to cover this? I suppose we would need a new test which enabled the View Unpublished module.

Jonathan

[edit to fix the link]

stBorchert’s picture

Hm, maybe this could be tested implementing hook_node_access_records() and hook_node_grants() in a test module and rebuild the permissions for some test content.
This will add a situation where these nodes are not accessible by scheduler without the patch.

legovaer’s picture

Status: Needs review » Needs work

Update to "Needs work" as we need to develop automated tests for this fix.

lucas.constantino’s picture

Patch re-roll.

jonathan1055’s picture

On #2803049: Scheduler Module is conflicting with View_unpublished module we also have confirmation that this patch works.

I am trying to write tests for it, and have created a support test module which denies all access to the nodes via hook_node_access_records() and hook_node_grants() as described by stBorchert in #4. It does what we expect when used with a real crontab job, but during the simpletest even if the test does not log in to a user account, because I am using the UI test runner built in to the drupal website it seems to be running with user 0 and thus ignores the denied access. This makes the test useless as it does not fail even without the patch. Does anyone know how to make $this->cronRun(), or any other cron execution method, behave like an anonymous crontab execution?

jonathan1055’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
5.98 KB

I have worked out why my tests were passing even without the fix. The {node_access} db table was not being rebuilt at test start-up, even though node_access_needs_rebuild(TRUE); is in hook_install of the test module. It needed a direct call to node_access_rebuild() in the setup function.

This patch contains the new test and associated test module, but not the fix to scheduler.manager from #6. Hence we should get test failures on this run.

Status: Needs review » Needs work

The last submitted patch, 8: 2700209-8.disable_access_checks.test_only.patch, failed testing.

jonathan1055’s picture

Title: Disable access checks on publish/unpublish » Disable node access checks during cron publish/unpublish
Status: Needs work » Needs review
FileSize
6.79 KB

As expected there are four failed assertions. This new patch has the tests and the code.

  • jonathan1055 committed cce36c7 on 8.x-1.x
    Issue #2700209 by jonathan1055, stBorchert, lucas.constantino, legovaer...
jonathan1055’s picture

Status: Needs review » Fixed

Thanks @stBorchert, @lucas.constantino, @legovaer
Committed!

  • jonathan1055 committed 8240eb5 on 8.x-1.x
    Issue #2700209 by jonathan1055: Correction to Node Access test module...

Status: Fixed » Closed (fixed)

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

jonathan1055’s picture

Commited a change to add Scheduler as a dependency to this module, to keep it tight when enabling the module manually for testing.