PKP Bugzilla – Bug 4554
Cannot re-order some sections
Last modified: 2013-12-02 14:35:57 PST
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
When trying to re-order sections up or down the TOC, some will not move as expected. For example, the linked UP arrow for "Report From The Presidential Team" has no effect:
Also, the DOWN arrow for the "Index" section just above the "Report From the Presidential Team" section is not linked at all, providing no way to move this section down the TOC.
Similar problems can be found in the following issues for this SFU-hosted journal:
Vol 53 #5
Vol 54 #4
Vol 55 #5
Vol 56 #5
Vol 57 #5
Vol 58 #5
Vol 60 #5
Vol 61 #6
If this can be patched, could it be applied to this journal?
Kevin, do you know what steps they took to cause this? I reproduced the behavior once, but I can't for the life of me do it again.
No, but I will ask them and cc you on the message.
The most probable cause, OTOH, is something like an article being published to an issue in a section that wasn't previously part of the ToC. That's enough of a special case that it may not currently be handled properly.
No, its not quite as simple as that.. It seems to be a very special case, and I reproduced it once (actually, I had about 10 sections in one issue and about 8 of them didn't have links on the 'up' arrows)... But in trying to debug the problem I unset the custom ordering and have no idea how to reproduce the error! This heat wave might have made me stupid though.
I did have the $sections array in pages/editor/IssueManagementHandler.inc.php printed out when the bug occurred though, and I noticed that $section and sometimes $sections was null for these sections in question, so its a handler and not a template problem.
Matt, did you get any further on this one?
No -- I spent so much time trying to reproduce this! Would you be able to take a look?
Can I set you up with a DB dump from CHSP? It can be duplicated there.
Sure, or I can take one down myself (Though I can't find them on lib-journals2 or 3)
Matt, it's on lib-journals2 -- my typo, the install is called cshp (not chsp). See the URL above.
Created attachment 2327 [details]
Patch against OJS pre-2.3 CVS
Well, the reason this is occurring is because the custom_section_orders table is not being consistently maintained. For instance in volum 61, no 5 of CSHP, there is a section 26 (Report From The Presidential Team) that never doesn't exist in the custom_section_orders table, so the issue management handler thinks section 8 (News) is the last section and doesn't provide a down arrow link.
I still can't really reproduce the problem, but I think it has something to do with the fact that when you delete an article that is the only article in the section, the section is not deleted from the custom_section_orders table. This patch fixes this bug.
Patch committed. Though I can't reproduce the problem and see if the patch actually fixes it, I think this is the only way the custom_section_orders table can get messed up. Also, the problem is very hard to reproduce. So I'm gonna mark this as closed :)
Created attachment 3964 [details]
Screenshoot of the issue
I arrived today to the same place with 2.3.6 (where this patch it's included in the release).
An screen shoot is added to illustrate.
What I found it's that my "published_articles" table included an "archived" article (I suspect this is not the culprit) and "custom_section_order" had info about sections not included in the issue.
When I clean "custom_section_order" with "DROP where issue_id=XX" and INSERT just the sections of the issue (with a sequential number starting by 1) the problem disappears.
I don't know what my "Journal Manager" exactly did to mess the "custom_section_order" but sounds like they play with the sections adding and removing... and OJS wasn't able to "clean up" the table by it's own.
Marc, would it be possible for you to share with me a (suitably anonymized) database dump?