Send submissions to iThenticate at later stage

[amandastevens]

Currently the iThenticate plugin sends a submission to iThenticate after the author has completed the submission. A PKP|PS hosted client would prefer to instead send submissions to iThenticate at a later point - after an editor has looked at the submission and decided to send it to review. This journal receives an average of 600 submissions per year and rejects 70% initially because they do not meet basic criteria. They would rather spend their iThenticate credits on submissions that are actually being considered for publication.

Would it be possible to add a setting to the plugin that allows a journal to configure at what point a submission gets sent to iThenticate or what action triggers the iThenticate submission?

[asmecher]

@amandastevens, what point would it make sense for this journal? e.g. on sending the submission to the review process? (My current thinking: a single point of submission is unlikely to make everyone happy, and selecting from a bunch of options might be brittle and get badly maintained... so what about a manual submission process? What is iThenticate's turn-around time like?)

[amandastevens]

I asked the client and they said "Definitely yes! a manual trigger would be great. (e.g., a check box or button). Such an option would save us over 400 credits with iThenticate." So I think having one of these additional options would be great:

• send submissions manually to iThenticate
• configure the plugin to send submissions automatically either when they are completed or when they get sent to review

[alexxxmendonca]

Same issue is happening to SciELO journals too.

Many use iThenticate but they prefer using it via the web interface instead of the plugin since they can control which papers to submit for analysis on the former but not on the later.

Having a manual submission process would definitely benefit our journals.

[aguen]

In addition, if a submission consists of multipe components (article text, cover/rebuttal letter, materials etc.) manually sending submissions might help to decide which file/component of a submission is send to iThenticate and which not. So a place to manually trigger sending to iThenticate might be when editors send a submission to the review phase (i.e., no desk reject) and select the review file(s). Only these review files should be send to iThenticate.
What is not so nice with this solution is that the submission would be in the Review phase already even though editors would want to wait for the result of the plagirism check until they assign reviewers - and would even have to stop review at all if the plagiarism check reveals some issues. Actually, it might be more appropriate to have this check still in the "Submission" phase.

[emoaida]

Nós fazemos isso, o Editor Chefe olha, dá ok, para submissão, encaminhamos para revisão, e o primeiro revisor é o Editor de Plágio, que faz a análise em até 5 dias, depois vai para revisão dos pares. Temos o plugin mas não utilizamos, no momento está desativado.

[aguen]

Nós fazemos isso, o Editor Chefe olha, dá ok, para submissão, encaminhamos para revisão, e o primeiro revisor é o Editor de Plágio, que faz a análise em até 5 dias, depois vai para revisão dos pares. Temos o plugin mas não utilizamos, no momento está desativado.

Doing the plagiarism check in the review phase as a first review (done by a member of the editor team) is an interesting idea. Thank you!

[NateWr]

This would be a good use-case for the new editorial decisions workflow in 3.4 (see #7265). The plugin could add a step to any editorial decision which allows the editor to select files to be sent to iThenticate.

[NateWr]

Here is a quick outline of how this could be addressed in 3.3, so that it can be gracefully upgraded to support 3.4:

3.3

• Add a setting to the plugin where the journal can choose when to send files to iThenticate: initial submission (when the author submits), when the submission is sent to review, when the submission is sent to copyediting.
• Move the automated deposit code so that it occurs when the setting has been made.

3.4

• Keep the same plugin settings in place.
• Based on the plugin settings, add a step to the correct editorial decisions that lets the editor select which files to send to iThenticate.
• If the plugin is set to send files on initial submission, do it automatically.

[twakeford]

I can see the advantage of editors selecting when to send these files, but can I please also argue for not only this option and to retain the journal level setting where they are sent automatically and not triggered by the editor?

We often get requests from editors about reducing click count. Adding something for them to manually do that was once automatic may not go down too well. More importantly though, from the publisher's perspective I need to know that we're completing anti-plagiarism checks on all submissions without having to check each submission. I can't rely on each individual editor to manually assess and select the appropriate files as that could easily open the process up to files being missed (either accidentally or on purpose to avoid scrutiny).

Our strong preference would also be to choose which article components are sent to iThenticate. e.g. a submission with 5 PDF figures with captions will each cost c.$1, so our cost for that submission has gone from $1 to $6.

[NateWr]

I understand the desire for automation and there will probably still be an option for automation when sending the files is configured at the moment of submission. But I want to point out that automation will introduce human error as well, and maybe more of it. If we automate based on the file component (eg - Article Text), all it takes is an author to select the wrong file component for plagiarism checks to be missed.

With editorial review, there is at least a human involved in the process who can spot a wrongly-labelled file. If a step is added to an editorial decision with the files pre-selected, we'll get human oversight with minimal overhead.

[twakeford]

Yep, there are definitely pros and cons to both, thus having the plugin accommodate custom setups/workflows would be very valuable as I think that the use case for one journal may be very different from another.

(As a slight aside, the point of an author choosing the wrong component is something we hope to address in future by introducing a setting where a journal can make certain components mandatory. This has more advantages than only for the iThenticate plugin. Something for another thread)

[NateWr]

An issue exists for making submission file components mandatory: pkp/pkp-lib#6241.

[touhidurabir]

A new discussion started at #33 to gather more ideas/proposals and to finalise an improved implementation if possible . Any idea/proposal is highly appreciated .

[JackieHeCc]

Our journal has recently used the iThenticate service, but has also encountered the problems mentioned by @amandastevens. @NateWr’s suggestion is very good. It is very necessary to let the editor decide whether it is necessary to use iThenticate for the article, and let the editor follow It is also necessary for the author to choose which file will be submitted in the attachment uploaded by the author.

What I would like to propose is whether a function button can be added to the relevant part of the article. After the editor uploads an attachment to the article, this button can quickly open the backend of iThenticate without having to open IE and enter the corresponding URL before logging in and so on. operate.

Finally, I would like to ask whether there is a development plan for the above functions, and when the plug-in update will be released. In addition, our journal is currently using OJS version 3.3, whether the new plug-in will be compatible with 3.3.

Thank you so much.

[asmecher]

Closing; this has been implemented in recent betas, e.g. https://github.com/touhidurabir/pkp-plagiarism/releases/tag/1.0.7-0-Beta-7 for OJS/OMP/OPS 3.3.0-x. This will move into the Plugin Gallery as a formal release soon.