Journal manager initiates a Copyediting Discussion for Submission 1, with Author 1. Author responds on X date, including file uploads in her response.
On Y date, Journal manager initiates a Copyediting discussion for Submission 2, with Author 2. However, the discussion is incorrectly attributed to Author 1 in the discussion, and the datestamp is for X instead of Y.
We are looking into the queries table and notes tables - any further suggestions for debugging? We are having a very hard time replicating the issue consistently but will keep trying to pin it down.
So the queries table confirms what the UI shows, which is that the incorrectly attributed discussion has recorded the username and user_id for Author 1 instead of for the Journal Manager. (Author 1 does not have access to this submission), and records a date_created 4 days before the actual date the discussion was created.
We’ve tried testing several different variations of sending discussions between different roles in our test journal, but can’t reproduce this error. Any thoughts on what may have caused it?
We have had another report of discussions being misattributed to the wrong user. The editor initiated a discussion on May 17, but once he saved the discussion it was dated April 12, and attributed to the wrong user, who was not included in the discussion, or related to the submission. This is a different journal from the one reported above, and on a completely separate instance of OJS. Any ideas of what could be going wrong here, or where we can look to resolve this issue? I can see it in the queries table, with the wrong user attributed. There doesn’t seem to be any particular circumstance that causes this to happen, but would appreciate hearing if others have had the same behaviour reported.
Hi,
I confirm that weve the same problem but we don't know what causes it. This doest happen often, but always in installations OJS with multiple journals.
I confirm everything you write. In such cases, we try to manually change the authors of the discussions in the database.
Peter
Can you narrow down the conditions in some way? For example, is the user to whom the discussion is falsely attributed always a journal manager or “insider”? Do they always have other discussions in the system? Or any other commonality you can identify.
Thanks,
Alec Smecher
Public Knowledge Project Team
Hi @smecher - we only have an n= 2 we’ve been able to catch so not sure if shared characteristics would be just coincidence or a pattern! Both times, the conversations were attributed to users with Author / Reviewer / Reader accounts who did not have manager/editor permissions. Both times these authors also had active submissions in production as well, and had had earlier discussions in their own unrelated submissions. Neither had any permissions or associations that would allow them to have access to the submissions with the misattributed discussions.
We’ve seen this before, too. In our case, we had a discussion post attributed to a user who wasn’t even assigned to the journal. @asmecher if I remember right, you and I talked about the possibility of some clean up not happening if a user clicks to create a new discussion, but then closes the browser window instead of cancelling out of the modal. I don’t think the clean up code runs in that case? There’s an initial query record created there in order to have the query id so the note can be assigned, I think. Is there a chance that those orphaned records can get used again or assigned elsewhere?