As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

Forum rules
This forum is meant for general questions about the usability of OJS from an everyday user's perspective: journal managers, authors, and editors are welcome to post questions here, as are librarians and other support staff. We welcome general questions about the role of OJS and how the workflow works, as well as specific function- or user-related questions.

What to do if you have general, workflow or usability questions about OJS:

1. Read the documentation. We've written documentation to cover from OJS basics to system administration and code development, and we encourage you to read it.

2. take a look at the tutorials. We will continue to add tutorials covering OJS basics as time goes on.

3. Post a question. Questions are always welcome here, but if it's a technical question you should probably post to the OJS Technical Support subforum; if you have a development question, try the OJS Development subforum.

In order to simplify the process, or make it safer (the deleting step is always scary to me) I would like to add an option to HIDE the supplementary file for public viewing, in addition to EDIT and DELETE actions for supplementary files. The HIDE option would label the supplementary file so that it won't be publicly displayed when the paper is published.

The place where this setting can be stored might be the "type" column in the `article_supplementary_files` table in the database, so that type can be eg. "Source files". The HIDE action would set the type to "Source files" and the author could already set the type to "Source files" when submitting a supplementary file. When displaying supplementary files when viewing article, these labeled with "Source files" would not be displayed.

I'll try to see if I could implement this, but first I'd like to receive some comments if that would be an acceptable workflow for authors and editors, and if that is possible to implement codewise.

That approach sounds quite doable to me. My only caveat is that when we move to OJS 3.0 (due for release in the first half of next year) we are doing away with the Supplementary Files entirely in favour of supporting submissions as sets of files rather than just a single file. I think this will facilitate the kind of workflow you're doing but you'll have to consider how to migrate content. (We're expecting to maintain the 2.4 line of releases for quite some time afterward, as OJS 3.0 will need some time to stabilize and people will need to come to their own migration plans over the course of the following year or two.)

The place where this setting can be stored might be the "type" column in the `article_supplementary_files` table in the database, so that type can be eg. "Source files". The HIDE action would set the type to "Source files" and the author could already set the type to "Source files" when submitting a supplementary file. When displaying supplementary files when viewing article, these labeled with "Source files" would not be displayed.

Ales

Hi Aleskl,

What you said is exactly what I want to achieve. I cannot wait for 3.0 and need to implement this in 2.4.x. Have you been able to achieve this. If yes, could you post the code and change to your table?

I haven't done any code changes to implement hiding of supplementary files. Instead, we instruct our authors to pack the original files in a single zip file and upload it as a supplementary file. After our layout editor generates the final galley PDF, I delete these supplementary files. It's manageable for us because very few papers in our journals use true supplementary files, so this kind of workflow is not so confusing. The problem would be if we had a lot of true supplementary material mixed with original files used for final publication layout.