When upgrading to OMP 1.2, the transformation from table “signoffs” to table “queries” (in Upgrade.inc.php, function convertQueries) does not work for us.
We have three types of entries in table signoffs:
Auditors assigned to files in Editorial/Copyediting (SIGNOFF_COPYEDITING, assoc_type 515)
Auditors assigned to files in the publication format tabs (SIGNOFF_PROOFING, assoc_type 515)
Entries I don’t know what they mean (SIGNOFF_SIGNOFF, assoc_type 1048582)
The auditors assigned in Copyediting are well converted to table “queries” (with assoc_type 1048585=ASSOC_TYPE_SUBMISSION), but all participants from the Copyediting are assigned to that Discussion/File, not only the Auditor who was originally assigned to the file. We could delete them manually.
For the auditors assigned in the publication formats tabs, more seems to go wrong, although I am not sure, what the goal is. They don’t appear in the discussion section in stage “production”, actually they don’t seem to appear anywhere except in table “queries” with assoc_type 521= ASSOC_TYPE_REPRESENTATION and assoc_id=publication_format_id. There are also more participants assigned than where assigned originally and in one case, the entry is doubled in table queries, one with closed=0 and one with closed=1, but I don’t understand the meaning of “closed” in that context since there was no closing option in OMP 1.1.
As we don’t need the signoffs from stage “production” anymore, would it be save to delete all entries with assoc type 521 from the table queries (and the corresponding entries in table “query_participants”) ?
And what about the SIGNOFF_SIGNOFF entries in table signoffs? What do they mean and do they need to be ported to OMP 1.2?
I’ll take a look and come back as soon as I figured it out…
Just for me to be able to reproduce it correctly:
– who/what are those other participants from the Copyediting and Production that are also converted into the table queries?
– could the “closed” value correspond with the “considered” option for the auditors in 1.1?
– do you maybe know how could I reproduce those SIGNOFF_SIGNOFF entries?
Ah, I think I figured it out:
- I will see with Alec if it is meant to be so, that all participants are also participants in the discussion – this could be true.
- I think the assoc type = 521 is wrong, it should be 1048585 and you would then see those entries in the discussion in the production stage.
- SIGNOFF_SIGNOFF are apparently the editor’s actions on a signoff i.e. when a sighnoff is marked as “considered” i.e. completed. They seem to be correctly migrated into the DB table queries with closed = 1.
If the behavior in #1 is correct/wished – lets wait for Alec’s answer – then you maybe don’t want to delete those participants, but just leave them?
I couldn’t reproduce the double entries for the publication formats proofreads – except for the wrong assoc_type (and thus assoc_id) in the table queries everything worked fine for me here. Could you maybe tell me how to reproduce them? If you really want to delete them, you could then delete those with assoc_type=521 and stage_id=5.You will then also have to consider the submission_files with the assoc_type = 520 = ASSOC_TYPE_NOTE and the appropriate assoc_id, as well as entries in the table notes. (Note: Those publication formats files that had an auditor are not migrated as publication formats files, just as notes files. This might be not correct as well i.e. this should also be fixed). Else, I will try to fix it and will let you know, so you can use the patch.
Yes, I think that behavior in #1 is intended behavior; if it’s a bad assumption, alternative suggestions are welcome!
Public Knowledge Project Team
I opened a new issue about the migration of those signoffs, s. signoffs migration · Issue #1931 · pkp/pkp-lib · GitHub.
I made the upgrade fix, s. pkp/pkp-lib#1931 signoffs migration fix by bozana · Pull Request #341 · pkp/omp · GitHub (first for the master branch). Would it be possible for you to use this patch and try the upgrade again with this patch?
Thanks a lot!
Just to note here, that I could test the patch with some ‘real’ data and it worked…