Hooking to publishIssue

Software Support
1

Hi,

Is there a way to hook into the publishIssue function here: https://github.com/pkp/ojs/blob/master/classes/controllers/grid/issues/IssueGridHandler.inc.php#L391

2

Hi @ajnyga,

Off the top of my head, you should be able to use the LoadHandler hook to intervene before the normal processing would happen.

Regards,
Alec Smecher
Public Knowledge Project Team

3

Thank @asmecher,

I just could not figure out how to use the loadhandler hook here. Basically I would need the id of the issue that is being published which I would use to run a database query inside the plugin.

I was hoping to use this in the preprints plugin I made. The idea was that when a new issue is published, the plugin would remove the preprint flag from the submission_settings and the article would not show up in the preprints listing anymore. https://github.com/ajnyga/preprints

I changed the plugin now so that the listing also checks the status of the submission. If there is a preprint flag + status == 1, then it is shown in the preprints listing. Otherwise not. The downside is that over time the amount of submissions returned by the query will be larger and larger.

As a side note I noticed, that the unpublish issue function does not change the article status back to 1, it will stay as 3.

4

@ajnyga, I’ll take a look i.e. think a little bit how that could be solved… will then come back to you…

Concerning the article published status (= 3, right?): an article has that status when it is assigned to an issue. Thus, if one would like to see if an article is ‘really’ published, one will have to also see if the issue is published :slight_smile:

Thanks!
Bozana

5

@asmecher and @ajnyga

In order to be able to ‘hook’ to a GridHandler operation, some changes would be needed for the LoadComponentHandler hook:
These lines where the operation is calculated: https://github.com/pkp/pkp-lib/blob/master/classes/core/PKPComponentRouter.inc.php#L214-L216
should be called earlier, e.g. here: https://github.com/pkp/pkp-lib/blob/master/classes/core/PKPComponentRouter.inc.php#L176
and that operation should be added to the hook call, as a second parameter, here: https://github.com/pkp/pkp-lib/blob/master/classes/core/PKPComponentRouter.inc.php#L186

Then in a generic plugin, one would register for that hook, i.e. something like:
HookRegistry::register('LoadComponentHandler', array($this, 'setupGridHandler'));

Then in the callback function one would have to have something like this:

function setupGridHandler($hookName, $params) {
$component =& $params[0];
$op =& $params[1];
if ($component == ‘grid.issues.FutureIssueGridHandler’ && $op == ‘publishIssue’) {
$componentA = ‘controllers.’.$component;
// We expect the handler to be part of one
// of the following packages:
$allowedPackages = array(
‘controllers’,
‘lib.pkp.controllers’
);
// A handler at least needs to implement the
// following methods:
$requiredMethods = array(
$op, ‘authorize’, ‘validate’, ‘initialize’
);

  	$componentInstance =& instantiate($componentA, 'PKPHandler', $allowedPackages, $requiredMethods);
  	$request = $this->getRequest();
  	$args = $request->getUserVars();
  	$roleAssignments = $componentInstance->getRoleAssignments();
  	if ($componentInstance->authorize($request, $args, $roleAssignments)) {
  		$componentInstance->initialize($request, $args);
  		$issue = $componentInstance->getAuthorizedContextObject(ASSOC_TYPE_ISSUE);
  		// do something with the issue...
  	}
  }
  return false;

}

I.e. one would have to initialize the component here (like it will be done in the PKPComponentRouter) in order to be able to check authorization and securely get the issue object. (One could immediately get the issueId argument, but I believe the authorization check is good/necessary to have, right?)

@asmecher, do you think it would/could be a decent way?

Else, maybe to add a new hook into this function publishIssue?

Thanks!
Bozana

6

Hi @bozana and @bozana,

Ah, I see.

I think the best approach is to support a mix of both high- and low-level hooks; the low-level looks usually provide the best coverage, but sometimes can be painful to use because of their low semantic worth. (LoadHandler is a fair example of a very usable low-level hook; the DAO hooks for SQL operations, less so.) The high-level ones are nicest and best-targeted, but there are many parts of the code that don’t specify them.

Perhaps it would be best to add both – the LoadComponentHook handler you describe, @bozana, and higher-level hooks in the specific handler too?

Thanks,
Alec Smecher
Public Knowledge Project Team

7

just dropping by to say thank you once again @bozana and @asmecher. The handler hook would of course work, but I have a feeling that I am not the only one who will look for a speicific hook from the publishIssue function.

8

Here is the GitHub issue to follow: Additional hooks · Issue #2572 · pkp/pkp-lib · GitHub

:slight_smile: Bozana