I am currently testing our installation of OJS 3 and I have this remark:
Quite often when I remove a participant or add a new one to a submission, the page needs to be reloaded manually for a new list of participants to be displayed correctly, with corresponding right panel buttons.
Perhaps this could be fixed?
Anna
_(Edit - This issue has unearthed a bunch of different problems, which have been compiled in this comment)._
@ania-appb, this suggests that a Javascript error occurred; can you use a developer toolbar such as Firebug for Firefox to check what the Javascript console looks like when this condition arises?
@asmecher, I am not sure, but I believe this is one of those cases I also find, where the reload/refreshing should be done. E.g. also when publishing/unpublishing issues.
@asmecher, @bozana, I can give you this example:
when I added a participant (in this case this was a journal manager) to one of the submissions, reloading worked fine, next I made removing this participant and after that action, manual reloading needed to be done as he still was present on the list of the participants. No errors appeared in the JS console of my Firefox browser, except the warning after the page was manually reloaded:
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user鈥檚 experience. For more help http://xhr.spec.whatwg.org/
I noted that when I made such a test for another submission everything worked correctly.
So this behaviour happens every now and then, but quite often when I add a participant who has more permissions and additional buttons (e.g. Send to Copyediting) are to appear.
Anna
A bug with removing a participant from the list was fixed back in August:
https://github.com/pkp/pkp-lib/issues/1684
That "Synchronous XMLHttpRequest..." warning is cosmetic and can be ignored (for now).
Could you check whether that commit is included in your installation?
@asmecher, thank you for answer, in our installation I found that file in this localization:
/lib/pkp/controllers/grid/users/stageParticipant/StageParticipantGridHandler.inc.php
But it is ok - that commit is included in our installation.
So, this must be something else that is causing the problem I described above.
Anna
@asmecher, @bozana, another example of necessity of manual reloading in OJS 3:
When I added Journal Editor to the list of Participants in the Copyediting stage of a test submission, the page needed to be manually reloaded for Send To Production button to apear.
No errors were displayed in the console of my browser.
Anna
@ania-appb, did you check the server error log? The browser console might not be the relevant place to look, depending on your server's configuration for PHP error handling.
Hello @asmecher, so, once again I added Journal Editor to the list of Participants, she appeared on the list, then, I had to manually reload the page for Send To Production button to appear.
Here is what I got from the log:
2016-10-06 09:49:45 PHP Strict Standards: Declaration of ArticleGalleyGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/acta/ojs/ojs-3.0.0/controllers/grid/articleGalleys/ArticleGalleyGridHandler.inc.php on line 356
2016-10-06 10:04:22 PHP Deprecated: Non-static method PKPRequest::getUserVar() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/form/Form.inc.php on line 351
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::customTemplateExistsByKey() should be compatible with PKPEmailTemplateDAO::customTemplateExistsByKey($emailKey, $assocType, $assocId) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::deleteEmailTemplateByKey() should be compatible with PKPEmailTemplateDAO::deleteEmailTemplateByKey($emailKey, $assocType, $assocId) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::getBaseEmailTemplate() should be compatible with PKPEmailTemplateDAO::getBaseEmailTemplate($emailKey, $assocType, $assocId) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::getEmailTemplate() should be compatible with PKPEmailTemplateDAO::getEmailTemplate($emailKey, $locale, $assocType, $assocId) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::getEmailTemplates() should be compatible with PKPEmailTemplateDAO::getEmailTemplates($locale, $assocType, $assocId, $rangeInfo = NULL) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::getLocaleEmailTemplate() should be compatible with PKPEmailTemplateDAO::getLocaleEmailTemplate($emailKey, $assocType, $assocId) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of EmailTemplateDAO::templateExistsByKey() should be compatible with PKPEmailTemplateDAO::templateExistsByKey($emailKey, $assocType = NULL, $assocId = NULL) in /home/acta/ojs/ojs-3.0.0/classes/mail/EmailTemplateDAO.inc.php on line 20
2016-10-06 10:04:22 PHP Strict Standards: Declaration of UserSelectGridHandler::authorize() should be compatible with GridHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/userSelect/UserSelectGridHandler.inc.php on line 214
2016-10-06 10:04:22 PHP Strict Standards: Declaration of UserSelectGridHandler::initFeatures() should be compatible with GridHandler::initFeatures($request, &$args) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/userSelect/UserSelectGridHandler.inc.php on line 214
2016-10-06 10:04:22 PHP Strict Standards: Declaration of UserSelectGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/userSelect/UserSelectGridHandler.inc.php on line 214
2016-10-06 10:04:22 PHP Strict Standards: Only variables should be passed by reference in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/form/AddParticipantForm.inc.php on line 74
2016-10-06 10:04:23 PHP Strict Standards: Only variables should be passed by reference in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/userSelect/UserSelectGridHandler.inc.php on line 140
2016-10-06 10:04:23 PHP Strict Standards: Only variables should be passed by reference in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/userSelect/UserSelectGridHandler.inc.php on line 204
2016-10-06 10:04:31 PHP Deprecated: Non-static method PKPRequest::_checkThis() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/core/PKPRequest.inc.php on line 582
2016-10-06 10:04:31 PHP Deprecated: Non-static method PKPRequest::getUserVar() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/form/Form.inc.php on line 370
2016-10-06 10:04:31 PHP Strict Standards: Declaration of AddParticipantForm::readInputData() should be compatible with PKPStageParticipantNotifyForm::readInputData($request) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/form/AddParticipantForm.inc.php on line 18
2016-10-06 10:04:31 PHP Strict Standards: Declaration of AddParticipantForm::validate() should be compatible with Form::validate($callHooks = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/form/AddParticipantForm.inc.php on line 18
2016-10-06 10:04:31 PHP Strict Standards: Declaration of PKPStageParticipantNotifyForm::execute() should be compatible with Form::execute($object = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/form/PKPStageParticipantNotifyForm.inc.php on line 18
2016-10-06 10:04:31 PHP Strict Standards: Declaration of PKPStageParticipantNotifyForm::fetch() should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/form/PKPStageParticipantNotifyForm.inc.php on line 18
2016-10-06 10:04:31 PHP Strict Standards: Declaration of PKPStageParticipantNotifyForm::readInputData() should be compatible with Form::readInputData() in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/form/PKPStageParticipantNotifyForm.inc.php on line 18
2016-10-06 10:04:31 PHP Strict Standards: Declaration of ValidatorUrl::getRegexp() should be compatible with ValidatorUri::getRegexp($allowedSchemes = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/validation/ValidatorUrl.inc.php on line 19
2016-10-06 10:04:49 PHP Deprecated: Non-static method WorkflowStageDAO::getStageStatusesBySubmission() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/pages/workflow/PKPWorkflowHandler.inc.php on line 283
2016-10-06 10:04:49 PHP Strict Standards: Declaration of PageHandler::authorize() should be compatible with PKPHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/page/PageHandler.inc.php on line 19
2016-10-06 10:04:49 PHP Strict Standards: Declaration of PublishedArticleDAO::getBySetting() should be compatible with ArticleDAO::getBySetting($settingName, $settingValue, $journalId = NULL, $rangeInfo = NULL) in /home/acta/ojs/ojs-3.0.0/classes/article/PublishedArticleDAO.inc.php on line 800
2016-10-06 10:04:50 PHP Deprecated: Non-static method PKPRequest::_checkThis() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/classes/core/Request.inc.php on line 68
2016-10-06 10:04:50 PHP Deprecated: Non-static method Request::getContext() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/plugins/ThemePlugin.inc.php on line 372
2016-10-06 10:04:50 PHP Deprecated: Non-static method ScheduledTaskHelper::_isInRange() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/scheduledTask/ScheduledTaskHelper.inc.php on line 114
2016-10-06 10:04:50 PHP Deprecated: Non-static method ScheduledTaskHelper::checkFrequency() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/plugins/generic/acron/PKPAcronPlugin.inc.php on line 316
2016-10-06 10:04:50 PHP Deprecated: Non-static method SectionAssignmentRule::effect() should not be called statically, assuming $this from incompatible context in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/security/authorization/internal/UserAccessibleWorkflowStageRequiredPolicy.inc.php on line 107
2016-10-06 10:04:50 PHP Strict Standards: Declaration of CategoryGridHandler::doSpecificFetchGridActions() should be compatible with GridHandler::doSpecificFetchGridActions($args, $request, $templateMgr) in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/controllers/grid/CategoryGridHandler.inc.php on line 493
2016-10-06 10:04:50 PHP Strict Standards: Declaration of CategoryGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/controllers/grid/CategoryGridHandler.inc.php on line 493
2016-10-06 10:04:50 PHP Strict Standards: Declaration of CategoryGridHandler::setUrls() should be compatible with GridHandler::setUrls($request, $extraUrls = Array) in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/controllers/grid/CategoryGridHandler.inc.php on line 493
2016-10-06 10:04:50 PHP Strict Standards: Declaration of CustomBlockPlugin::getContents() should be compatible with BlockPlugin::getContents($templateMgr, $request = NULL) in /home/acta/ojs/ojs-3.0.0/plugins/generic/customBlockManager/CustomBlockPlugin.inc.php on line 130
2016-10-06 10:04:50 PHP Strict Standards: Declaration of GridCategoryRowCellProvider::getCellActions() should be compatible with GridCellProvider::getCellActions($request, $row, $column, $position = GRID_ACTION_POSITION_DEFAULT) in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/controllers/grid/GridCategoryRowCellProvider.inc.php on line 19
2016-10-06 10:04:50 PHP Strict Standards: Declaration of InformationBlockPlugin::getContents() should be compatible with BlockPlugin::getContents($templateMgr, $request = NULL) in /home/acta/ojs/ojs-3.0.0/plugins/blocks/information/InformationBlockPlugin.inc.php on line 18
2016-10-06 10:04:50 PHP Strict Standards: Declaration of LanguageToggleBlockPlugin::getContents() should be compatible with BlockPlugin::getContents($templateMgr, $request = NULL) in /home/acta/ojs/ojs-3.0.0/plugins/blocks/languageToggle/LanguageToggleBlockPlugin.inc.php on line 106
2016-10-06 10:04:50 PHP Strict Standards: Declaration of LensGalleyPlugin::getTemplatePath() should be compatible with Plugin::getTemplatePath($inCore = false) in /home/acta/ojs/ojs-3.0.0/plugins/generic/lensGalley/LensGalleyPlugin.inc.php on line 157
2016-10-06 10:04:50 PHP Strict Standards: Declaration of NotificationsGridHandler::initFeatures() should be compatible with GridHandler::initFeatures($request, &$args) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/notifications/NotificationsGridHandler.inc.php on line 239
2016-10-06 10:04:50 PHP Strict Standards: Declaration of NotificationsGridHandler::setUrls() should be compatible with GridHandler::setUrls($request, $extraUrls = Array) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/notifications/NotificationsGridHandler.inc.php on line 239
2016-10-06 10:04:50 PHP Strict Standards: Declaration of PKPWorkflowHandler::authorize() should be compatible with PKPHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/pages/workflow/PKPWorkflowHandler.inc.php on line 24
2016-10-06 10:04:50 PHP Strict Standards: Declaration of PKPWorkflowHandler::initialize() should be compatible with PKPHandler::initialize($request, $args = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/pages/workflow/PKPWorkflowHandler.inc.php on line 24
2016-10-06 10:04:50 PHP Strict Standards: Declaration of PKPWorkflowTabHandler::authorize() should be compatible with PKPHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/tab/workflow/PKPWorkflowTabHandler.inc.php on line 23
2016-10-06 10:04:50 PHP Strict Standards: Declaration of PdfJsViewerPlugin::getTemplatePath() should be compatible with Plugin::getTemplatePath($inCore = false) in /home/acta/ojs/ojs-3.0.0/plugins/generic/pdfJsViewer/PdfJsViewerPlugin.inc.php on line 136
2016-10-06 10:04:50 PHP Strict Standards: Declaration of QueriesGridCellProvider::getCellActions() should be compatible with GridCellProvider::getCellActions($request, $row, $column, $position = GRID_ACTION_POSITION_DEFAULT) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/queries/QueriesGridCellProvider.inc.php on line 18
2016-10-06 10:04:50 PHP Strict Standards: Declaration of QueriesGridHandler::authorize() should be compatible with GridHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/queries/QueriesGridHandler.inc.php on line 515
2016-10-06 10:04:50 PHP Strict Standards: Declaration of QueriesGridHandler::getDataElementSequence() should be compatible with GridHandler::getDataElementSequence(&$gridDataElement) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/queries/QueriesGridHandler.inc.php on line 515
2016-10-06 10:04:50 PHP Strict Standards: Declaration of QueriesGridHandler::initFeatures() should be compatible with GridHandler::initFeatures($request, &$args) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/queries/QueriesGridHandler.inc.php on line 515
2016-10-06 10:04:50 PHP Strict Standards: Declaration of QueriesGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/queries/QueriesGridHandler.inc.php on line 515
2016-10-06 10:04:50 PHP Strict Standards: Declaration of QueriesGridHandler::setDataElementSequence() should be compatible with GridHandler::setDataElementSequence($request, $rowId, &$gridDataElement, $newSequence) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/queries/QueriesGridHandler.inc.php on line 515
2016-10-06 10:04:50 PHP Strict Standards: Declaration of StageParticipantGridHandler::authorize() should be compatible with GridHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/StageParticipantGridHandler.inc.php on line 24
2016-10-06 10:04:50 PHP Strict Standards: Declaration of StageParticipantGridHandler::loadCategoryData() should be compatible with CategoryGridHandler::loadCategoryData($request, &$categoryDataElement, $filter = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/users/stageParticipant/StageParticipantGridHandler.inc.php on line 24
2016-10-06 10:04:50 PHP Strict Standards: Declaration of SubmissionFileDAO::fromRow() should be compatible with PKPSubmissionFileDAO::fromRow($row, $fileImplementation) in /home/acta/ojs/ojs-3.0.0/classes/article/SubmissionFileDAO.inc.php on line 23
2016-10-06 10:04:50 PHP Strict Standards: Declaration of SubmissionFilesGridHandler::authorize() should be compatible with GridHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/files/SubmissionFilesGridHandler.inc.php on line 205
2016-10-06 10:04:50 PHP Strict Standards: Declaration of SubmissionFilesGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/acta/ojs/ojs-3.0.0/lib/pkp/controllers/grid/files/SubmissionFilesGridHandler.inc.php on line 205
2016-10-06 10:04:50 PHP Strict Standards: Declaration of WebFeedBlockPlugin::getTemplatePath() should be compatible with Plugin::getTemplatePath($inCore = false) in /home/acta/ojs/ojs-3.0.0/plugins/generic/webFeed/WebFeedBlockPlugin.inc.php on line 105
2016-10-06 10:04:50 PHP Strict Standards: Declaration of WebFeedPlugin::getTemplatePath() should be compatible with Plugin::getTemplatePath($inCore = false) in /home/acta/ojs/ojs-3.0.0/plugins/generic/webFeed/WebFeedPlugin.inc.php on line 190
2016-10-06 10:04:50 PHP Strict Standards: Only variables should be passed by reference in /home/acta/ojs/ojs-3.0.0/lib/pkp/classes/core/PKPApplication.inc.php on line 210
This looks like no errors were detected. I would appreciate your comments on that.
Anna
One more example of quite similar problem:
When one opens Tasks they are displayed as a list, and to make this list close, one has to click on some other link (as clicking somewhere outside the list needs manual reloading) , this is confusing and inconvenient.
@asmecher, do you observe such behaviour?
@ania-appb, FYI, I've replicated the issue of needing to reload the page after assigning an editor in order for the editorial decisions to appear.
Hi,
I am experiencing similar problems as well.
The php error log is clean and there are no javascript errors in console. The only thing I am getting is this "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user鈥檚 experience. For more help http://xhr.spec.whatwg.org/"
If I turn deprecation errors on, I can see a lot of them and they prevent a lot of javascript loading on the page, but these should not of course affect this issue when turned off.
I have tested with FF 49.0.2, IE 11.0.9600.18499 and Chrome 54.0.2840.71, using Windows 7. All browsers have the same problem and the problem appears both in our test server and my clean XAMPP installation. I am using OJS 3.0.0 downloaded from the PKP site (not a version from Github).
@asmecher: I can provide access to one of my test installations if it helps to solve this.
Edit: it seems that removing participants works when there are more than one using the same role. So, if there are two editors assigned to the submission removing the other one works and the grid is updated. But removing the second (and the last) editor does not update the grid - you have to refresh the page. When looking at the console I have noticed that this request is missing, when I remove the last participant of certain role:
http://sitedomain.fi/journal/$$$call$$$/grid/users/stage-participant/stage-participant-grid/fetch-grid?submissionId=59234&stageId=3&_=1478896463682
I changed the title of the issue, because there are more of the kind:
-- when submission is deleted (e.g. from unassigned queue)
-- when unpublishing a back issue, the back issue list is not updated
-- when publishing a future issue, the issue disappears from the future issue list, but it is not visible in the back issue list before reloading the page
-- when removing a participants from the list, the participants grid is not updated
-- when deleting a DOI the tab is not reloaded
-- there is the link "DOI Plugin Settings" on the Crossref plugin settings page. Is it possible to reload the page after saving the DOI Plugin Settings here?
-- reload page after unasign reviewer (because of the notifications)
-- notify participant --> reload page (because of the notifications)
-- delete galley -> reload page (because of the notifications)
-- delete discussion --> reload page (because of the notifications)
Unfortunately, now, I do not now how to solve them...
Just noticed that it's the same thing with most of these: if there are more than one item, the item is removed succesfully, but the last item needs a page refresh. I guess the same fetch-grid does not load in those cases?
I saw that @asmecher mentioned here http://forum.pkp.sfu.ca/t/workflow-for-uploading-without-quick-submit-plugin/26338/2 the problem with the buttons not appearing after adding an editor to a submission.
Are the buttons appearing automatically for someone when you add an editor? Out of around 70 users who have participated in our OJS3 workshops, everyone has had to refresh the page to make the buttons appear. This includes around 20 users training with 3.0.1.
Surprisingly I didn't run into this during any of my normal testing/development -- but that's probably because my test/dev setup has the journal configured such that editors are assigned automatically, so I don't run into the situation where an article goes from none assigned (Send To Review not displayed) to one or more assigned (button should be present). Fixing this is a high priority for the next release.
Just chiming in on this, particularly the list of issues @bozana identified. Some of these are just components that need an update trigger to fire, I think. But several of them are places where inter-widget communication is useful.
I'm going to take one of the really simple examples (like publishing an issue) and try to write up a global event router as a model for addressing these issues. If we like how it works we can extend it out to cover a bunch of these update issues.
I was able to reproduce the initial issue. I can reproduce it when removing the last participant in a user group.
Probably something to do with the category grids updating properly.
-- reload page after unasign reviewer (because of the notifications)
-- notify participant --> reload page (because of the notifications)
-- delete galley -> reload page (because of the notifications)
-- delete discussion --> reload page (because of the notifications)
@bozana can you explain these in more detail? I'm trying to reproduce them but not having much luck. When you say "notifications", are you talking about the in-place notification at the top of the workflow area, the floating notifications or the Tasks?
When I unassign a reviewer, the notification correctly changes for me. I was unable to find any associated notifications for the other events you describe.
Hi @NateWr :-) This was some time ago, but I hope I can explain: "notifications" are banners at the top of the page, that tell the user what is happening/to be done next, thus:
-- when an editor unassigns the last/only reviewer, the banner should change and tell that a reviewer has to be assigned and therefore the page reload would be needed, if I can recall correctly.
-- if there is a banner that copyeditor or layout editor has to be assigned and editor assigns the appropriate participant, the banner should change. Again page reload was necessary for that, I think.
-- if there is no galley, there is a banner that says that galley should be uploaded, I think, thus when removing the last galley, this banner should be displayed again. Again, the page reload was necessary, I believe.
-- hmmm.... I forgot about discussion... I will have to take another look... :-\
Does this helps anyhow?
THANKS!!!
Hi @bozana, ah I just noticed your post is from November! Sorry, just came to my attention recently.
That's what I thought, but I was unable to reproduce the problems you mention. The only notification I see is the reviewers notification, and this updates properly when a review is added or removed for me. Maybe it's been fixed since then.
Aaaa... OK, I can test them again... to see if it is still actual... :-)
Don't worry about it. I'm digging into the notifications so I'll test it out. Just wanted to make sure I understood you. :)
OK, thanks!!!
I've just taken a look at one: When an editor assigns a reviewer, this banner is displayed: "Awaiting responses from reviewers. " When he then immediately unassigns the reviewer, so that there is no reviewer assigned any more, the banner does not change for me immediately. First when I reload the page I see the correct banner "Waiting for reviewers to be selected. ". Is this not fore you?
Interesting, that does work for me on latest master...
Hmmm... I was on ojs-stable-3_0_1 and will check it now with master...
Hmmm... strange... it works when adding the review -- the banner changes -- but when unassigning the reviewer is does not work for me... (And I thought it makes sense, because all those JS actions seem to be problematic...) :-O
Hmm, it worked for me when unassigning a reviewer too (assuming it's the last reviewer and the grid is then empty).
But yes, all these JS events are messy. I'm trying to get to the bottom of it. :/
Great to see you working on this.
I think the clearest case of this happening is with the participants grid in the submissions.
Everytime you remove the last particapant of a certain group (for example the last editor) from the list of participants, the fetch-grid script is not running. If there are more than one in a group (for example two editors), the fetch-grid runs and clears the name.
@NateWr, would it be possible for you to check out this as well:
"Adding an editor or section editor in the submission stage works, but the buttons (Send to review, Send to copyediting, Decline submission) only appear if I refresh the page"
It is very common that an editor adds herself to the submission and at the moment she has to reload the the page manually or visit another page to get those buttons to show.
I am bringing this forward, because I have a feeling that this is a separate issue from the other reload issues here. The other issues seem to be grid related. This case could be a functionality that is missing altogether.
ps. and I of course realize that there are a lot other issues you are working on.
There seem to be a lot of different things reported in this issue. @asmecher, since this has a Critical Issue flag for 3.0.2, can we identify which things are critical? I doubt we'll get them all fixed. Here's my list of things mentioned in this issue:
Plus the following which I wasn't exactly clear on the details:
Which of these are critical for OJS 3.0.2? I want to make sure we get those filed properly, without losing all the other problems here.
The only truly critical one (IMO) is...
- If an editor assigns themselves to a submission, editorial actions (Send to Review, Accept, etc) don't appear until page refreshed. (To replicate, editors should not be assigned automatically.)
Ok, I spun the critical bit off to another issue, pegged that one to 3.0.2 and flagged it as critical.
I've removed Critical from this issue and assigned it to OJS 3.1. I'm hoping to address a bunch of these through a global event router #2163.
@Nate, assigning to you because of its relevance to the JS reworking you're doing.
Ok, I think I've addressed the outstanding issues. These PRs address:
PRs (tests running):
https://github.com/pkp/ojs/pull/1506
https://github.com/pkp/pkp-lib/pull/2736
@bozana, tests passed, can you code review?
@NateWr, looks good and I merged it... THANKS!!!