Discussion notification leads to the current workflow stage, not to the stage where the discussion thread is

[librariam]

Describe the bug
When a discussion participant clicks on a notification that a conversation thread has been added to in OJS, they are taken to the most recent stage of the workflow, NOT to the thread from which the notification originated. For example, if there is a notification from a "Pre-Review Discussion" under the Submission Tab, when clicking the notification it actually takes you to "Round 2" under the Review Tab (current stage).

To an editor not familiar with this behaviour it would appear as though the discussion has disappeared. To one familiar it still means searching through the pages to find the relevant thread.

To Reproduce
Steps to reproduce the behavior:

1. Start a pre-review discussion in the Submission stage
2. Advance the submission into the Review stage
3. Reply to a pre-review discussion
4. Follow the discussion notification (via email or dashboard notifications)
5. The link leads to the Review stage (not the Submission stage where the discussion thread is)

What application are you using?
OJS 3.2 and 3.3

Additional information
I suspect embedding discussion content into the notification (#6222) would partially address the issue, but it would still make sense for the notification to lead to the proper stage.

[NateWr]

Just dropping some notes in here on what needs to be changed. The URL is generated by QueryNotificationManager:

https://github.com/pkp/pkp-lib/blob/main/classes/notification/managerDelegate/QueryNotificationManager.inc.php#L110

It uses the getWorkflowUrlByUserRoles method:

https://github.com/pkp/pkp-lib/blob/main/classes/submission/Repository.inc.php#L147

However, this is used in many other cases too, so we need to be careful not to change how the generated URL works. It's a complicated method because it checks a number of things to ensure the correct URL is delivered depending on how the user is assigned to the submission: as a reviewer, author or editorial staff.

Probably we need to separate out the logic that checks the user's assignment from the code that generates the URL. Then the notification will be able to generate the correct URL based on the user assignment.

[forgive38]

Hello

Because our editors need this feature, I'm looking into creating a link to open the discussion directly. It could be "QueryNotificationManager->getNotificationUrl()"#stageId#queryId.
Then I will have to develop the logic to open directly the corresponding modal.

@NateWr : Do you think it is the right way?

thank you

[NateWr]

I don't want to add such a feature into the workflow page right now. At some point, we are going to have to redesign and refactor the workflow page to meet accessibility requirements. Adding this feature in now will make that refactor more complicated when we get to it.

Is the problem with a URL that appears in an email? One that appears in the in-app "tasks" list? Or both?

[forgive38]

In both cases: in notification of a discussion in tasks list or by mail, the generated URL redirect to the current stage of the workflow. But not to the stage of the discussion and even less directly to the discussion modal.

If you plan to redesign this part of the UI, I'll wait before working on it.
I will rather look at how to integrate the content of the discussion in the email sent

[NateWr]

If you plan to redesign this part of the UI, I'll wait before working on it.
I will rather look at how to integrate the content of the discussion in the email sent

Thanks @forgive38! At another stage of the development cycle I might be able to oversee a bigger change, but we're late on 3.4 so trying to stay focused.

Integrating the content of the discussion in the email will be great. See this issue: #6222

You could also fix just the bug report in this issue by making the URL go to the correct stage of the workflow. That would be an easy improvement to merge, even if it's not the full feature you wanted.