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/DashboardHandler.inc.php? 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.
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.
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:
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.
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 https://github.com/pkp/pkp-lib/pull/2399 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/ActiveSubmissionsListGridHandler.inc.php:60 (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?
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).
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.