Customizing the submissions page

Dear @NateWr or @asmecher (or anyone else who would know).

Thanks for all the help you guys have already provided. We have successfully made a theme plugin for OJS 3 that styles and customizes the frontend (although some tweaks remain).

We now want to add custom tabs for the /submissions page. This seems to require changing different sorts of stuff, so I wanted to ask for your kind guidance before I spend hours trying to figure out how this backend logic is put together.

I found that I could add a new empty tab by simply adding another <li> in templates/dashboard/index.tpl, but basically I don’t know how to fill that with content.

What I want to do is create a tweaked version (possibly several versions) of the existing tab “active”, so it would be helpful to start out with just duplicating that.

It looks to me like I might have to add a function in lib/pkp/pages/dashboard/ And then point that to a duplicated and tweaked version of dashboard/active.tpl?

It would be super useful if you could point me in the right direction here, and perhaps also comment on whether this is possible to do as part of the theme plugin, or if we just have to edit the application code directly.

Best regards,

Hi @edyrhaug,

Modifying the backend is kind of a whole different sort of problem. That doesn’t mean you can’t do it, but it takes a lot more investment in understanding the infrastructure that powers the backend UI.

We move more quickly in the backend, so you may have more maintenance work keeping your backend changes up-to-date. For instance, we just merged a big change upcoming for OJS 3.1, which includes a new submissions list.

I’d encourage you to check it out. It may address some of what you want to do with a new active list. And we’ll be investing in it further to make it easier to filter and track submissions in large journal settings.

Having said all that, here’s some quick orientation to hopefully help.

First, we’ve gotten rid of active.tpl and now all the submission tabs are defined in dashboard/index.tpl (here).

On one hand, that should make things easier for you. Here’s how the new active submissions list component is initialized:

And here’s how the active list data is passed to that template:

You should be able to use the docs in the theming guide to inject custom data into that template and add a new tab/list:

However, at this point, depending on what you want to do, things could get considerably more complicated. If you want to modify how the submission list appears (what content is in it), you’ll need to create a new Vue.js component and make sure you’re initializing that. It will require familiarity with a modern JS toolset, and an understanding of how Vue.js works.

1 Like

Hi @NateWr,

Thanks for getting back to me on this.

I’ve looked at the new code in master now and also gotten a copy of that up and running (with the npm vue setup).

Unfortunately I don’t think this will help us in our current situation, for two reasons:

  1. The release date for 3.1 is too far off. It looks like no release date is set for 3.1 yet, and that only 64% of the assigned issues have been completed so far. The changes we are currently trying to figure out how to implement are needed asap.

  2. The changes introduced in the submissions view in 3.1 go the opposite way of what we need. We need to introduce a whole lot more information on the “active” tab, and we need additional tabs with different information to cover different use cases.

(It might be that we should still adopt the new framework introduced in and customize that, but since we can’t wait for 3.1 we would have to cherrypick these changes into our current ojs-stable-3_0_2, and I don’t know if that would be advisable?)

Because of the time limitations here, I think our best bet might be to just change the main application code directly for now, and refactor these changes into the theme plugin or a new plugin later, probably at some point after the release of 3.1.

What we want to do is:

A) Introduce a bunch of extra columns in the ‘active’ tab, and to have these filled with data. As far as I can tell I can introduce new columns the way the ‘editor’ column is introduced in lib/pkp/controllers/grid/submissions/activeSubmissions/ (on ojs-stable-3_0_2), but I don’t get how I can fill that with data. We want columns like “submitted at”, “section”, “due date” etc.

B) Introduce an additional ‘active’ tab that is filtered on status = "in editing", with different set of additional columns. (We also want to filter the original ‘active’ tab on status = 'in review', so in other words we want to split the original ‘active’ tab in two tweaked versions, with different filters and different sets of additional columns.)

Can you guide me on how to do this fast, as a temporary hack, and then we can look at how to do it more properly within the framework of 3.1 at a later stage?

Hi @edyrhaug,

Sure thing. 3.1 is probably farther along than it looks because we tend to defer lots of issues at the end. But I wouldn’t want to be in your position waiting around without a firm date.

So every grid handler is served by grid row and grid cell providers. The grid cell provider is where you’ll find the details about adding information to the editor column:

Each grid handler can define it’s own cell provider, so you can extend that class with your own if you like, or just hack it into the core code. Here’s where the active grid defines its cell provider:

If you’re creating new submission grid classes for your use-cases, you’ll probably want to look at the loadData method on the ActiveSubmissionsListGridHandler:

The SubmissionDAO::getByStatus will probably be useful for you to pull out the data you need for your additional grids:

We’re planning to have filtering by submission status in the new lists, and hope to have them in for 3.1. The UI pattern has already been built for some OMP lists. But I don’t want to promise it for 3.1 just yet.

Thanks for the help @NateWr. I was able to implement a solution that gave us enough of what we wanted that we are happy with it as a temporary solution. We ended up changing three core code files directly. For the long term we want to do this (and a bit more) without changing core code of course, and we probably want to do it within the 3.1 grid framework (npm/vue).

Great! You can see an example of the list filtering that’s just gone in for 3.1 here:

And a couple of items on the agenda for 3.2 which I believe are related to feedback from your team:

I’d he happy to help you implement what you need outside of these features in a custom plugin as well. Just let me know when you want to discuss that.


This is a very interesting approach @edyrhaug and @NateWr. Thank you for exposing it, our authors too demand a similar solution and this is a good starting point.

Best regards

1 Like