Steps to do upon submission

I am looking at the next version of the Fidus Writer plugin after we have done some user testing and also to make it work with OJS 3.1.

PHP is not my native tongue, so I am slightly perplexed by some parts here. For example, it seems in order to make a submission and make it work like other submissions, it is not enough to create the submission object and add it using:


but additionally one has to copy and adjust rather large parts of PKPSubmissionSubmitStep4Form and SubmissionSubmitStep4Form. As far as I can tell, it’s not possible to just subclass these, as they rely on the request object having specific attributes that it will only have if the user were actually calling it. Is that correct? Or is there some way to call all these functions (basically their purpose seems to be to add author, editors and manager users to the submission and then to send out relevant emails about the submission having been received.

Hi @Johannes_Wilm,

Each DAOs corresponds fairly directly to a single database table (providing its basic CRUD operations, plus usually some helpers that might span a couple of tables), and an article/submission depends on entries in several tables.

DAOs correspond to model classes and the form classes correspond to controllers in the MVC; they aren’t intended to be subclassed for other (non-controller) uses.

You shouldn’t need to work with many DAOs to create a submission – I’d suggest looking at the native XML import/export plugin’s filters to find purer examples of how to create entities. These are unfortunately spread across several filter classes, so they aren’t perfect examples for your purposes, but they are collected in lib/pkp/plugins/importexport/native/filter and plugins/importexport/native/filter. The classes starting with NativeXml… are responsible for parsing XML entities into OJS’s database, so those will be relevant for you. (The others perform the opposite operation, converting OJS’s entities into the XML structure.)

If it helps, there’s some sample XML here in github.

I think the most compact way to accomplish what you need is to work with the DAOs as you’ve been doing, despite having to work with several of them.

If you want a short-cut to find out which entities are involved in a minimal article, you could trim down the import XML to a minimal example, use the error_log trick in HookRegistry to log the hooks called during the import process, then look through them for the entities that get created.

Alec Smecher
Public Knowledge Project Team

Ok, thanks for that. I’ll took a look, but it seems there it’s just importing the file without assigning any managers to the submission, right?

I noticed that when a user submitted via Fidus Writer, the submission would not automatically get an editor assigned, whereas a traditional submission would. I guess the difference lies in this:

    // Manager and assistant roles -- for each assigned to this
	//  stage in setup, iff there is only one user for the group,
	//  automatically assign the user to the stage.
	$stageAssignmentDao = DAORegistry::getDAO('StageAssignmentDAO');
	$submissionStageGroups = $userGroupDao->getUserGroupsByStage($this->submission->getContextId(), WORKFLOW_STAGE_ID_SUBMISSION);
	$managerFound = false;
	while ($userGroup = $submissionStageGroups->next()) {
		// Only handle manager and assistant roles
		if (!in_array($userGroup->getRoleId(), array(ROLE_ID_MANAGER, ROLE_ID_ASSISTANT))) continue;

		$users = $userGroupDao->getUsersById($userGroup->getId(), $this->submission->getContextId());
		if($users->getCount() == 1) {
			$user = $users->next();
			$stageAssignmentDao->build($this->submission->getId(), $userGroup->getId(), $user->getId(), $userGroup->getRecommendOnly());
			if ($userGroup->getRoleId() == ROLE_ID_MANAGER) $managerFound = true;

And then I started looking more at that and it seemed like there are more assignments happening there (sub editors) and after that, in SubmissionSubmitStep4Form, there are notifications about the submission being sent (Notifications = emails to author and various editors, managers, etc., right?).

Coming from the Python/JavaScript world, I am just surprised that there isn’t a function defined somewhere that basically is used to “add submission with the following attributes to the database + add default user rights and send all relevant notifications”. It just feels like I copy a lot of code that I would assume would be be available in just one function to ensure that everyone executes it in the same way.

Btw, while I’m at it, as part of the code I need to copy, I see that the notificationmanager related calls and some others need the request as an argument. I am trying to understand what it needs the request for, because in our case it won’t come from the browser and so it won’t hold specific post variables or login tokens/cookies or whatever it may expect browsers to send in their requests at step 4.

Hi @Johannes_Wilm,

We’ve only really had three different ways to create submissions:

  • The QuickSubmit plugin
  • The normal workflow
  • The XML import/export

None of these have had enough overlapping requirements to justify a layer between them and the DAO classes. This is something that will probably change as we further build out the REST API.

The notification classes are quite crufty – I don’t believe there are any cases of notifications being created without a valid user session and request object, so it’s likely that the request object is getting passed in as shorthand for e.g. getting the router object to build a URL. This is due for clean-up but we haven’t had the time yet, I’m afraid.

Alec Smecher
Public Knowledge Project Team

1 Like

@Johannes_Wilm Just to chime in here to add on that this is a big part of our goal to build out our REST API, and then to bring more of our UI to rely specifically on that. A simple “create submission and do everything else required” is something our SubmissionService class will eventually do, so that it’s used by our REST API, import scripts and any other needs. But we’re just beginning that refactor process.


Ok, thanks, @asmecher and @NateWr ! Then that makes sense. I’ve looked more at it. It seems like what I need to do is to create a dummy request object the way you guys do in the tests and then hand that to all the various functions that ask for a request.

Hi @Johannes_Wilm,

Not ideal, but yes, until we’ve had a chance to clean up the notification classes etc. Let me know if you run into any unexpected dependencies and I’ll see if we can take a look.

Alec Smecher
Public Knowledge Project Team