OJS 3.4.0.1 - Authors Unable to Initiate Discussion in Workflow

Hi,
I am reaching out to report a bug that we have discovered within our OJS 3.4.0.1, specifically concerning the discussion functionality in the author workflow.

Currently, we have noticed that authors are unable to start a discussion at any stage of the workflow. While the editor can initiate a discussion thread with the author successfully, the author’s attempts to initiate a discussion encounter an issue.

Here’s a breakdown of the problem:

  1. When the editor starts a discussion with the author, the author can effectively reply to the thread and add their message. This functionality is working as expected.
  2. However, when the author attempts to initiate a discussion by clicking on the appropriate button, a message window opens up. Upon pressing the “OK” button to send the message, the window briefly displays a processing circle sign, but no further action occurs. The window remains open, and the message is not sent. Meanwhile, on the editor’s dashboard, a new discussion line appears, but it lacks any accompanying message.

Interestingly, it is not throwing any error in the PHP error log. Thank you for your time and support. We eagerly await your assistance in rectifying this bug.

OJS: 3.4.0.1
PHP: 8.1

Regards
seisense

Hi @seisense,

Can you use your browser’s web development tools to see what the response looks like from the server side when you attempt to start a discussion as Author? What is the HTTP response code (e.g. 200 , 500, etc), and what are the contents (if any) of the response from the server?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher
I tried but the browser’s web development tool is not throwing any error. Please see the attached screenshot. On pressing the OK button, a wheel spins briefly next to OK and then disappears.
There is nothing in php error log as well.
Thanks
seisense

Hi @seisense,

I’m not sure what browser you’re using (it’s different than mine) – but look for a “Network” tab, which will capture and inspect network exchanges between the browser and server.

Regards,
Alec Smecher
Public Knowledge Project Team

Hello @asmecher ,
Thanks for pinpointing where exactly to look at…
Below is the screenshot of the network tab and the last two entries of the screenshot appear only when I hit the “OK” button in the add discussion window.

following two screenshots shows the detailed headers of the last two entries:

Thanks
seisense

Hi @seisense,

Thanks, that helps. Can you look at the Response tab of the update-query response?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher ,
Please find below the screenshot:

Thanks
seisense

Hi @seisense,

I suspect this is coming from the access to check that determines whether the author is allowed to edit a discussion or not. It’s implemented here:

In particular, I think this check is not working as expected:

It should permit authors to edit discussions, as long as they were created within the last hour (3600 seconds).

I don’t think this implementation has changed since 3.3.0-x; are you sure this is a regression that appeared in OJS 3.4.0?

One thing that might be helpful – can you verify that we’ve identified the problem correctly, by temporarily removing that last condition:

&& (time() - strtotime($headNote->getDateCreated()) < 3600)`

…and seeing if it causes the problem to go away? (This is not a fix – just a confirmation that we’ve identified the right issue.)

(Add lib/pkp/ to the start of the pathnames here to get the full location.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher ,
I have made the suggested change in a specific file (see the screenshot)

But, it still does not allow the author to start the discussion.
Regards
seisense

Hi @asmecher ,
I tried the solution we applied here Error during upgrade from 3.3.0.13 to 3.4.0.1 - Unsupported assoc_type in the event log: 515 - #16 by asmecher

by changing the triple equal to the double equal sign, it has solved two problems:
1- Now the author can start the discussion
2- The editor was not allowed to use the “Notify” option after the change even this function is working fine.

Now the question is do you recommend keeping this change or I should revert this to a triple equal sign? Is this change going to break/harm any other function?

Thanks
seisense

Hi @seisense,

Hmm, this is a curious issue – I wasn’t able to replicate the other type mismatch on my own system, nor this one. I’m using PHP 8.1.21, and I see you are using 8.1 as well. What specific version of PHP are you running? I suspect this is an underlying PHP bug that’s already been fixed, but I’d love to track down the details.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher ,
I am using PHP 8.1.20 with the following configuration

I have another subdomain where I am still running OJS 3.3.0.14 with the same configuration as above and I never encountered any issues. Before writing this post, I tested all these functions once again (the author can start the discussion and the editor can use the “Notify” function) on this test domain and I found it is working perfectly.

Hope it helps to figure out why PHP behaving strangely on my server.
Regards
seisense

Hi @seisense,

Hmm, the differences between PHP 8.1.20 and 8.1.21 don’t seem relevant – and that’s just a single build gap, which would be surprising if it were the cause. My dev system is very close to yours in other respects too, e.g. the MariaDB version.

I’ve filed and fixed this here…

…however, if anyone is able to investigate the mismatch more deeply, I’d love to know more about it!

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @seisense,

There are a few suspects for this, per this PHPFreaks thread and StackOverflow thread:

  • One of us is using mysqlnd, and the other is using mysqli. Checking my phpinfo() output, it looks like I’m using mysqlnd.
  • One of our systems is emulating prepared statements, while the other is using them natively. There is a PDO option that should be turned off by default for this: PDO::ATTR_EMULATE_PREPARES
  • One of our systems has “stringify fetches” turned on. There is a PDO option that should be turned off by default for this: PDO::ATTR_STRINGIFY_FETCHES

All the same, this does appear to be something that’s evolving in PHP8.1 (release notes), so the dev team is probably going to have to be careful not to assume sane types coming from the database.

Regards,
Alec Smecher
Public Knowledge Project Team

This topic was automatically closed after 13 days. New replies are no longer allowed.

Heads-up on how to debug this: It’s possible to cause PDO/Laravel/MySQL/PHP to behave in this unusual way by calling (prior to the offending database fetches)…

stable-3_3_0:

\Illuminate\Database\Capsule\Manager::schema()->getConnection()->getPdo()->setAttribute(PDO::ATTR_EMULATE_PREPARES,true);
\Illuminate\Database\Capsule\Manager::schema()->getConnection()->getPdo()->setAttribute(PDO::ATTR_STRINGIFY_FETCHES,true);

stable-3_4_0:

\Illuminate\Support\Facades\Schema::getConnection()->getPdo()->setAttribute(\PDO::ATTR_EMULATE_PREPARES,true);
\Illuminate\Support\Facades\Schema::getConnection()->getPdo()->setAttribute(\PDO::ATTR_STRINGIFY_FETCHES,true);

(I also tried adding these to the Laravel database connection options array, but it didn’t work for some reason.)