Hello,
Any update on this?
Thank you!
Best Regards
Hi @digitojs,
When you manually delete a review round, youāre probably leaving related entities in the database (particularly in the notifications table) related to that deleted entity. I donāt suggest intervening in the database like this, but if you do, make sure youāre cleaning up anything with assoc_type=523 (thatās the PHP-side ASSOC_TYPE_REVIEW_ROUND constant) and assoc_id equal to your review_round_id.
I tried creating a second review round and wasnāt able to duplicate the behavior you described. Can you give me a step-by-step example? If youāre able to synthetically build the example, so much the better, as itāll be easier to repeat.
Regards,
Alec Smecher
Public Knowledge Project Team
Hello @asmecher,
Thank you for your reply.
Actually, I cant replicate that behavior because it isnāt happening anymore and the user that was affected by it has no problems now. He can check the tasks menu again, and Iām not sure what could have been the cause. If it happens again and I can duplicate it, Iāll let you know step by step.
Regarding the other part of your comment, I have at least two users with that problem. And when they are logged in and access submissions or the taks menu, I added a print to the code and the assoc_type it logs is 517 and not 523. After that, the error shows up. I tried to track those review_assignments or review_rounds, but Iām missing some idās or other references. If I had wrote down the assignments I deleted it would be easierā¦
Thank you,
Best regards
Hi @digitojs,
Not a surprise ā thereās quite a tangle of interrelated entities. If youāre looking to remove content from the database you might have better luck invoking the delete functions in the DAOs from within PHP, as they should take care of deleting related entities.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
Problem solved.
Thank you for your time and patience, this was a mess Iāve complicated even more. There was no need to re-create DB entries or others, but for some reason I thought something was missing. Everything is clean now and no more related issues again!
Thank you!
Best regards
Hi @asmecher,
I think we should prohibit deletion of a section with at least one article connected in OJS.
After transition to OJS our journal managers found a lot of duplicating sections. They tried to delete them. So some articles might become āorphanedā. That is why I think we have those errors now.
Hi @Ph_We,
That should be the case ā see Check if section has articles before deleting Ā· pkp/ojs@924289d Ā· GitHub (which is included in OJS 3.1.0).
Regards,
Alec Smecher
Public Knowledge Project Team
1 Like
Years later, Iām reviving the topic. Iāve been having the same problem for about a week. Tasks didnāt load and the loading circle was spinning forever. Our site is on a hosting account using cPanel and the log records were not as detailed as what you shared here. Maybe itās due to OJS version difference, I donāt knowā¦ Anyway; Thanks to what you wrote, I made an inference and solved the problem.
When we first set up OJS, we did some tests to understand the system and workflows. We couldnāt delete the submissions from the admin panel and I deleted these submissions from the database to avoid confusion when we start receiving real submissions. However, tasks of these submissions remained. I thought that OJS couldnāt load the tasks because these submissions were deleted and the notifications table and the submissions table were related, so I deleted the old notifications (Instead of directly associating it with the submission id, a different method was followed, so I could not detect the notifications associated with the submissions I deleted) from the notifications table in the database. So, problem solved.